Coding Properly.

Language agnostic guidelines for not writing garbage code.

#1. Be lazy!

The fastest code is the code that didn't exist in the first place — presume your computer is a lazy git.

Ask yourself:

  1. Do I have to write this function?
  2. What would be the most efficient placement of this code, such that it won't run? Here's a clue — "Aarrrr!! Hoist me matey!"

#2. Stop being so feckin' lazy!

Just because somebody has written a necessary bit of functionality that resides in a library, many times that bit you need is a single class or routine which you could much more efficiently knock out yourself in 100 lines or less.

Prefer your own code over other's. The often parroted advice that you should always use pre-written, presumptively tested, 3rd party components is balderdash. From my 17 years experience there have been few exceptions where a 3rd party library would not hinder maintenance, introduce security vulnerabilities, increases build complexity, increase deployment footprint or result in crap runtime performance on the server or client. The exceptions are things like video codecs*, math libraries, or syntactic sugar such as the Standard Template Library (STL) which inlines during compilation.

* Most of the time - containers not necessarily.

#3. Write defensively

Assume every argument of the function you are writing will be either null or an unexpected value at some time.

With every opening statement ask yourself:

  1. What if that argument is null?
  2. Is this function likely to be a hot path? (ie called thousands of times per second.)

    If the answer is No:
    Null-check and value check everything.

    If the answer is Yes:
    Null-check and value check everything, but from a higher level caller. And then also "debug assert" your null-check and values if the performance hit is tolerable.

#4. Everything bytes.

100% of all languages end up as byte code — a list of goto statements fed to a CPU. Consider your compiler.

When writing any statement ask yourself "what do these instructions probably look like"?

I encourage every interpreted language developer to take a weekend crash course on x86 assembly and to try writing some 'Hello World' C code, compiling it, looking at the emitted assembly output, and then reproducing it by hand in ASM. Play around a bit, make it call another function and do something with memory and variables. You will gain insight into the complexity of what your C#/VB.Net/Python/Javascript language is probably emitting at runtime, and what the implications are of the whole push/pop stack based register model.

#5. Be consistent.

Not just in your code, also in your UIs.

How do Google have half of the planet's money and yet they can't even put buttons the right way around? or at least in the same order or location consistently across their products? It's a disgrace.

A lot of people hate Microsoft, but one gift somebody who worked there once imparted upon the world was a familiar and consistent UI design language.

If nothing else, for the design challenged:

Except in rare scenarios where your dialog is a piece of artwork or perhaps a remote-control driven TV based UI ...

  1. Buttons should:
    1. All be aligned to the right.
    2. Cancel is always on the far-right. No exceptions.
    3. The affirmative/accept/ok/whatever on the inside closest to center.
    4. Other buttons go in-between the OK and Cancel.
    Correct button placement Incorrect button placement
  2. Make sure all headings, text, labels, paddings and margins vertically align against one another. You should be able to draw straight imaginary lines on the left/right edges on all of the things on your application's screen.
    Consistent alignment

#6. Code on shitty hardware.

If you want to learn how to write efficient software you need to force yourself to develop on the suckiest piece of suck that ever sucked.

There's a balance to strike between 'staying productive' and limiting your development environment to specs that your end-users are actually going to be running your software on. Be that desktop applications, DirectX/OpenGL games, or just a javascript web application. Depending on your work's problem domain, it may be a good idea to debug your application exclusively on a 2GB RAM non-SSD disk drive machine. When a customer does run it on modern hardware, its runtime performance will be fantastic.

It doesn't help that Visual Studio has turned into a RAM and CPU hog over the years, making working on down-level, non-SSD machines unbearable. I write this as I glare at the VS "Background Intelligent Transfer Service" in task manager hogging 50% CPU and the "Visual Studio Background Download" service hogging another 24% sustained for the past hour — "Reckon that's a bug." (If it's not we should be embarrassed for the Microsoft employee who wrote it.)