How to Blur Programming Lines? Quick Guide for Beginners!

Okay, here’s my blog post about “how to blur programming”, written from my personal experience:

So, I was messing around with this project, right? It was one of those things where I needed to, like, hide parts of the code’s functionality. Not really hide it, ’cause, you know, it still needs to work. But I wanted to make it harder for someone to just glance at it and instantly get what’s going on. Think of it like a soft focus on a photo – you can still see the picture, but the details are fuzzy. That’s what I was going for, this “blurring” effect.

First Steps: The “Duh” Stuff

First, I did the obvious. I renamed all my variables and functions to, well, nonsense. Seriously. Instead of, like, calculateTotal(), I went with fluffyBunny(). And my clear variable names? Gone. Replaced with single letters or just completely random words. This made the code look like a jumbled mess, at least at first glance.

It made sense in my head at the time, I used to think, ha!

• Rename Variables: userAge became x.
• Rename Functions: displayWelcomeMessage() became doStuff().
• Rename Classes: UserAccount became Thingy.

If it had anything remotely saying what it did, I changed it.

Getting a Bit Trickier: Adding Layers

Next, I thought, “Okay, this is confusing, but someone could still figure it out if they spent enough time.” So, I started adding extra layers of, well, nothing. I created functions that didn’t really do anything useful. They’d take in some input, maybe shuffle it around a bit, and then spit it back out. Pointless, right? But it added bulk to the code and made it harder to see the actual important parts.

For example one of the things I did was to make a function that takes a number, multiplies it by 2, then divides it by 2, and returns the result. Total waste of space, but it makes the code look more complicated!

Indirect Calls: The “Where’s Waldo?” of Code

Then, I got into indirect function calls. Instead of calling a function directly, like processData(), I’d create a bunch of intermediary functions. So, mainFunction() might call helperOne(), which calls helperTwo(), which finally calls processData(). It was like a maze, trying to follow the actual flow of the program.

This was my favorite part. It’s like creating a treasure hunt, but the treasure is just the original function you wanted to call.

The “Finished” Product (Sort Of)

By the end, the code was a monster. It worked, yeah, but trying to understand how it worked was a nightmare. I even confused myself a few times. Mission accomplished, I guess? It was definitely “blurred.” Like looking at something through a really dirty window.

It ran fine though, after I added the normal parts back in. I just left a bunch of the useless stuff in there, and it passed right through.

Would I recommend this for, like, a real project that other people need to work on? Absolutely not. It’s a terrible idea for collaboration. But for my little experiment, it was kind of fun to see how much I could obfuscate the code while still keeping it functional. It’s more of a thought experiment than a practical technique, to be honest.