Writing Code for People
08 Feb 2023
When I began learning to program in C, I learned from the textbook The C Programming Language, 2nd edition by Kernighan and Ritchie. This book was published in 1978. While it is a great reference for learning C syntax, I quickly realized that the examples of code in the book were atrocious. They were confusing, all over the place, and didn’t seem to follow any sort of coding standard. It was later explained to me that in 1978, programmers prioritized saving computer memory over anything else, since back then memory was precious, and expensive. Every byte counted, and so making memory efficient code was prioritized over readability.
Prioritization in Modern Coding
When I first started learning to code, I naively believed that speed and efficiency were the most important things when it came to making good code. It’s a common misconception among beginner programmers. I remember taking a coding class with my buddies in high school, and we would compete to see who could complete a task in the least amount of lines of code. I remember my friends bragging about accomplishing a task in only one or two lines, over the seventeen lines of code it took me to do the same thing.
Looking back, however, it occurs to me now that the seventeen line solution was significantly better than the two line solution; because coding nowadays is not about speed or efficiency, and it’s definitely not about how many lines it takes you to accomplish a task. Coding nowadays prioritizes readability. Sure, you want your code to be as fast and efficient as you can get it, but a good programmer would not put that above readability. If you write a program that takes up a ton of memory, the easiest solution to that problem is not to rewrite the code, but to run the program on a better computer. We have that luxury now. But in a world as interconnected as ours, if you publish code, you better expect that other people will try to use it. It doesn’t matter much whether your code takes 0.02 seconds versus 0.10 seconds to run, but if it takes another programmer hours to decipher what you’ve written, then you’ve written poor, inefficient code.
On Readability and Coding Standards
When I started college, my professors emphasized the importance of following coding standards, going so far as to take points off of homeworks if they didn’t comply with them. I thought this was trivial, and a bit ridiculous at first. Why should I get a point off for not including spaces in the right places, or not putting my brackets on a new line? For a long time, coding standards were something I begrudgingly followed under threat of getting a lower grade on my homework otherwise.
I realize now the importance of coding standards. It’s the same reason we follow standards in regular writing. We want other people to be able to easily read and understand what we are trying to say. Programmers just have to deal with the extra caveat that computers need to understand us as well. But we don’t write code for computers; we write code for people. Back in 1978, that meant prioritizing memory, because there was no point in creating code that took up too much memory to run. But with modern technology, we have the luxury that computers can do most of the heavy lifting, and that allows us to create more user-friendly, human-oriented code. It’s important to remember that our job as programmers is to write code for people, not machines.