No more bloated and inconsequential lists please
Why oh why do people make lists like this, it seems like our dear Reinhold just had to cram 40 things in there.
However, more is not better and this list is a perfect example that quantity rarely makes up for quality. Some of it is totally irrelevant to the article’s title which states that this is a list of “40 signs you really are a lousy PHP programmer”.
Granted, some points on the list should be there in my opinion too but you are not a lousy PHP programmer if you:
1.) don’t comment your code properly with something like phpDoc
This point is completely irrelevant, you don’t comment code with phpDoc, phpDoc parses your comments and creates a good looking documentation for you. This can be done at any time provided that you commented your code in the first place which is what the point should have been about. The points in a list should at least hit their mark. It should’ve looked something like this:
1.) don’t do proper comment blocks that can be parsed by something like phpDoc. At the END of the project mind you. Usually it’s a waste of time to do these things in the middle of the project (if the team is not massive) because so much changes all the time that you would be spending more time writing documentation than code!
3.) have never used some form of version control like Subclipse
I would like to know how not following this point makes me a bad coder if there is me and another guy working on the project, or only myself? Points in a list should be more specific than this.
6.) don’t escape and/or validate properly input or sql queries
Depending on the project, doing this might just add time to it in order to create redundant security.
8.) don’t use test-driven development
Jesus, adhering to this point would be a massive mistake in a lot of small to medium sized projects. Besides, I prefer to test with users, not unit tests, that way I will actually end up with a final product that people will use sometime this century.
9.) don’t refactor your code
Why on earth would I want to refactor my code if it’s good enough to start with? Besides – as stated in point 7 – if I planned my project properly I shouldn’t have to refactor anything. If someone is refactoring all the time it’s probably a sign that he is a bad programmer, not good!
13.) don’t know what these stand for: KISS, DRY, MVC, OOP, REST
That’s probably the lamest point in the whole list. Could it be possible that maybe, maybe there is a chance that there actually are people who follow some of these principles without knowing these acronyms or having read the redundant piece of crap book that coined the acronym in the first place?
15.) have never seen the advantage of unit tests or testing in general
How is this point relevantly different from point 8? Keep The List Short Stupid! Don’t Repeat Yourself!
16.) return HTML, not data, strings, or objects.
I’m wondering as to which context we are referring to here? An Ajax call? Let’s pretend it’s an Ajax call. If I return JSON for instance, then the receiving javascript would have to be responsible for creating new DOM elements etc. So we got a lot of headaches but saved some minimal bandwidth, hallelujah! Oh it meant remote calls between PHP scripts? Why didn’t it say so!
18.) don’t optimize your sql queries.
How on earth am I supposed to have time to sit and tinker with my SQL when my deadline won’t allow it? Finishing on time and delivering something that works is priority number one. Optimizing queries can be done after the service has been launched, if the service in question takes off at all! My employer doesn’t pay me to act like some amateur with all the time in the world on his hands.
19.) don’t use __autoload.
I followed point 7 so I don’t need to autoload anything.
31.) don’t use a database abstraction layer.
Like so many other points in this list, but more than most, this one simply doesn’t make sense within the context of the headline. How can I be a bad PHP coder just because I don’t use an abstraction layer? Especially if I know exactly why I’m not using one?
32.) don’t keep it DRY, Don’t repeat yourself. If you have to copy and paste or duplicate something your design may be off.
Didn’t we cover this already in the lame acronym point? Don’t Repeat Yourself! No, it’s not OK to repeat yourself in lists either because it makes them suck and why would you want to write something that sucks just because you want more points on it?
38.) don’t allow a table prefix when using database tables
No I don’t, why? Why would I? I never work with stuff that is supposed to share a database with something else, hence no need for table prefixes. And again, how will not using prefixes make me a bad PHP coder per se?
39.) use a separate template engine
If one follows some of the other points on the list this one is redundant too.
Usually I’m a fan of lists, a proper list can be a good way to convey a lot in few words but half of this list is simply redundant crap or in some bad cases – misinformation. Just because you’re writing a list doesn’t mean it’s OK to write crap.
Granted, in bigger projects a lot of the points in the list become more relevant but the title makes no mention of that fact. I’m not kidding, if I adhered to the whole list I would be fired pretty soon.