This is rookie-level shittifying. What it needs to do is insert `with` blocks at random, with various levels of nesting, so you completely lose track of the scope of any object property.
Too "bad" that `with` blocks are forbidden in strict mode and most JS is strict mode by default now. You could somewhat approximate it with lots of unadorned blocks and complex object destructuring.
{
const { prop1: a, prop2: A, prop3: xTy } = obj
// …
{
const { prop1: A, prop2: xTy, prop3: a } = obj
// …
}
}
And randomly add "-Decorator" suffix to class names.
Ages ago, I tried to diplomatically explain to our Senior Architect Grand Poobah (and my team lead) that one set of Decorators are actually Chain of Commands. And that they shouldn't be silently swallowing exceptions.
After a few minutes, he says "u/specialist, I'm surprised someone with your experience doesn't understand architecture." Then gets up and walks away.
> No one wants to reformat the files because then it will mess up with git history.
GitHub will use a file `.git-blame-ignore-revs` to allow blame to ignore commits that make those kind of changes. (This is the format used for the `--ignore-revs-file` option to `git blame`.)
Git has something for every occasion I ever encountered with a need for something I knew was technically possible but didn't know if git would let me do it. It let me do it every time, truly the hacker's utility.
Rather than putting identifiers into MOckiNG sPongeBob CasE, it should apply a standard case convention (including initialism, Systems Hungarian with incorrect types, etc) at random for each identifier.
function Make_List(firstString, second_string, chThirdString) {
var a = [firstString, second_string, chThirdString];
return a;
}
Is it possible to get something like this: https://i.redd.it/as700946ez9z.jpg , but without the indents? So a flat block of code aligned to the left, and all the brackets in a column on the right?
I was thinking maybe it could be used for debugging, in the same way some have suggested a mode that reassigns names randomly so you can't rely on pattern matching as much
I used to work with a fella that wrote code similar to this. To him, code seemed to be a scratchpad, a place to jot down ideas and try them out. Once an idea worked out, he shipped it. Done.
Impossible to maintain, but damn if he couldn't churn out some quality works. Bug laden, sure, but the core ideas were great – at times even brilliant. There was a certain beauty to the chaos.
Prettier wasn't around then, and code for matters weren't much of a thing at all really. Can't help but think if that would've helped or stymied his process. Certainly would've helped the rest of us though!
> Impossible to maintain, but damn if he couldn't churn out some quality works. Bug laden, sure
That doesn’t sound like quality work.
I’ve had colleagues like that, they’re a pain in the ass because they look productive at the cost of everyone else holding the bag, and while they’re useful for exploratory or prototypal work it can be difficult to make the stakeholder understand that no the bug-ridden mess with an injection per SQL query is not going into production ever.
I’ve wondered if forcing them to use a very restrictive langage could help channel the mess somewhat.
Because the stakeholders often don't have the wherewithal to understand the difference so we shouldn't let the charlatans and terminally flawed take advantage of them.
There is an interesting difference in philosophy in this and the parent. One is the mindset that engineering is a profession and the other something of a market will sort itself out approach.
Unfortunately we’re living in a world where the doors are coming off airplanes mid flight.
Usually because you will inevitably get tasked with fixing something in that mess, and will have to slowly sacrifice your soul to get into the warped brain of that 'prodigy' coworker to understand the code if you don't.
> I’ve wondered if forcing them to use a very restrictive langage could help channel the mess somewhat.
StyleCop in C# (and ESLint/Prettier to a lesser extent in JS land) works extremely well for this. It's very quick to red squiggle your style problems when you're writing, can often automatically fix the problem, and keeps everyone committing code that looks one way.
It drove me nuts when I started doing work in a team, but I got used to it quick and we rarely bikeshed now.
This reminds me of seeing others' code in the first year of university. There was a pretty basic intro to some language constructs, but for some reason the first exams were done on paper.
People wrote everything without indentation, or with inconsistent spacing. Somehow this also carried over to the code that they'd write in the computer, so it was pretty much unreadable, since you couldn't glance at a block of nested loops and realize what goes where.
Having a code generator for each and everything mandating accutely expensive dependencies (massive and complex scripting language/templating SDK) is brilliant too...
Perhaps this could make useful synthetic data for improving large language models improving code, because you could have two pairs of code, better code, and the terrible code. This is probably already done internally at the top AI labs.
I would presume the code before was better than the code after, so that's how you could get two sets. It might not be much of a boost, it could depend, and I'm sure there are other data augmentation techniques. Good model improvement is usually an iterative loop, trying things out to optimise an objective.
It would be useful in conjunction with other data, but wouldn’t the model just learn the logic of the obfuscation code (unless perhaps you heavily regularised it?)
Yes in conjunction. For causal models like GPT, this sort of approach might help augment data, making it go further when training, or fine-tuning and the model could be trained on "improving" the bad code, actually the existing code. So the before and after would be reversed.
For encoder-decoder models they can can be trained, or fine-tuned on a more explicit translation task.
So just a kind of https://en.wikipedia.org/wiki/Data_augmentation
If it was deterministic - everyone on your team uses it to produce the same formatting, no matter show shitty it is - it would still meet the same goals as Prettier.
I would strongly disagree. People have different preferences on what makes code readable. But I would prefer anyone else's definition of readable to something that aims to objectively make code unreadable.
The problem with this tool is that it’s too easy to revert most of its work (everything except for the case changes in identifiers, AFAICT) using a prettifier.
I could see someone triggering a proper obfuscator (not this) as a time bomb, rendering the code in a permanent frozen feature state - usable but unmaintainable by future employees. (The contract says only to “write code to do this feature…”.) Do contracts provide legal barriers to this?
That would be a good way to destroy the reputation of your company lmao. Leaving nothing but horrors in your wake. Kind of funny, though, even if it's cruel to everyone who comes after you.
In general it does. doing bad work is better, because you deliver poor quality. but if you deliver something and then break it on purpose, it's like breaking something that belong to the company(not you). Remember that everything you do in a company don't belong to you.
As a party to a contract, if you act in a way that denies to the other party the benefit to which they are entitled, you could be said to have breached the implicit obligation of good faith and fair dealing that is more or less implied in every contract.
Worked with a company that outsourced their code. Contract stated that source code must be provided so in an effort to be pricks, the outsourced company provided their code on fanfold dot matrix printouts using a line printer from the 80s. It arrived in three very heavy boxes not even folded neatly.
I know this is satirical, but I would actually use this with my web development students as an exercise if it introduced more subtle shittiness that they would have to fix.
83 comments
[ 4.4 ms ] story [ 157 ms ] thread> Random indentation for a chaotic code structure.
One to add if it isn't there already: some blocks indented by tab, some by spaces, some mixed.
1. Convert leading indentation to tabs or spaces at random.
2. Insert trailing spaces.
3. Use varying indentation styles - pick at random from: https://en.wikipedia.org/wiki/Indentation_style#Overview
And randomly add "-Decorator" suffix to class names.
Ages ago, I tried to diplomatically explain to our Senior Architect Grand Poobah (and my team lead) that one set of Decorators are actually Chain of Commands. And that they shouldn't be silently swallowing exceptions.
After a few minutes, he says "u/specialist, I'm surprised someone with your experience doesn't understand architecture." Then gets up and walks away.
It was horrendous to look at at first, but I’ve gotten used to it by now and just apply the same random style to whatever snippets I modify. :)
GitHub will use a file `.git-blame-ignore-revs` to allow blame to ignore commits that make those kind of changes. (This is the format used for the `--ignore-revs-file` option to `git blame`.)
Minify every third variable randomly.
So, Go?
...just trying to be evil... :)
But seriously, if anyone is to maintain code like this, this will force the lowest possible cyclomatic complexity.
https://dimden.dev/beautifier/
And yet, I'm sure some folks will find serious applications, like in cases of malicious compliance when having to share your code against your will.
Like allowing an application to use several different caching / database setups depending on values in property files.
Java / Spring has so much potential.
Impossible to maintain, but damn if he couldn't churn out some quality works. Bug laden, sure, but the core ideas were great – at times even brilliant. There was a certain beauty to the chaos.
Prettier wasn't around then, and code for matters weren't much of a thing at all really. Can't help but think if that would've helped or stymied his process. Certainly would've helped the rest of us though!
That doesn’t sound like quality work.
I’ve had colleagues like that, they’re a pain in the ass because they look productive at the cost of everyone else holding the bag, and while they’re useful for exploratory or prototypal work it can be difficult to make the stakeholder understand that no the bug-ridden mess with an injection per SQL query is not going into production ever.
I’ve wondered if forcing them to use a very restrictive langage could help channel the mess somewhat.
Why do you bother saving the stakeholder from themselves?
Unfortunately we’re living in a world where the doors are coming off airplanes mid flight.
StyleCop in C# (and ESLint/Prettier to a lesser extent in JS land) works extremely well for this. It's very quick to red squiggle your style problems when you're writing, can often automatically fix the problem, and keeps everyone committing code that looks one way.
It drove me nuts when I started doing work in a team, but I got used to it quick and we rarely bikeshed now.
People wrote everything without indentation, or with inconsistent spacing. Somehow this also carried over to the code that they'd write in the computer, so it was pretty much unreadable, since you couldn't glance at a block of nested loops and realize what goes where.
Also possible in C and C++:
What is this internet law about not knowing satire from "lunatics" called now again ...
Howerver the main idea is very interesting.
To make it robust against such adversary attacks it should incorporate the teachings of “How To Write Unmaintainable Code” (https://github.com/Droogans/unmaintainable-code)
This reminded me of that for some reason.