Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Matthias Noback:
More code comments
Aug 16, 2018 @ 10:06:58

In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola PoŇ°a. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

tagged: code comment refactor opinion clarity types usefulness

Link: https://matthiasnoback.nl/2018/08/more-code-comments/

Phil Sturgeon:
PSR-2 v CodeSniffer PSR-2: A Success Story
Oct 16, 2013 @ 09:34:15

In a new post to his site Phil Sturgeon talks about the "success story" around the PSR-2 PHP-FIG standard and his work to get the PHP CodeSniffer checks to be more correct for it.

I've had static analysis tools running in Sublime Text for a long time, but for most of that time I have had CodeSniffer and it's PSR-2 rules disabled. I couldn't for the life of me remember why I had done that, until I turned it back on again. All of a sudden it started complaining about code that I had always considered to be perfectly compliant. It reminded me of multiple conversations I've had with others in the FIG and the community in general, about how CodeSniffer often enforces rules in the PSR-2 spec that do not exist, or were not what was meant when it was written. Two months ago I set off on a mission, to get CodeSniffer in line with what PSR-2 really is.

He gets into a bit of the backstory around the checks and the addition of "Errata" to add to the specs that have already been defined. The goal isn't to alter what's been defined, but to help clarify some issues (or close some loopholes) that might have come up. After polling the PHP-FIG mailing list about it - and it passing unanimously - the Errata was added and the CodeSniffer rules were updated to match (PHP_CodeSniffer 1.4.7).

If you're interested in other unclear places in the PSR-2 spec and want to discuss it, check out this gist and the conversation that goes with it.

tagged: psr2 codesniffer rule clarity errata phpfig

Link: http://philsturgeon.co.uk/blog/2013/10/psr2-v-codesniffer-psr2

Benjamin Eberlei:
Doctrine and SOLID
Feb 05, 2013 @ 11:09:33

Benjamin Eberlei has a new post to his site today answering a question he sometimes gets about using Doctrine2 in a SOLID context (more on SOLID development here) as it seems difficult to follow the Single Responsibility Principle with how the tool is used.

These problems are related to the inability to share behavioral code through aggregation and the complexity of state transformations. Combining both, your average entity with 5-15 fields can end up with hundrets or thousands lines of code. The solutions to both problems boil down to minimizing duplication and maximizing clarity.

He looks at two different kinds of objects Doctrine uses in its setup, the value objects and method objects, and "maximize clarity" on them by dividing them up into more functional-related objects, passed into each other via method injection.

tagged: doctrine value method objects clarity solid development principles

Link: