William Durand has a new post to his site sharing not only the slides from his recent presentation on SOLID vs STUPID code but the same content written out. It provides a great overview of the two concepts and some examples of what to avoid. There's also a recording of the session you can listen to via the in-page player.

Last week I gave a talk about Object-Oriented Programming at Michelin, the company I am working for. I talked about writing better code, from STUPID to SOLID code! STUPID as well as SOLID are two acronyms, and have been covered quite a lot for a long time. However, these mnemonics are not always well-known, so it is worth spreading the word.

In the following, I will introduce both STUPID and SOLID principles. Keep in mind that these are principles, not laws. However, considering them as laws would be good for those who want to improve themselves.

He starts with the STUPID concepts first - Singleton, Tight Coupling, Untestability, Premature Optimization, Indescriptive Naming and Duplication. He goes through each of these and explains why they're bad things to have in your code. He then gets into the SOLID ideals - Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle. These are a bit more complex to understand but he does a good job (complete with code snippets) of each. The slides for his presentation are also included but they're just a high level look at the same concepts from the article.

Nikita Popov talks about the SOLID coding practices and creates his own acronym for the complete opposite - STUPID (Singleon, Tight coupling, Untestable, Premature optimization, Indescriptive naming, Duplication).

Ever heard of SOLID code? Probably: It is a term describing a collection of design principles for “good code” that was coined by Robert C. Martin (aka “uncle bob”), our beloved evangelist of clean code. [...] So, why not approach the problem from the other side for once? Looking at what makes up bad code.

He goes through each part of his STUPID acronym and talks about how it can hurt your code and a few alternatives to help make your application more flexible and easier to maintain in the long run. He also mentions GRASP (General Responsibility Assignment Software Principles), another set of good practices to follow, some similar to SOLID, that can make your app better.

Most of the bugs that get reported to the PHP project are pretty useful. They help developers track down those small, random issues that might slip through the cracks otherwise. There are, however, some of them that make you wonder a bit about the person that submitted them Scott MacVicar takes a look at a few of them in a new blog post.

Recently the PHP project has been receiving an increasing number of rather silly reports, these vary from simply not reading the manual, searching the internet or a fundamental lack of understanding how the internet works.

He points out three in particular (from the same person, no less) about things that shown an almost complete lack of understand of what PHP does. One was a request to make PHP use less CPU and another asking to make PHP censorship free and, finally, a request to make PHP more secure...by doing away with support for cookies.

Scott also suggests a few constructive things you can do before submitting a good (useful) bug report:

• Gather together as much relevant information as you can (generalizations are bad)
• Run performance checks against older PHP versions to try to pin down when the bug was added
• And, finally: "don't get aggressive or be an asshole when your bug reports get closed".

According to Felix Geisendorfer's newest post on the Debuggable blog, he thinks that "private and protected methods and properties are one of the most stupid concepts of OOP."

This is a thought I first shared at CakeFest Orlando this year, but could not explain properly at the time.

He illustrates with an example of a protected "balance" variable in a BankAccount class. Sure, it's marked as private but less skilled programmers might not use it that way. He recommends a method without the getters/setters to help make the usage of the variable a bit simpler. He also suggests that using protected/private scoping helps to promote "crappy code" - using them to provide a sort of protection for code that you either don't want getting used or hiding it away so the API can't get at it.

Brian Moon has a "stupid PHP trick" posted to his blog today - normalizing SimpleXML data you've pulled in from just about any external source.

Anyhow, one annoying thing about SimpleXML has to do with caching. When using web services, we often cache the contents we get back. We were having a problem where we would get an error about a SimpleXML node not existing.

They were using memcache to store the information but came across problems when their code tried to use a (sometimes) empty tag. He gives two solutions - one using a recursive function that identifies the empty items and the other that encodes then decodes the object to and from JSON, keeping the values intact.