What programming rules should you ALWAYS follow

Earlier today, more for my own interest, I asked the question on Twitter “What programming rules should you ALWAYS follow, regardless of the scenario you’re working in?”  In other words, are there programming rules that you ALWAYS should follow.  It doesn’t matter if it’s a script to copy a bunch of files for a one time migration or if you’re building the next Facebook (DON’T try to build the next Facebook.  You will fail miserably.  Build something else).  In other words, what was the purist of programming rules.

Here are the responses that I got.  I will pen some of my own thoughts afterwards.

always comment your code. Readability is key if you ever want others to understand how something is supposed to work.

Giorgio Sironigiorgiosironi Giorgio Sironi
I found that many “clean code” rules are subverted when developing for embedded systems

Giorgio Sironi

giorgiosironi Giorgio Sironi
if there is money or possible downtime involved, yes 🙂 /cc @weierophinney

Rafael Dohmsrdohms Rafael Dohms
object calisthenics 😛

Josh Buttsjimbojsb Josh Butts
@weierophinney pragmatically, no, i wouldn’t test that. I’d tell others to though. Do what I say, not what I do and all that.

weierophinney weierophinney weierophinney
Yes, it does. Because you’ll inevitably add features. Tests ensure what you do doesn’t break other stuff. /cc @chartjes

Marc Towler MarcTowler Marc Towler (editorial: My heart skipped a beat because at first I thought that said Martin Fowler)
only lightly comment functions or anything that might be difficult to understand

Sean Prunkasprunka Sean Prunka
never tested? or never written tests for? because if you used it even once before putting into production, you tested it.

Shaun Farrellfarrelley Shaun Farrell
real devs don’t need tests… @chartjes@JeremyKendall

Jeff Carouthjcarouth Jeff Carouth
You forgot “source control.” /cc @kpschrade

Sean Prunkasprunka Sean Prunka
version control, regression (or unit) testing, documentation (comments, self-documenting code), easy to read code.

Josh Buttsjimbojsb Josh Butts
source control. source control. source control.

Jeff Carouthjcarouth Jeff Carouth
Meaningful names. Revision control. Consistent structure. Asserts/validation/defensive. Write tests.

Marc TowlerMarcTowler Marc Towler
if you have to think what it does, comment it

Adam Lundriganadamlundrigan Adam Lundrigan
Always write reproducible tests of some form…and, like @robertbasic said, always use a VCS. Always. ALWAYS.

Robert Basicrobertbasic Robert Basic
heh, might fit into the “always use a VCS” category then? 🙂

Chris Hartjeschartjes Chris Hartjes

Robert Basicrobertbasic Robert Basic
no matter how small and simple that script is, you’ll need it one day. keep it.

Jeremy KendallJeremyKendall Jeremy Kendall
Testing is ideal, but I’m not sure it’s a rule you can *always* apply, regardless of the situation. /cc @kpschrade

Jeremy KendallJeremyKendall Jeremy Kendall
There is no such application 😉 /cc @chartjes

Chris Hartjeschartjes Chris Hartjes
write tests to make sure you didn’t break anything else

Jeremy KendallJeremyKendall Jeremy Kendall
Version control. Always.

Radoslaw Benkelsinglespl Radoslaw Benkel
“Think. Think again. Then write code”.

The one that I had not thought was “no matter how small and simple that script is, you’ll need it one day. keep it.”  I have written so many little one-offs that had something that was copy-worthy in there.

I don’t think that unit tests would fall into the ALWAYS category.  Clearly you should be building and running unit tests in typical development work but there are plenty of scenarios where unit testing is completely unnecessary or counter-productive.  For example, unit testing a shell script is almost pointless.

Some other thoughts on what you should always do are

  1. Use a debugger.  Those of us who are good (I consider myself mostly lucky) take this for granted.  But how many issues on StackOverflow could have been figured out in half the time if the person had just run a debugger.  It’s not like this is compiled code you WILL have the source code.
  2. Source Control.  Yeah, this may seem overkill for some projects, but for those projects it’s a good place just to store your code in case you need to copy it later on.  Therefore, it’s always useful.
  3. Logging.  Even if it’s a shell script and it’s logging to the screen, tell your user what you’re doing, even if the user is only you.

That’s all I have for now.  If you have any unbreakable rules of programming feel free to put them in the comments


Paul Verhoeven (I presume he is different from the one that did Starship Troopers, Total Recall and RoboCop) said “i’m missing the worldfamous #RTFM / reference / apidocs and the inmost cases undeniable #PICNIC & #PEBKAC.”

We’ll make that #4.


10 Thoughts to “What programming rules should you ALWAYS follow”

  1. 1. Keep code clean and with well indentation. Never keep lot of commented code in files of server/SVN repository.
    2. Never use tabulations in the code. Indentation is done by steps of 2 spaces
    3. Use camelCase, not underscores, for variable, function and method names
    4. Use underscores for option/argument/parameter names.
    5. Braces always go on their own line.
    6. Don’t put spaces after an opening parenthesis and before a closing one.
    7. Do not insert HTML tags within PHP.
    8. Write the code including English documentation comments.
    9. If you use version control system for the code (svn, cvs), never upload files with passwords or absolute paths.

  2. Keeping code clean & document as much as possible works for me.
    Everything else like VCS/Tests/CI server/blahblah is good, but not a “Do or Die” type of things

Leave a Reply

Your email address will not be published.