40 signs you really are a lousy PHP programmer
Disclaimer: This collection was published a few years ago on my blog, it was met with heavy criticism about featuring micro-optimiziations which have little to no effect at all compared to other things you can do which was then and is still today very true 
As this was copied & published on a few hundred blogs in the aftermath here again the original list exactly as I published it many years ago.
I will follow up shortly with an article on more effective methods. Until then …
This is something I prefer to call my “programming list of shame”. Although having a formal university education with courses on software engineering, enterprise software architecture & database design I have been guilty of every single one of those things at one time or another. This is completely subjective & Eclipse oriented.
You are a lousy PHP programmer if you
- don’t comment your code properly with something like phpDoc
- don’t see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
- have never used some form of version control like Subclipse
- don’t adopt some coding & naming standards and general conventions and stick to to them at least throughout the project
- don’t use a consistent methodology
- don’t escape and/or validate properly input or sql queries
- don’t plan your application thoroughly before starting to code
- don’t use test-driven development
- don’t program & test with error reporting on
- don’t see the benefits of a debugger
- don’t refactor your code
- don’t keep the different layers seperated using something like MVC
- don’t know what these stand for: KISS, DRY, MVC, OOP, REST
- don’t return content but echo or print it from your functions or classes
- have never seen the advantage of unit tests or testing in general
- return HTML, not data, strings, or objects.
- hard code messages and configuration parameters
- don’t optimize your sql queries
- don’t use __autoload
- don’t allow intelligent error handling
- use $_GET instead of $_POST for any destructive actions
- don’t know how to use regular expressions
- you’ve never heard of sql injection or cross-site scripting
- don’t allow simple configuration, can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime.
- don’t understand the benefits and limitations of Object Oriented Programming
- misuse OOP / everything you write , no matter how small is OOP
- you think reusable software equals/requires your code to be OOP
- don’t choose intelligent defaults
- don’t have one single configuration file
- don’t want the file contents to be seen, but give it a .inc extension instead of .php
- don’t use a database abstraction layer
- don’t keep it DRY, Don’t repeat yourself. If you have to copy and paste or duplicate something your design may be off.
- don’t make a function/class/method do just one thing and don’t make them interact.
- don’t try to take advantage of OOP specific features like abstract/interface classes, inheritage polymorphism & access modifiers.
- don’t optimize your application design with established design patterns
- don’t allow your user to define a base directory if you have multiple files and/or directories
- pollute the global namespace, one option is to prefix the functions in your library with a common string
- don’t allow a table prefix when using database tables
- use a separate template engine
- don’t take a look at established php frameworks for inspiration, most of them have advanced web dev concepts and good code
By reading above options, i agree i m a lousy programmer
Okey, so this is a wonderful list, despite it’s OOP’y and Eclipsy bias. Two things that even subjectively surprise me:
4. Subclipse is an Eclipse plugin for using the version control system Subversion.
22. Unless you are a Regex fanatic there is often no need for regular expressions and many, if not all, programming languages have built-in functions for string comparison and manipulation that are faster; although they often provide an alternative to only a subset of regular expressions.
Otherwise, I totally agree with your list and I am convinced that it is not nearly as long as it could be. And sometimes I am a lousy programmer (so that could qualify as a lazy programmer).
very good, some coincil for development and implement
Forgive me oh gracious lord in the heavens! For I have committed the 40 sins of your commandment most often when time is short.
While I disagree with about half of it, some of it does make sense. The list does seem to be overly reliant on tools instead of skill and learning — But then I’ve not been a fan of “IDE’s” of late since they typically shoe-horn all the code into one window instead of letting you have your separate files open in separate windows so you can look at them side-by-side. (very handy on multiple displays) — it’s why I consider tabbed editors a step backwards in functionality. Likewise if you need a ‘tool’ to document your code, you probably have no business writing code… Likewise I’ve never had “version control” software do ANYTHING but piss all over any project I’ve ever tried it with — and in thirty years of coding that’s saying a lot.
Though you really hit it on the head with misuse/overuse of OOP. People are throwing objects at EVERYTHING these days for no fathomable reason. It is NOT the be-all end-all answer and yet people seem to be using it as such… there are a LOT of cases where static functions are better/more efficient… like single instance single call library functions.
… though in a lot of case I think things like singletons are used to make up for PHP’s complete lack of proper handling of nested functions and scope.
DRY is often funny since if you come from an assembler or C background you know two types of optimization — speed or size… and when you choose speed, you often HAVE to repeat yourself — “unrolling the loop”.
… and I agree wholeheartedly with #39 — template engines are for idiots when PHP is perfectly capable of doing theming all by itself. Oh noes, instead of using some idiotic bloated crap like smarty I have to have functions like theme_header, theme_footer, filled with echo statements that are no more or less complex than the templating engine.
Of course, if most PHP developers actually knew enough HTML or CSS in the first place… but of course one look under the hood of most forum, CMS and blogging systems it becomes DREADFULLY apparent most people writing PHP don’t know enough HTML to, well… be writing scripts to pre-process jack ****!
Just like how most PHP developers don’t know enough about accessibility either pissing out inaccessible fixed width layouts, inaccessible fixed metric (px) fonts, with inaccessible illegible color contrasts…
Like this site, where I had to zoom in 60% and apply a custom stylesheet to even read it. Of course with the idiotic “nested conditional HTML tag” crap by Paul Irish, endless pointless DIV, nothing remotely resembling semantic markup, improper use and abuse of heading tags, inaccessible/incomplete forms, and use of HTML 5 idiocy to double the markup needed to build the page, it’s kinda hard to take your list seriously. You’d almost think this site was crapped out in turdpress.
Pingback: Javier's Blog » 40 signs you really are a lousy PHP programmer
I can disagree with minor parts of your list, but its a good list. Some things in your list assume particular types of projects… like #36.. I’m not even sure what that means.
Also, #26… no, everything should be OOP, but not everything has to be an object. There is no reason not to approach problems with an object oriented pattern, especially if you’re using a framework, as mentioned in #40. If you often need to write small projects, then you probably should have a framework, or at least a “toolbelt” of methods you carry around so that you’re not rewriting mysql_connect() each time.. and since that set of tools is used on lots of projects, then the tools themselves could be considered a larger project in their own right.. and would benefit from being OOP. As you improve the framework, or toolbelt, over time.. as with core bug improvements or security fixes.. you’d expect (or hope) that the new toolbelt remains backward compatible with all previous projects. No better way to do that then OOP.
But, there are times, when spawning 1,000,000 objects drags the app to a halt, so.. not everything needs to be an object.
It also looks like Jason Knight is a prime candidate for this article, which is not surprising since he’s been coding for “30 years”… its just the way of it.. older coders have too much to unlearn to adopt the new patterns.
Notable items:
- Likewise I’ve never had “version control” software do ANYTHING but piss all over any project I’ve ever tried it with
Version control can be crummy, but not once you’ve mastered it. Too often people use version control to be something it’s not.. i.e. backup system, or use it in place of a CI. That said, its absolutely required if you have more than a handful of developers, and provides far reaching benefits even if its only you.
- Likewise if you need a ‘tool’ to document your code, you probably have no business writing code
If you don’t need a tool then your project is too small to be considered for any serious discussion. The tools do not write the docs, they just make it easier to write the docs. Our “API Documentation” (which I’m sure is a term you’ve never even used) is written in-line, using doc comments, generated using Doxygen and interpretted in our IDEs via phpDocumentor.
All extremely useful stuff, and if you’ve ever worked with more than, say, one developer.. you’ll know that getting a developer to write documentation, of any sort, is like pulling teeth. It’ll look crappy, even if they write it.
- But then I’ve not been a fan of “IDE’s” of late since
Virtually anything you can think of to say bad about IDEs, they make up for it within 10 seconds of loading up. But given that you hate just about everything about modern coding, like OOP, VCS, Source Documentation, and color monitors, you’re right.. you probably don’t get anything out of IDEs. Do your thing man, give that VIM hell..
But yeah, its cool.. Jason has just probably never had to work on a large project, or with a lot of people. Its understandable.. every type of coder has a place… just don’t get near our VMs with your punch cards.
–
So, in all, its a good list for a beginner. I’ll add a few, just for your own consideration:
.. if you’ve never even considered anything other than SQL for long term persistence
.. if you have more than one publicly accessible php file in your projects
.. if you think you’re both a good designer and a good coder
.. if you cannot immediately define abstraction, modularization, ORM, and ACM
Also, at @RalfMC — regex can turn 100 lines of code into a single line of code, no kidding. Not say I don’t use str_replace, because I use the shit out of it, but being able to use regex when its time to use regex requires a mastery, and nothing can replace that.