I’m currently adding features to an existing Android app. It is written in Java, a language that I can write in but not at all as competently as C++. The programmer is very skilled in many areas but I think that he lacks a little discipline in removing redundancy. Removing redundancy makes code more maintainable and this code probably doesn’t get changed much. It is also possible that the original programmer never worked with programmers who were assholes when it came to making the team do things “right.” I did. They were great engineers and great people who treated their source code like a piece of art.
Some redundancy looks difficult to remove. But really, any time there is a few lines of code that is repeated in two or more places, those lines should be moved to a function, subroutine, or method, and that code should be called to do those actions. Then if any of those few lines changes, only one change is made.
I’m writing this because I am dealing with SQL statements that are essentially repeated at least three times in this one module. I had to add a column to a table and had to search and find the lines of code that interacted with the table. One area where a programmer might not think to remove redundancy is in the hard coded SQL query strings. My suggestion would be to write a function to return the part of the query string that references the column names. Something like this:
public String GetColumnNames() { return “aaa, bbb, ccc”; }
If there is any time when the column name is needed separately, store the column names in an array of strings and build that string above from the array. Then only the array needs to change.
It’s not always smooth sailing to do these things. The SQL code I am using can return all of the column data but leave out some lengthy string data and instead return the length of that string data. I don’t know why the length is useful but it is certainly useful to skip the big string data when it’s only a few of the other columns needed by the caller (to create a list of entries by name, for instance). In that case, the GetColumnNames() function is not quite right and could be changed to accept a flag to tell it to skip that big string column. What I dislike about that is that the code that extracts the data from the columns by their index then uses different indexes for different columns. More functions can be written to handle that or maybe some clever SQL query code could be stuck into the query to return an empty string for that one column instead of the real data – now that sound cool!
With just a simple change to return the column names in that delimited string, there is then 3 or 4 places in the code where I would not have made mistakes in manually editing the strings. Then there is the code that steps through the rows of returned data and uses some getString() and getint() functions to get data out of the returned row data and into a more typical java class. Again, a single function could be called to do this with a few options to control it. That code uses hard-coded numbers to get the data from the columns and reducing the number of places we see those numbers, the better. In fact, they should not change from one place in the code to another if the code is written well enough. but if they do, at least that can be encapsulated in that one function and the function can then get a parameter to control things. Ideally, it would take the same parameter that is passed to the GetColumnNames() function to control the columns.
If you think that this is a waste of time because it’s not that hard to know how to fix your own code, remember that someone else might be maintaining that code someday and even if these other functions don’t simplify the code much, they certainly move lines of code from one place where a lot is going on to another place where they are isolated and easier to understand.
Removing redundancy also make you a better programmer. It makes you a person who designs code instead of just writing it. It helps you think about what is going on in the software and helps identify places where the code might not be optimal, confusing, just wrong, etc..