Repetative Recursion

One of my pet tech peeves is repetition and redundancy. I wish documentation had the same level of reuse as code. But in reality I find that we tend to repeat ourselves even in code just for duplication’s sake and we don’ realize it. Were I see a lot of superfluous repetition that is easy to overlook is in naming of variable, fields, columns, and classes. Here are a few examples of what I mean.

You have a folder called ‘Experience’ and under that all files are named like the following ‘exp_search_test.xml’ filename. The filename repeats that this document is an experience, whatever that really means. If you really want to indicate a file is of a given data type use the extension, so you rename the file as ‘search_test.exp’ or ‘search_test.exp_xml’ to indicate the file type.

Another example dealing with code is that variable names repeat their purpose. For example, you have an Employee class and the class has a subsequent employeeFirstName. If the variable is inside the Employee class, it is not required to prefix the class name to each field name. Use the context of the class to define meaning, don’t ad verbose comments to repeat what is clearly obvious like ‘This is the employee first name.’

I see this same problem in database column names. Another example that comes to mind of a real database schema used in production is of a fund table with column names such as fund_long_name, fund_type, etc. Again, I prefer concise and succinct column names.

Let me repeat myself again, if you try to add context to field name where it is already obvious you actually populate the namespace. Here is a more concrete example of that, again from code used in production. There was an ExcelExport class that contained the following two methods, exportExcel() and urlExportExcel(URL). Which method name should we refactor to simplify the API? … You might be thinking to rename urlExportExcel(URL) to simply exportExcel(URL) and in this way provide a concise API by overriding the same name but with different parameter list. Remember, the method signature of most languages includes the parameter type/list. But I would not stop there, I would actually rename the exportExcel() and exportExcel(URL) method names to simply export() and export(URL)! Why? Well, because you don’t just export data to Excel, you usually export data in different formats and flavors such as XML, RSS, CSV, etc. I hope that you can now see, that simply naming this method as export and using polymorphism, interfaces, subclasses, and factory pattern you simplify not just your method names but code.

An example of recursive repetition is where a word in the dictionary refers a different word, but if you look up the second word it refers to the first. As rule of thumb to avoid dubious verbose recursive repetition, variable names are not comments and comments should not repeat variable declarations.

Leave a Reply