Then you realize your code is undebuggable because half the functions and variables have single-letter names or called foo, bar, baz, etc.
I have a somewhat related real world story. I had a client that was convinced that tons of people were going to decompile their application and sell their own version of the program, so they insisted that they needed their code obfuscated to protect company secrets and make it harder to reverse engineer. I tried explaining to them that obfuscation wasn’t that big of a deterrent to someone attempting to steal code through reverse engineering and that it would likely cause some issues with debugging, but they were certain they needed it. Sure enough, they then had a real user run into an issue and were surprised to find that their custom logging system was close to useless because the application was outputting random obfuscated letters instead of function and variable names. We did have mapping files, but it took a lot of time to map each log message to make it readable enough to try to understand the user’s issue.
This is why you obfuscate after you code. Just obfuscate the release build. And logging may at that point be thrown out of the window anyway
It was obfuscated only in the release build. The issue is that they have a system to send certain logs to an API so they can refer to them if a user has an issue that needs further investigation. Unfortunately, their target audience is not very tech literate and have a hard time explaining how they got into a situation where they experienced a bug, so the remote logging was a way to allow us to try to retrace the user’s steps. Some of the logs that get sent to the API have JSON values converted from class data, will refer directly to class names, etc, and those logs had the obfuscated names.
