The topic of developing great code can be long and boring. So, for the readers I’ll make this humorous and shorter, list style, because everyone loves lists!

#1. Commenting Code or “Fifteen Pieces of Flare Is The Bare Minimum”

You’re happily coding along, php, c++ or otherwise (hey, even Javascript) and it hits you! The most awesome line of code in the world, it does all you ever desired and more with only a single line of code chained with some funky “if” statement and a regular expression. You want to show it to your friends but you know they won’t care or understand what you’re talking about.

What do you do? You sit back, proud of your creation, test it and move on thinking “wow, I just leveled up my coding stats.” WRONG. You did the exact opposite, you actually got more dumb. Why? Because six months from now you may find a bug or want to add some new code features and you’ll come upon that utterly creative line of code and think to yourself “hmm, what does this do?”

You have no idea. You know it was cool at the time, but you’re lost on its actual purpose. Why? Because you left out the damn comments and you now have to re-trace your steps to guess what it is supposed to do. Second guessing yourself, you find a “bug” in the line… you thought you were a creative bastard but you really screwed up something bad; something you hadn’t considered before.

You re-write it and feel good about it, and move on. Lo-and-behold all your code breaks down and things just don’t work the same (or at all) anymore. No PHP errors or linker errors, but things just aren’t working right. Why?

Because that line of code wasn’t broken at all, you had a very specific reason for doing it and you lost it all when you decided to retool that line of code. Now, imagine how that would have played out had you left a little comment block explaining your reasoning for it’s creation. Imagine how much time you would have saved having to go re-generate that genious six months later.

Comment your code, for both yourself and others. Don’t do the bare minimum and comment a function header or script header - comments are there to help recall historical actions and explain to yourself and others why you did something. Go above and beyond the minimum.

#2. Consistency Makes The Soul Grow Fonder

You ever write a bunch of code/script and try to tuck it away so nobody else can see it? You do this because you know its ugly, unprofessional and you get defensive if someone says “hey, I can update it for you, send me the file.” You wish you would have done it differently but it’s too late, the code is not manageable and you know “someday I’ll re-write it better.”

That someday could be day-1 if you just took the time to be consistent in your practices. You like to pass arrays instead of a bunch of variables in a function? Fine, do it everywhere. You like to use a specific style to making logic blocks? Fine, do it everywhere. You always use double quotes over single quotes when using strings, do it everywhere.

One way to avoid “spaghetti code” is to write code that is consistent in all the functions and files. It doesn’t have to be a beautiful piece of art if a reader can get a sense for what you’re trying to do and learn it. Once someone learns the style they’ll read the rest of it easier.

Nobody writes an essay or novel partially in English with pen, chapter 2 in French with crayon and the end in German (ya know, the part with all the verbs) in pencil. Consistency will lead your readers to know what to expect, even if it is to expect unprofessional techniques.

#3. Return Once, Read Many

Nothing is harder to read than a routine that returns eight times in a single function. Especially when the return statements are something like “true” and “false” and some of them are “true” while others are returning “false.” What exactly should the reader expect when reading it? They’ve got to predict eight paths of execution now and remember them as they go?

If you return once in every function (that’s consistency, see bullet #2) you’ll have code that reads easier. It will require you to work harder when coding because you’ll have to think ahead “what are all the possibilities of returns” and plan ahead - but planning and anticipating are never a bad thing when coding.

So many people say “it’s too hard to do that” and just go about it the old fashion way because that’s what “everyone else does.” Don’t be a sheep, be a leader, show people just how professional your code can be. Do the right thing, just because MIT developers return a billion times per function doesn’t mean you have to as well

If an MIT graduate jumped off a bridge would you do it too?

#4. PHP Is Not An Excuse To Write Crappy Code

“It’s just scripting, I don’t have to be pretty.” That’s a ton of BS, actually it is more important to be pretty because the language is so open-ended and allows you to break most programming rules. Just because your rules are less strict it doesn’t mean you can break them.

If you go to a country that allows you to smoke marijuana are you going to break your own personal rules just because you can? Okay, bad example…but you know what I mean.

Scripting languages like PHP and Perl will let you get as creative as you want, but creativity makes complex code almost every time. When you think you’re being totally creative to “save CPU cycles” remember, you’re not in C anymore Toto - resources are not as large of a factor considering the language is a higher level and resource management is somewhat up to the interpreter.

You can create an “if” statement in a few ways using PHP and even more in Perl, this doesn’t give you a license to use them all. You can recycle variables like it was your job, but creating unique understandable names will save you time and energy later.

Pretend you’re coding in a “real language” and use the same rules that inspire other professional software developers. Not only will you be proud of your work, but you’ll be able to show it off to others and perhaps do it for a “real job” someday (if you don’t already).

#5. Don’t Re-Invent The Wheel

Unless you’re doing research or have a ton of free time, there is no reason for re-coding routines that already exist. First, PHP has a ton of resources readily available “as is” but the community does a great job explaining specific features, tools and creations. If you’re working in a CMS, first look for a module to see if it does what you need. If you’re working on a javascript or cascading style sheets (CSS) like drop-down menu’s look for resources on the Net - they exist all over the place.

Should you feel bad using someone else’s code and not using your own brain? No, because you can utilize that free time to create your own custom modules that provide the “wow factor” or are required for something that doesn’t yet exist in the community (it’s your choice to give back as well).

For instance, Drupal doesn’t have an international shipping estimator for their e-commerce package so I wrote one myself based on the domestic version. I had to, it didn’t exist. I didn’t however, re-write my own full e-commerce solution, I used one that already existed. That saved me free time to code an international shipping module.

Not all modules will do what you need, unfortunately. So you may utilize them and “hack them” to do what you need or use them as a learning tool to re-tool your own software. I did this with the e-commerce coupon module that is supplied with the Drupal e-commerce modules. The coupon module is lacking many features that would make life easier for me, such as promotional coupon codes. So I’ll do it myself in my own coupon system.

Use what exists, learn from what doesn’t fit your needs and spend more time working new ideas and less time designing software which has existed in the community for years.