Download
2013-02-11, 05:18:17
This evening I had a look at http://get-simple.info/wiki/getsimple_coding and while I don't think that the rules are bad, they look a bit dated.
1. closing ?> tag at the end of the file: it's a good practice to avoid (since PHP does not discard the spaces after the last tag it sees). It's a hack, yes, but it's a good practice in modern php.
2. sanitizing the user input: GS should provide methods to do it, and not let the plugin developer mess with it. but the basics that all the input must be sanitized stands!
3. '' vs "" (single vs double quotes): while it's indeed a good idea to avoid "abcd $var efgh", since GS provides translation files, the advise should be not to output any not translated string. and if you want to be able to translate a string the best thign is to use a sprintf around it: sprintf(i18n_r('pluginname/ABCD')), where ABCD is defined as 'abcd %s efgh' (yes, when translating you often have to move around parts of the text)
btw, the difference between " and ' has officially been declared a non issue (there is no difference between using the one or the other)
4. don't be scared of ternary operators: they're a good thing in the right context! obviously, the exemple in the page linked above, shows that the person having added this point to the list does not understand when they are useful :-) "$dynamic = ($language == 'php' ? true : false);" should be written as "$dynamic = ($language == 'php')" and is still a bad example of using the assignment of results of comparisons (???) to a variable.
5. <?= is officially the best way to output strings when in the presantation context (and you should probably never output anything when you're not doing presentation...
so, all in all, not really big issues. still i have the feeling that the rules have been compiled by people who are scared by the way php is evolving...
1. closing ?> tag at the end of the file: it's a good practice to avoid (since PHP does not discard the spaces after the last tag it sees). It's a hack, yes, but it's a good practice in modern php.
2. sanitizing the user input: GS should provide methods to do it, and not let the plugin developer mess with it. but the basics that all the input must be sanitized stands!
3. '' vs "" (single vs double quotes): while it's indeed a good idea to avoid "abcd $var efgh", since GS provides translation files, the advise should be not to output any not translated string. and if you want to be able to translate a string the best thign is to use a sprintf around it: sprintf(i18n_r('pluginname/ABCD')), where ABCD is defined as 'abcd %s efgh' (yes, when translating you often have to move around parts of the text)
btw, the difference between " and ' has officially been declared a non issue (there is no difference between using the one or the other)
4. don't be scared of ternary operators: they're a good thing in the right context! obviously, the exemple in the page linked above, shows that the person having added this point to the list does not understand when they are useful :-) "$dynamic = ($language == 'php' ? true : false);" should be written as "$dynamic = ($language == 'php')" and is still a bad example of using the assignment of results of comparisons (???) to a variable.
5. <?= is officially the best way to output strings when in the presantation context (and you should probably never output anything when you're not doing presentation...
so, all in all, not really big issues. still i have the feeling that the rules have been compiled by people who are scared by the way php is evolving...
