4 ms·

Those problems are not related to PHP but to inexperienced developers. Refactoring such code is always a pain. So unless there is nice money involved: don't ref

by ohwp 14y ago

Those problems are not related to PHP but to inexperienced developers. Refactoring such code is always a pain. So unless there is nice money involved: don't refactor, just fix what's broken. I don't think refactoring of spaghetti can be automated. But there are other tools that can help you to find bad code. Some that come in mind: https://github.com/fabpot/PHP-CS-Fixer http://pear.php.net/package/PHP_CodeSniffer/redirected Those tools are used for coding standards (PSR-x), but those standards are also helpful to track down bad code.

itafroma 14y ago
Good advice, with a couple of caveats about PSRs: - They're not all about coding standards: only two of them are. PSR-0 is a class autoloading standard and PSR-3 is a common interface for loggers. The next PSR is likely going to be a common caching interface. - PSR-1 and PSR-2 are controversial (although PSR-1 less so than PSR-2), and don't necessarily represent best practices amongst the larger PHP community. They're useful insofar as the PHP Framework Interoperability Group (PHP-FIG, http://www.php-fig.org/ http://www.php-fig.org/), the people crafting the PSRs, needed an internal standard and really shouldn't be represented as anything more than that. Much of both standards are an amalgam of individual practices produced via an internal survey of PHP-FIG member projects. If you have nothing, PSR-1 and PSR-2 aren't bad places to start, but diverging from them is more likely to happen than not, especially if you're working with projects or teams that have existing coding standards.
- h2s 14y ago
  > PSR-1 and PSR-2 are controversial > Much of both standards are an amalgam of individual > practices produced via an internal survey of PHP-FIG > member projects. Those member projects include codebases like Zend Framework, Symfony, Composer and Doctrine. Those standards are are a very accurate representation of the way the best, most popular open source PHP code is being written. The only controversy I'm aware of is those petty pull requests opened by people who didn't like that they chose spaces over tabs, which eventually drove one of the founders of the group to quit out of frustration.
  - itafroma 14y ago
    > Those standards are are a very accurate representation of the way the best, most popular open source PHP code is being written. PHP-FIG members have repeatedly cautioned[1][2][3][4] that the PSRs (notably PSR-2) are not a set of best practices, but merely a survey of commonalities of PHP-FIG member projects. Even then, several member projects do not, and have stated they will not, implement PSR-1 and/or PSR-2. Treating them as the best or most accurate representation of how PHP is being developed at large is exactly the wrong thing to take away from the PSR process. [1]: http://www.php-fig.org/faq/ http://www.php-fig.org/faq/ [2]: http://paul-m-jones.com/archives/2420 http://paul-m-jones.com/archives/2420 [3]: https://groups.google.com/d/msg/php-fig/TRpoq0kdrZk/OkyD-J4uz8sJ https://groups.google.com/d/msg/php-fig/TRpoq0kdrZk/OkyD-J4u... [4]: Matthew Weier O'Phinney's comment on http://brian.moonspot.net/php-coding-standards http://brian.moonspot.net/php-coding-standards

by ohwp 14y ago

itafroma 14y ago

Good advice, with a couple of caveats about PSRs: - They're not all about coding standards: only two of them are. PSR-0 is a class autoloading standard and PSR-3 is a common interface for loggers. The next PSR is likely going to be a common caching interface. - PSR-1 and PSR-2 are controversial (although PSR-1 less so than PSR-2), and don't necessarily represent best practices amongst the larger PHP community. They're useful insofar as the PHP Framework Interoperability Group (PHP-FIG, http://www.php-fig.org/ http://www.php-fig.org/), the people crafting the PSRs, needed an internal standard and really shouldn't be represented as anything more than that. Much of both standards are an amalgam of individual practices produced via an internal survey of PHP-FIG member projects. If you have nothing, PSR-1 and PSR-2 aren't bad places to start, but diverging from them is more likely to happen than not, especially if you're working with projects or teams that have existing coding standards.

h2s 14y ago
> PSR-1 and PSR-2 are controversial > Much of both standards are an amalgam of individual > practices produced via an internal survey of PHP-FIG > member projects. Those member projects include codebases like Zend Framework, Symfony, Composer and Doctrine. Those standards are are a very accurate representation of the way the best, most popular open source PHP code is being written. The only controversy I'm aware of is those petty pull requests opened by people who didn't like that they chose spaces over tabs, which eventually drove one of the founders of the group to quit out of frustration.
- itafroma 14y ago
  > Those standards are are a very accurate representation of the way the best, most popular open source PHP code is being written. PHP-FIG members have repeatedly cautioned[1][2][3][4] that the PSRs (notably PSR-2) are not a set of best practices, but merely a survey of commonalities of PHP-FIG member projects. Even then, several member projects do not, and have stated they will not, implement PSR-1 and/or PSR-2. Treating them as the best or most accurate representation of how PHP is being developed at large is exactly the wrong thing to take away from the PSR process. [1]: http://www.php-fig.org/faq/ http://www.php-fig.org/faq/ [2]: http://paul-m-jones.com/archives/2420 http://paul-m-jones.com/archives/2420 [3]: https://groups.google.com/d/msg/php-fig/TRpoq0kdrZk/OkyD-J4uz8sJ https://groups.google.com/d/msg/php-fig/TRpoq0kdrZk/OkyD-J4u... [4]: Matthew Weier O'Phinney's comment on http://brian.moonspot.net/php-coding-standards http://brian.moonspot.net/php-coding-standards