The programmer’s battleground

There are hidden wars going on. Wars that the average person doesn’t know about. They don’t want to know about. But they are serious. As serious as the war between the Big Endians and the Little Endians in Gullivers Travels. There are many battlegrounds that programmers fight on every day. Some of them may seem pretty silly to you. In fact, they seem pretty silly to us as well…at first. But just like the Lilliputians, the once silly and novel concept morphs into serious arguments and, in some cases, all out war! These are some of the battlegrounds.

Tabs vs Spaces

Tabs vs. Spaces shirts (these actually exist!)

The code programmers write needs to be indented to be clean and readable. Some languages even rely on indentation to work properly (I am looking at you Python!). There is a great amount of debate over whether to use spaces or tabs to indent with a near 50/50 split (according to some surveys). That’s right, there is a great debate between:

(in case you are wondering, the first one is a tab, the second one is 4 spaces).

As much as this usually comes up as kind of a joke, these discussions tend to get quite heated. The argument for using spaces is they have more consistant…well…spacing (tab size can vary). The argument for tabs is they are characters designed for indentation. Also, tabs offer a space saving. Even though visually they look like 4 spaces, spaces take 4 characters whereas a tab only takes 1. So, this results in a smaller file size.

Personally, I don’t care if you use one tab or four spaces, just pick one and be consistent. As long as you don’t use 3 spaces like some kind of crazy person!

Placement of curly brackets

There are two common places where you can put a curly bracket: same line and next line.

An example of same line is:

if (condition) {

}

An example of next line is:

if (condition)
{

}

Supporters of the next line method like how the curly brackets line up. They find it is easier to see where the block begins and where it ends.

Supporters of the same line method feel that the statement is obvious enough and by going to the next line there is a wasted line.

I actually got into a pretty serious argument over this in my last job as a Java programmer. We are no longer on speaking terms and I stand by my position. Damn dirty next liners….

Naming things

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

This is not so much a battleground between developers but more of a struggle we face every day.

There are so many things in programming that need names. Files need names. Objects need names. Methods, functions, parameters and variables need names. There can be hundreds of files in a project, each potentially defining a number of objects, methods and a seemingly endless number of variables. All of these need names. It doesn’t take long before you start to run out of names.

In the beginning, you start with the obvious names for things. As things develop, you will find a name you used earlier is more fitting for what you are developing now. But if you take that name, what will you name the old thing? It still needs a name of its own!

On top of that, code changes and the names you picked for things may no longer be applicable. I recently wrote a method that parsed an HTML file and created a list of citations from it. I called this method “lookup_citations”. Later on, I found a need to modify and clean up image tags in the same HTML file. Since I was already parsing the HTML file in “lookup_citations”, it made sense that I would put the image logic in there…but the name no longer seemed to match what the function was doing. What could I possibly call this method now? “lookup_citations_and_cleanup_images”? “html_processing”? “stuff”?

Come to think of it, “html_processing” isn’t bad. Sorry “lookup_citations_and_cleanup_images”, you are about to be renamed again!

By the time your project reaches a large enough size, you are burnt out from naming things. You have used up every combination of words related to the project you are working on. You find enjoyment in using simple names such as “x”, “y” and “z” because you don’t have to think. You start to make up words just to get by. You struggle and struggle but you keep at it because one day you know another developer will see your code and yes, you will be judged! Your names better be both unique and descriptive!

camelCase vs snake_case

Because naming is such a problem in the programming world, we often have to use two or more words to end up with unique and descriptive names. Most programming languages do not allow spaces in their names so we need a way to join the words. The two most common approaches are to use camel case (the first word is lower case, every other word is uppercase, with no spaces between suchAsThis) and snake case (all lower case and replace spaces with underscores such_as_this).

Some languages promote a naming convention to help resolve this. Java promotes camel case while Python and C promote snake case. Other languages are not so clear (such as Javascript and Ruby) and lead to many great debates.

At least one study has found that snake case is easier to read than camel case. A counter argument is that camel case is easier to type. If only we could type in camel case and read in snake case, the world would be a better place.

Conclusion

As developers we face some amazing challenges every day. It seems silly that we can make such a big deal out of such little things. Isn’t our job hard enough as it is? If only everybody would acknowledge that camel case, same line brackets and tabs are the superior way to go, we could move on and focus our time on some serious problems…like naming things…