Information Security – Unmaintainable code (it doesn’t just make your eyes hurt)

In my travels through the Internet, I found the , Java Coding Standards and wanted to highlight one portion as a concern for application security. The standards (specifically section 3) make me think back to my earlier days of code development. One person I worked with actually said to me after reviewing my code, “This makes my eyes hurt.” Now, as time has passed and my ability to code to standard has improved, I now get complements from the same person who’s eyes had hurt years ago after looking at my code.

Unmaintainable code, or code that doesn’t follow coding standards (or best practices related to the language used) increases the risk that the next developer tasked with updating the code will make a mistake (or kill the previous developer … just kidding). When code is not documented, doesn’t follow coding standards, or is written in a “spaghetti-like” fashion, is not secure. Obfuscation of code may be desired to secure the code from prying eyes, but in no way should it be considered when trying to maintain it. “Cool” features should be avoided, because “cool” features usually are only “cool” to the person writing the code. To others, the “cool” feature is just one more thing to try and understand, and a potential area for a mistake to occur.

Maintainable code is usually devoid of redundancy. In other words, one code block can be called many times, but only written (or modified) in place. For example, most programmers are familiar with methods (or functions, or subroutines, depending on the language we are discussing). The method contains what one may consider an atomic transaction – manipulation of data, getting data from a database, updating records in a database, etc. The method is called many times throughout an application, but a developer only has to maintain code related to what they want to do in one place.

Maintainable code is effortless to read. In conversations I’ve had with other developers, the “cleanest” code usually wins out over the “hurts my eyes code”. Using the gauge of “it works, so what’s the problem” to measure quality of code makes for unmaintainable code in the future. The code may work, but it is almost like reading someone else’s handwriting – it may only make sense to the author. This leads to mistakes and bugs when the code has to be maintained by others.

The information security risk applies primarily to the integrity tenet of the C-I-A information security tenets. Integrity relates to the application executing changes as expected and intended. If anyone who looks at the code can’t establish what the code is supposed to do, this is the perfect setup for failure. There is the increased potential that one developer assumes the code is doing one thing and the author actually meant for the code to do something different. Clear and concise code is always preferable to cleaver hacks or “cool” features. Encapsulation of like ideas is always preferred over “cut and pasting” duplication of code.

In the end, it’s not your code, it’s someone else’s code. If you leave the company because you were hit by a bus or win a million dollars, someone else has to take the code you wrote and maintain the code for the company. Writing maintainable code will allow others to carry on your legacy, instead of cursing you leaving them a mess .