How to Write Unmaintainable Code

Flagged. Links to a github page that blatantly ignores the Copyright of the original:

"Copyright

I would like to remind you this essay is copyrighted material. It is illegal to repost it without permission. I will usually give you that permission if you translate the essay into another language and if you provide a link back to the English-language original. I do this for three reasons.

That way any change I make to the essay is instantly reflected in any English-language copy anyone reads. That way the formatting and images are preserved. Pirated copies usually screw up the formatting. Google ad revenue from this essay is the main source of income from the website. It pays to keep me on the air. Please report any copyright violations."

There's a lengthy section in here on Hungarian notation and there's a statement in here that caught my eye:

"Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names."

A common mini-"Hungarianism" in most people's code is the naming convention of boolean variables and functions, usually by prefixing the name with 'is' + 'has' + 'can' and/or suffixing the name with a question mark (if the language allows it). I thought this was a near universal convention but every once in a while I come across code that doesn't follow this rule, to which I go - "Really?" (Although I will say that combining true Hungarian notation with that - e.g. bIsAbleToDoThing - seems too redundant.)

On a semi-related note, I wonder why such seemingly little slip-ups (not even the worst examples in the article, which are unlikely to find in the wild anyway) in the mere naming and formatting of things can become so irritating to us programmers. Why do things like Hungarian notation seem to hurt the readability of a program, despite usually just being the addition of just one letter to an identifier? You would think that we should just easily be able to ignore and look past these little things, but it's difficult not to notice them, even if you kind of get used to working on shitty code.

This is great. One of the very first things that jumped out at me:

> You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything.

I have this feeling about getters and setters. You never know if a getter or a setter is doing something nontrival. Most of the time they don't! But there's that 1%...

> "Optimise" JavaScript code taking advantage of the fact a function can access all local variables in the scope of the caller.

This is just not true. I believe he means in the scope of where it is constructed which is actually a useful technique.

As I don't have expertise in all of the enough expertise in all of the areas discussed, I'm not sure what other techniques are actually possible.