I started an online python course some days ago and part of the assignment is to peer evaluate other peoples code. The task was to print a message on the screen. Yes, I know, a boring task.
There I came upon something like this:
string = "xdxlxrxoxW xoxlxlxexH"
string = string[::-2]
And this, in three lines, is the essence of problems I’ve encountered over the years with big complex projects and legacy code. Remarkably it seems to be a trap each projects “Super-Programmer” falls in…
1. Show-off programming
It’s okay to be proud of ones knowledge but, come on, this is about the job, not your ego.
2. The code is the documentation
NO, definitely not, code is just a small part of any bigger or more complex project. There ususally are configuration, directory structures, external dependencies (libraries) etc. Put it somewhere to be seen, the init file, a readme, a getting-started txt file but don’t assume.
3. Don’t oversmart
You found this very cool, super cryptic looking function that does unexpected thing… Yeah, probably use something that can be understood right away or at least leave a comment about what it does.
4. Modularize to death
Especially in ruby (but any other language as well) I found many people building modules around simple functions, meta programming things to bits and doing stuff they found in years old posts somewhere.
Those techniques are all good and useful at times but not every function is predestined to be reused in another project, so why not declare it a helper function?
1. Write code that can be read with by an average coder, not just by the “Super-Programmer”. Projects or companies dev teams seldom have an even knowledge distribution. (And in most cases you don’t even want that.)
4. Put your ego aside. I rarely think stuff like “Oh my, he/she came up with a fancy solution”, mostly it is along the line of “WTF! Why didn’t he use the obvious solution?” So if there is a reason for doing it differently go back to point 2 or 3.