For anyone that has ever read someone else’s code or simply reviewed their own, you know bad code and good code when you see it. Perhaps the variable names are abstract or the indentation is off – never the less, a programmer must not forget that he or she is an author! Code MUST be readable, understandable and follow certain principles if one is consider it ‘clean code’.

Now you may think that this notion is merely stylistic, however programming can be just as beautiful as art. Although one might argue that art is stylistic and subjective, it still follows a basic principle – it speaks to people. Now I’m not saying to get SIRI to dictate your entire project to you, I’m saying that the code you write needs to jump off of the page, revealing the logic and the end goal as cleanly as possible to anyone reading it (including perhaps, yourself months down the road).

So what is good and bad code? How can you tell? Following the art metaphor, you know wonderful art when you see it. However, just because someone appreciates the work of Van Gogh, doesn’t mean he or she could replicate the thinking process to create such a masterpiece. Its not easy – it takes time investment, thinking, practice and above all, understanding.

Lets look at an example coded in Java from the book, Clean Code by Robert C. Martin:

public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>(); 
    for (int[] x : theList)
        if (x[0] == 4) 
    return list1; 

This is readable, right? Its a function called ‘getThem’ that returns a list of integer lists(ex. [[1,2], [3,4]] ), constructed by iterating through ‘theList’ and adding the element if and only if the first element of each list is equal to 4. What? If you’re confused, now you understand why bad code is considered bad.

What is it getting? What does ‘getThem’ refer to? Cats, people, slippers, guacamole hats? We have no idea! Furthermore, what is the significance of 4? And what is ‘list1′ suppose to contain? We know nothing about this function!

Alright alright, don’t panic… it can be salvaged. Lets see if we can refactor this to make… well, sense.

public List<Cell> getFlaggedCells() {
    List<Cell> flaggedCells = new ArrayList<Cell>(); 
    for (Cell cell : gameBoard)
        if (cell.isFlagged()) 
    return flaggedCells;

Okay, now we’re getting somewhere. Say this function is part of the Minesweeper code (that cheesy game that comes standard on Windows). We can tell immediately that this function returns a list of all flagged cells. We iterate through the entire game board (conveniently called, ‘gameBoard’) which consists of ‘Cell’ objects, and then check with a method called ‘isFlagged()’ to see if that particular cell is flagged. We return a list of all flagged cells. This makes sense (I hope) to almost any coder and only takes a few seconds of reading to piece together this functions purpose.

This simple seven liner is an excellent example of why programmers sometimes find themselves lost in a project. Maybe you didn’t write this ‘bad’ code, maybe it was a colleague. Nevertheless, it must be fixed! Lets take a look at another analogy from the book, The Pragmatic Programmer.

An urban study showed that an area with a single broken window soon fell apart extremely rapidly if that single window was not repaired. That window signifies neglect, and if whatever ‘higher authority’ neglects to fix a certain issue, so to does the next person to walk by. Furthermore, that person may even feel inclined to break another window, and then another and so forth. Soon, this area is totally destroyed and we’re in a zombie apocalypse! Okay, maybe I’m getting carried away here, but you get the point. Neglect feeds neglect. Don’t push things off until tomorrow – tomorrow means never.

So the next time you write code, look at and see if the logic jumps off the page. If it doesn’t, its bad code. As I said in the beginning of this article – programmers are authors. What we write ‘needs’ to be easily understandable to every other coder. After all, programming languages are human readable abstractions overtop of unreadable machine code… therefore, shouldn’t they be just as readable as any other language? Lastly, when you do come across a snippet of code that looks like hieroglyphics, refactor it! Doing so has far more impact than one might imagine to the integrity of a quality project.