Programming Tips
This is a place for sharing some practical programming tips.
* Add by small steps, spare yourself [1]debugging hell later, do one
step after another (see also [2]orthogonality): 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.
* Program on a weak computer or alternatively use some utility such as
[3]cpulimit to make your hardware weaker, this will help you make your
program efficient (and learn [4]how to do it), any inefficiency will
be immediately apparent as your program will simply run slow or swap.
Using a physically weak computer is best as it is limited in all
aspects so it will also help you make the program easy to develop on
such computer etc., small [5]embedded devices such as [6]open consoles
are ideal.
* Jerk off before programming: This will make you think less about sex
and focus better.
* 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 ([7]Python cough
cough) but similar effects can be achieved e.g. by adding many empty
lines in front of/after the temporary code.
* [8]Comments/[9]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).
* [10]KEEP IT SIMPLE and keep it [11]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 [12]vim or something similar. Stay away from [13]OOP,
[14]dependencies etc.
* Never listen to advice of anyone who does programming for living (not
[15]anymore), he's most definitely accustomed to the worst ways of
programming and will try to push you to [16]OOP, [17]bloat,
[18]proprietary tech, [19]tranny software, [20]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
[21]PRODUCTIVE; indeed, they usually do, but they are not good
programmers, their time is spent slaving the computer doing
[22]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
[23]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 [24]fixed point instead of
[25]floating point if you can, [26]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 [27]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 [28]C.
* By [29]Unix philosophy don't be afraid to throw away your code and
start 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 quicky. This has even been
generalized into a wisdom that says "plan to throw away one", i.e.
when approaching a new issue, you quite frequently start writing a
program you know you will throw away when it's finished, just to start
over and better; the first program just serves to help you understand
the true essence of the problem and foresee the real problems you will
face.
* Go out! This is related to the other point -- you shouldn't just sit
at the computer when programming, get up and go for a walk, do
something else, take a shower, go swim, do something in the garden,
repair some stuff or something like that. Fresh air and sunlight helps
the brain, it makes you feel better and it's been shown that walking
helps activate some important brain centers, many people [30]actually
say they have to walk when thinking hard { Can confirm. ~drummyfish }
Changing your environment and getting out of the current focus on the
letter on the screen can kick off some real great idea, seeing
seemingly unrelated things in nature can spark some inspiration. If
you're stuck, take a day off, just sleeping and approaching the
problem fresh does miracles. This really does help. It may help to
carry around a blog for taking notes so that you don't have to stress
about forgetting the ideas -- prefer paper blog, leave all electronics
at home.
* Insert funny [31]hexadecimal constant in your program such as
0xED1B1EFAECE5.
* TODO: moar
Links:
1. debugging.md
2. orthogonality.md
3. cpulimit.md
4. optimization.md
5. embedded.md
6. open_console.md
7. python.md
8. comment.md
9. preprocessor.md
10. kiss.md
11. lrs.md
12. vim.md
13. oop.md
14. dependency.md
15. 21st_century.md
16. oop.md
17. bloat.md
18. proprietary.md
19. tranny_software.md
20. github.md
21. productivity_cult.md
22. maintenance.md
23. dependency.md
24. fixed_point.md
25. float.md
26. sw_rendering.md
27. filter.md
28. c.md
29. unix_philosophy.md
30. ackchyually.md
31. hexadecimal.md