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.

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

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

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

rdohms Rafael Dohms
object calisthenics 😛

jimbojsb 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
Yes, it does. Because you’ll inevitably add features. Tests ensure what you do doesn’t break other stuff. /cc @chartjes

 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

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

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

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

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

jimbojsb Josh Butts
source control. source control. source control.

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

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

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

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

chartjes Chris Hartjes
WRITE TESTS OR I WILL CUT YOU /cc@JeremyKendall

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

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

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

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

JeremyKendall Jeremy Kendall
Version control. Always.

singlespl 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

[EDIT]

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.

[/EDIT]