News Feed
Sections




News Archive
feed this:

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

Phil Sturgeon:
PSR-2 v CodeSniffer PSR-2 A Success Story
October 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.

0 comments voice your opinion now!
psr2 codesniffer rule clarity errata phpfig

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

Benjamin Eberlei:
Doctrine and SOLID
February 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.

0 comments voice your opinion now!
doctrine value method objects clarity solid development principles



Community Events





Don't see your event here?
Let us know!


threedevsandamaybe laravel developer interview introduction series configure language refactor community framework wordpress release list code testing opinion podcast unittest install

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework