Program Code Is For People, Not Computers
We use computers to help us solve problems. We write programs to tell computers how to carry out the tasks we determine to be most relevant to solving problems.
Program code makes a computer do things, therefore code is for computers. It's a seemingly logical conclusion, an easy mistake to make and certainly part of why programming is so very hard.
But the program code we write is for people, not computers. A computer doesn't understand Java, C#, PHP, Python or Ruby any more than it understands what you're reading right now. A computer understands machine code only, instructions encoded as little blips of voltage. Little blips of voltage go in and little blips of voltage come out. And that's all your computer will ever understand.
The problem is that people find it tricky to remember what sequence of blips of voltage do what, since 01010010 looks little different from 01010100 most of the time, writing anything more than something very trivial would just take too long and making any changes to a program would take just as long as writing it in the first place.
So programming languages came along and let people use simple English-like instructions to control computers. A few decades pass and our high-level languages more closely resemble natural language than they do machine-level instructions.
The more advanced our programming languages become, the more distanced they are from anything a computer can comprehend. The advancement in programming languages serves a single purpose: to let people write programs in a way that makes most sense to people.
With every line of code you write, ask yourself how well it can be understood by people. Because program code is for people, not computers. A computer will never read your code, only people will. A computer will never need to understand your code, only people will. A computer will never need to manage, modify and maintain your code, only people will.
Just as our software should be straightforward enough that a manual is not needed, so our code should be straightforward enough that a hefty set of documentation is not needed.
I know that car.leftFrontWheel().inflate() will inflate the car's left front wheel. I shouldn't have to ponder over some documentation before figuring out that car().convolutedMethod() does the same.
I know that bankAccount.deposit(20, 'GBP') will put £20 into my bank account and bankAccount.withdraw(20, 'GBP') will take it out again.
Forget Hungarian notation, it's plain to see that the variable currentBankAccountBalance will contain a floating point number, not a string, integer or boolean, and that numberOfBunniesInCage can't possibly be anything but an integer.
Forget comments that tell me what the code does. Explain it with the code itself. Make the code describe what it does, saving comments for describing why you chose a certain approach or that a seemingly superfluous line of code is actually a workaround for a bug and not to be removed.
Write your code for people to understand, not just programmers and certainly not computers. Make your code more readable and more understandable. Since the majority of time spent with your code will be when other people are maintaining it, code written for people will result in lower development costs, lower maintenance costs, lower bug fixing costs and happier developers.
As with any writing, it's essential to keep your audience in mind. You know, deep down, that your code is not for computers. But since your code is certainly used by computers more frequently than it is used by anything else it's easy to miss the point and forget that code is for people.
Great post its exactly spot on, code is for people cant be more true, and comments can sometimes be more misleading then just reading the code from the beginning
Great article, but...
You must NEVER use float to represent money.