This updates the guidelines per some internal discussions and based on actual usage (see the first commit for the detailed changes).
This also moves the guidelines to their own dedicated file so they aren't confused with the sniffs in this standard.
A good follow-up to this PR would be to document all the actual sniff codes in this standard and link them to the associated guidelines.
Notable changes:
I don't see any reason to suggest using "new style" variable functions over "call_user_func" style. They're both bad. In some ways, the "call_user_func" style is easier to spot since it's explicit.
Some MUSTs I changed to SHOULDs since we can't avoid them.
Pure functions have a real definition and I don't think our partial definition was helpful, so I just removed mentions of that partial definition.
I can't come up with any good reason to use static methods over namespaced functions, so I just re-worded that section to say we shouldn't use them (but used SHOULD just in case).
I tried to clarify where side-effects should be made. I also removed mentions of database read access from the definition of side-effects, since I don't think they are side effects. They should still be made using a Facade pattern, but that's a different concept.
Increased the max function size from 20 lines to 40.
Added guidelines on boolean arguments.
Added guidelines on file, namespace, class, and function naming.
Added guidelines on validating database values and using value objects for database results.
prettyboymp
commented
5 years ago
This updates the guidelines per some internal discussions and based on actual usage (see the first commit for the detailed changes).
This also moves the guidelines to their own dedicated file so they aren't confused with the sniffs in this standard.
A good follow-up to this PR would be to document all the actual sniff codes in this standard and link them to the associated guidelines.
Notable changes: