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.
- Do I have to write this function?
- 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:
- What if that argument is null?
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"?
#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 ...
- All be aligned to the right.
- Cancel is always on the far-right. No exceptions.
- The affirmative/accept/ok/whatever on the inside closest to center.
- Other buttons go in-between the OK and Cancel.
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.
#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.
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.)