less_retarded_wiki/programming_tips.md

Programming Tips

This is a place for sharing some practical programming tips.

• Add by small steps: When adding features/functionality etc. into your code, do it by very small steps and test after each step. Do NOT add multiple things at once. If you add 3 features at once and then find out the program doesn't work, you will have an extremely hard time finding out the bug because it may be in feature 1, feature 2, feature 3 or ANY COMBINATION of them, so you may very well never find the bug. If you instead test after adding each step, you find potential bugs immediately which will make fixing them very quick and easy.
• No indentation for temporary code: Tiny "workflow" tip: when adding new code, keep it unindented so that you know it's the newly added code and can delete it at any time. Only when you test the added code, indent it correctly to incorporate it as the final code. Of course, this fails in languages where indentation matters (Python cough cough) but similar effects can be achieved e.g. by adding many empty lines in front of/after the temporary code.
• Program on a weak computer, this will "force" you to make your program efficient (and learn how to do it), any inefficiency will be immediately apparent as your program will simply run slow or swap. Small embedded devices such as open consoles are ideal.
• Comments/preprocessor to quickly hide code: It is a basic trick to comment out lines of code we want to temporarily disable. However preprocessor may work even better, e.g. in C if you want to be switching between two parts of code, instead of constantly commenting one part and uncommenting the other just use #if 0 and #else directives around the two parts. You can switch between them by just changing 0 to 1 and back. This can also disable parts of code that already contain multiline comments (unlike a comment as nested multiline comments aren't allowed).
• KEEP IT SIMPLE and keep it LRS, do not blindly follow mainstream ways and "workflows" as those are more often than not horrible. For example instead of using some uber bug tracker, you should use a simple plaintext TODO.txt file; instead of using and IDE use vim or something similar. Stay away from OOP, dependencies etc.
• Don't listen to advice of anyone who does programming for living, he's most definitely accustomed to the worst ways of programming and will try to push you to OOP, bloat, proprietary tech, tranny software, GitHub etc. Listening to advice of such people is like taking advice on whether to take drugs from a drug dealer.
• Most true programming is done away from the computer -- soydevs think that a good programmer just spends hours in front of a computer bashing the keyboard and drinking litres of coffee to stay alive and PRODUCTIVE; indeed, they usually do, but they are not good programmers, their time is spent slaving the computer doing maintenance, debugging, googling, updating and socializing on Twitter. A good programmer actually programs everywhere: when going for walk, before falling asleep, when sleeping, when watching a movie etc. He only starts writing a serious program after years of thinking about it and already having most of it programmed in his head; sitting in front of a computer and writing the algorithm down is only the final smaller part of the journey.
• It can't be repeated enough times: minimize ALL kinds of dependencies, don't use what you don't necessarily need -- this doesn't just apply to libraries but also design decisions. E.g. if you're making a compiler, make it a single pass compiler if at all possible, don't perform several source code passes if that's not absolutely necessary (which would however likely signify some flaw in the design of your language). Use fixed point instead of floating point if you can, software rendering instead of GPU rendering etc. If you're making something that transforms text to another text (e.g. machine translation), make it a filter with constant memory complexity if that's possible, i.e. do not require the program to load a whole input file to memory. Etcetc.
• During development turn off optimization flags for faster compiling and turn on verbosity and various checks, e.g. -Werror -Wall -Wextra -Wpedantic for C.
• By Unix philosophy don't be afraid to throw away your code and star over and better -- next time you'll most likely write the same program a lot better and if you're a Unix programmer, your programs are small, possible to be reimplemented in hours or a few days.
• TODO: moar