Should I obscure my source code to make it more secure?

Posted on 10/03/2018 by Ken Gregg

In a word, no.

Obscuring your source code has no benefit in the real world.

When you write code, you are not only expressing your intent to the compiler, but you’re also expressing your intent the the human reader — the future you or other people, who will need to read, understand, and maintain your code. That’s why meaningful variable names, consistent formatting, comments, consistent function naming conventions, etc. are extremely important. In most programming languages, the compiler couldn’t care less about these aspects of the source code, but humans care about these aspects a great deal. It is these aspects of your source code that help to make your code readable and maintainable.

Whether you’re developing an in-house accounting system, a shrink-wrapped software package, or a downloadable app, 80% or more of the cost of a software product is incurred during the maintenance phase of the project, where maintenance includes bug fixes, new features, enhancements, etc. So, if you do anything to make your source code harder to to read and maintain, you’re on the wrong track. If someone — including the future you — needs to understand your code to maintain it, and they find it is obscured, or they have to run it through some convoluted process to “un-obscure” it, you are dooming your code to having a very short lifespan. And you won’t be doing your professional reputation any favors, either. Developers sometimes joke about writing obscure code to gain job security, but in reality, writing obscure code has the exact opposite effect on your career.

Crystal clear is always better than cleverly obscure.

And, contrary to what you might have thought or been told, in the world of source code, security by obscurity does not work and has no place. If you think you’re hiding some important proprietary approach or trade secret by obscuring your source code, you’re not. At best, you’re keeping honest people honest. If someone wants to figure out what you’re hiding, they will. Count on it.

Now, code minification is a valid thing to do in some environments, not because it obscures the code (which it does, to some extent), but because it minimizes the amount of information that needs to be transmitted over a network, and in some cases it reduces the time required to interpret the code. But you still want to maintain a human-readable un-minified version of the code for reading and maintenance purposes.

There are some folks who take writing the most obscure code as a technical challenge. The International Obfuscated C Code Contest is one forum for demonstrating these “skills.” As a hobby or an intellectual challenge, there’s nothing wrong with this. But these obfuscation techniques should never make their way into real-world production source code.

code maintainability code readability obscure source code security by obscurity software maintenance source code obfuscation software development software engineering programming best practice best practices program organization software design organizing software projects software project organization