38 comments

[ 10.6 ms ] story [ 239 ms ] thread
The most amazing thing of this essay is that somehow, I know people who never read it, yet seem to know it by memory.
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.

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

http://www.youtube.com/watch?v=5TzHbcXYwI4

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

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.
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.
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.

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.
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.

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?

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.
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.
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.
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?!?)

"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.)
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.
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.

I once worked with a guy that decided to give his variables names like "Bob" and "Fred". IRONIC LOL.
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.

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";
      break;
  }
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.
"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.

>> "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

Over engineer a 100,000 line program like it's 100,000,000. (In my classes, we were graded on a curve on how short our programs were. That's how essays, websites and programs should be graded.)

What? Someone doesn't think a 1,000 line demo application program should use globals? Retard.

It's a cheap shot to criticise Windows for 16-bit legacy issues. Should they have over-engineered it? It's possible an over-engineered project would have failed. (Win 16) I thought of many features after the start -- I did not spec them. Before you criticize a project that has aged, humble yourself because it's long-lived. (Stupid punks criticizing Microsoft.) Only stupid academics don't respect success in the market.

http://wiki.osdev.org/Projects

http://lmgtfy.com/?q=64-bit+operating+system

I worked at Ticketmaster -- think about the cost of entry, the huge amount of competition in the sector and that they rose until they were sued for being a monopoly.

http://www.wired.com/magazine/2010/11/mf_ticketmaster/all/1

-------------------

Some people have small minds. I wanted to start absolutely with a fresh slate. Source code can have graphics. Once I explained that it has links like html and soon roared with laughter at small minds trying to make sense of that. Imagine a Microsoft Word document as source code. I'm cracking-up knowing that concept will not be understood.

I didn't really set-out to keep people from walking-off with my code, but laugh when I see the ways I suceeded... and maybe extended them. A major selling point is my compiler -- that separates me from amateurs... like the Linux kernel, that lacks a compiler. How depressing it would be to make a product who's only advantage is cost and that does no innovation.

Anyway, I want to highlight my compiler's existence and the fact source code is not limited to ASCII -- that it can even have superscripts and subscripts in names... so I very intentionally and deviously made a point of using pi and inf symbols. Helps prevent people walking-off too.

----------------------

God says... C:\TEXT\QUIX.TXT

ur and less justice the writings of others. It is my earnest hope that Your Excellency's good counsel in regard to my honourable purpose, will not disdain the littleness of so humble a service.

Miguel de Cervantes

VOLUME I.

CHAPTER I.

WHICH TREATS OF THE CHARACTER AND PURSUITS OF THE FAMOUS GENTLEMAN DON QUIXOTE OF LA MANCHA

In a village of La Mancha, the name of which I have no desire to call to mind, there lived not long since one of those gentlemen that keep a lance in the

-----------------------

That's not spam to me. "Lance" was the name of our grader in my class at ASU which was graded by code size. Actually, I only had one class graded on a curve based on code size and I got an A. It's was hardly competition -- I had been and was employed at Ticketmaster working on their VAX operating system in ASM. (My classmates were simply not in my league. That was my undergrad stuff, though.)

-------------------

I love Jesus!

36 He told them this parable: “No one tears a piece out of a new garment to patch an old one. Otherwise, they will have torn the new garment, and the patch from the new will not match the old. 37 And no one pours new wine into old wineskins. Otherwise, the new wine will burst the skins; the wine will run out and the wineskins will be ruined. 38 No, new wine must be poured into new wineskins. 39 And no one after drinking old wine wants the new, for they say, ‘The old is better.’”

--------------------

I win a hundred lottery grand prizes a day. I'm not worried about justice. I laugh at my enemies because they typically worry more about public opinion than God. Seek first the kingdom of God... and God will give you patent ideas faster than your enemies can... Eye has not s...