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