Hacker News new | comments | ask | show | jobs | submit login
Art of writing unmaintainable code. (thc.org)
195 points by amirdhagopal on Sept 22, 2011 | hide | past | web | favorite | 37 comments

What a fantastic piece. Check the bottom for the sign-off: "People paid no attention when I harped about how to write __maintainable code. I found people were more receptive hearing all the goofy things people often do to muck it up."

You can tell that he's not talking about this from a theoretical point of view and that the majority of those samples were encountered in real life code.

I've seen a couple of them myself over the years (and I've been guilty of at least a few, especially in the beginning). To be able to compile such a vast set of examples must point to a very colorful career.

The best part of the whole thing is that you can read it two ways, invert every line in meaning and you get a pretty good naming conventions and coding standards guide.

The most amazing thing of this essay is that somehow, I know people who never read it, yet seem to know it by memory.

The Drupal developers must have used this as a coding bible when they came up with the idea of shoving absolutely everything in multi-dimensional arrays.

I love it when the output of print_r is larger than the html of a fully rendered page, by virtue of the html being included in the array you are printing.

The output of print_r on a single form on a page could probably stretch to the moon and back if each line was laid one after the other.

Recursively, of course.

Most of this is true, but I hate to have people continue to give hungarian notation a bad name when idiomatic use of it is quite a lot better than the naïve use of it decried here.

As an aside, do any other Haskell hackers find that single letter variable names are a lot more usable than in other languages? x:xs, y' and their ilk seem more readable than in other languages and often more readable than long variable names in Haskell.

They did qualify that this isn't an example of the original intent of Hungarian Notation

"The following tips will help you corrupt the original intent of Hungarian Notation"

But it's not really that clear if you've not heard what proper Hungarian Notation is before.

I think the rule is that very short variable names are a lot more usable in very short scopes (so you don't have time to forget what they denote). I use a lot more short scopes in Haskell than in less-functional languages, though I'm not quite sure why.

Woah, learned something new today :) An alternative break construct -

  switch (n)
  case 1:
      p = "one";
      if (0)
  case 2:
      p = "two";
      if (0)
  case 3:
      p = "three";

While true, the article feeds an odious appetite for righteous superiority all too common among technical people.


Agreed - and while most of this is obvious, and some insightful, some of it is just baseless opinion: "Never underestimate how much havoc you can create by indenting with tabs instead of spaces..."

Conversely, never underestimate how much havoc you can create by using spaces for indentation. With tabs, the level of indentation is clear and atomic. With spaces, it is arbitrary, and, wait for it...

hard to maintain

As someone who, despite being 24 years old, learned to type on a (mechanical!) typewriter, I don't like tab for indentation on the basis that, for me, tabs have a very specific meaning:

Carriage (or cursor, if you prefer), go to the next tab stop. [2]

For typewriters it means to go "literally" to where the next stop is. For text editors (at least for emacs)[1], it means to insert as many spaces as needed so the next column on the current line matches with the last non-space column on the previous line.

So, in the same way I use the table tag for tabular data in markup, I use the tab key for tabular text.

[1] http://www.jwz.org/doc/tabs-vs-spaces.html [2] http://en.wikipedia.org/wiki/Tab_key#Origin

If we're talking emacs, you can configure it to do whatever you want. So no, it does not always mean "insert spaces until the next tab stop".

Was this an electro-mechanical typewriter or a purely mechanical one?

I started on a purely mechanical, but then, as the course progressed, changed to an electro-mechanical one.

I second your agreement. That line would have been much better if it had been referring to mixing indentation styles or combining tabs and spaces.

"Randomly capitalize the first letter of a syllable in the middle of a word. For example ComputeRasterHistoGram()."

I do this by accident all the time.

And this is the funniest thing I've read on the internet all year:

"Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database."

I wish I still thought that was funny, instead of just painful. I can't tell you how many times I have been burned on Is or Get methods with incredible side effects, like IsValid also automatically logs the user in, creates them if they don't exist, and retrieves their birthday from the database to make sure it's valid. (edit: yes, that really happened.)

I've done this a couple of times just through sheer stupidity. Then I forget about it.

It always makes me laugh when my colleague ends up going through it to add another method and can't get his head around the fact one of mine has a hidden dependency obscured by an autoloader, with irreverent comments like `// lets get some validation up in this bitch` littered all over it.

PHP autoloaders and magic methods are a great source of such frustration when pulled off right.

That "isValid(x)" line is my favorite as well. I'm sure discovering these bizarre side-effects has taken days (weeks, months?) of all our lives.

Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.

Common problem found in coding, attempting to do things in a hifi way, when simple things server the purpose.

I finally found the manual that scientists used to write their code!

I remember a physics student ahead of me lamenting the fact that scientists had written their own software (ROOT & Geant). He said it was hard to use.

i sorta think this is dumb. these are all true, but superficial. this piece doesn't touch on any real, deeper reasons that well-intentioned code is unmaintainable, like excessive and unnecessary state & implementation inheritance.

I agree -- I hate these "negative" lists because there's an infinite number of ways to screw something up. Enumerating them isn't helpful.

Enumerating some of the ways to screw things up may be helpful in that it allows a reasonably intelligent reader to intuit the underlying connections and apply that intuition to a broader set of coding circumstances.

sure, i agree. i just think things like weak names, hungarian notation, brace preferences and lispy one-liners have no objective impact on the complexity of a system.

>> "People paid no attention when I harped about how to write __maintainable code. I found people were more receptive hearing all the goofy things people often do to muck it up."

- when we're told to write maintainable code :: MY CODE IS GOOD !! I'm sure Bob/Igor/Venkatachalapathy (coworkers) understand it just fine

- when we're told - these are the tricks of unmaintainable code .. :: HOLY COW !!! so THIS is what Bob/Igor/Venkatachalapathy has been using against me !! no wonder my promotion's been slow

Most of the "tips" in this article seem to suggest choosing a bad naming scheme or intentionally misnaming variables / functions. I can't imagine it would be that hard to put the code into an AST and work with that. That would make it easy to see where variables are used (despite losing their names). I realize that would take extra time, but I don't suspect it would be quite as bad.

I'm more afraid of the "Use threads With Abandon" tip.

You literally could build a career out of this. I'm not saying that's a good thing. But you can't argue with the amazing job stability it provides.

Also makes me think how long it takes big teams to filter out people like this.

This is fantastic - making all my students read this. English is a third language for most of them so I'm always trying to decipher the most cryptic method and variable names.

What country do you work in?

I laughed hard at this one: "Optimise" JavaScript code taking advantage of the fact a function can access all local variables in the scope of the caller.

This list has been around for a while (10 years or so?). Still a classic, though.

The domain suggests something else, though: "THC dot org" :-)

(What are you people, on dope?!?)

"In particular, in Java, make ordinary methods masquerade as constructors."

Isn't that the first item of Effective Java? Factory methods? Which is a good thing.

You know you read too much of that article if you notice that the 'Reduce, Reuse, Recycle' advice is given twice.

Meta-obfuscation in the obfuscation guide?

I once worked with a guy that decided to give his variables names like "Bob" and "Fred". IRONIC LOL.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact