Getting wiser, dev-wise

Stick figure on a lawn yells at two other stick figures to get off the lawn

Almost a decade ago when I was getting into real-er programming, read Java, I thought that the best practices how to write code are overrated. I could understand my very long functions. I had no reason why to comment because a lot of my code didn’t last long.

I admit I was cocky when I was 20 when it came to programming because throughout high school I had two friends who were way better than I was and in four years I couldn’t catch up to them. That chasing made me well above average programmer in my class and when I went to university I still aced my first three programming classes (basic Java, advanced Java with basic C and VHDL with NIOS assembler) on my own.

I wrote stuff that would make me cringe. Not from technical point of view I wrote some interesting things which I am not sure I would write today. We have more available libraries now. But from social point of view they were awful.

Length of functions

Reading your own long functions is mostly ok but reading someone else’s is dreadful. I had no problem writing function 100, 200 lines of code long and didn’t see a problem with it except I had to listen my TA warning me that they are too long. After working with more complex and legacy code written by a dozen or so other developers I can say that she should’ve told me to rewrite it and until then not accept it as done.

Having a lot of shorter functions will make it easier for you to debug your program because

  1. it’s easier to see what’s happening in a function when you don’t have to scroll
  2. when you throw an error you can trace it to a certain function

These days when I write a function I try to write less than 40 lines of code. But occasionally I’ll write more when I am working with my display in vertical mode because I simply don’t realize it and when working with switch¬†es1.


It’s easy to write code, it’s apparently hard to explain why you did it when you did it. Earlier this year I worked with a technology which will be soon deprecated and with poorly2 documented framework. When you write code and don’t document whats and whys you are turning the developer who will come after you into an archeologist, not Lara Croft type, not Indiana Jones type and definitely the not Daniel Jackson type. You are turning them into an archeologist whose specialty is Urnfield culture3.

I beg you write at least {Java|PHP|WhatEver}Doc before you let your code into production, preferably before you close a ticket or a bug. If you write a hack out of necessity describe it near the hack or write down in wiki/documentation your thought process and add a comment to the hack with url.


I am guilty as charged, it’s dyslexia’s fault4, when it comes inconsistencies with semicolons but I’ll say it anyway. If your language doesn’t care whether you use them or not you should care. But it might just my pet peeve when I see a code where lines with semicolons and without them are mixed. It’s not visually pleasing. Try to keep a style.

This is all what I wanted to say. Think of the developer who comes after you as a potential friend and ally and don’t make them hate you.

  1. This makes me miss Scala’s pattern matching
  2. “Poorly” is an understatement
  3. There is nothing wrong with them except we don’t have to keep Urnfield culture’s tech alive and kicking
  4. Blamestorming, right?