[corresation]

Most code out there is shit code. Denying it is not going to help either.

So you do it "right" then, I assume. What do you think the next guy is going to say about your code? Do you really think they're going to praise the excellent code quality? Or will they declare to all around that it all needs to be rewritten because it doesn't conform to the newest flavor of the month?

I absolutely and unequivocally agree with the author: People declare everything around them as shit to prop themselves up, and the explain their own inadequacies in advance. There is shit code, granted, but by some measure of shit all code is shit. A viewer can destroy code as over or under engineered, over or under built, over or under abstracted, over or under object-oriented, over or under functional, and on forever, and anyone who thinks there is an actual right way in any reasonably complex system is demonstrating profound naivety.

The one thing that I will disagree with in the submission is the notion that this is a new or increasing pattern. It isn't, and has been the norm for decades. This is what developers do, especially those who are weak at reading code: Declare it shit in advance and just write your own.

[bowlofpetunias]

Maybe I haven't been entirely clear.

I'm not talking about a mismatch between approach (over- or under- whatever) and goal. I'm not talking about quick hacks that were never refactored (because of course, there never is time). I'm not talking about code that has gone through many cycles of unpredicted change and has acquired many layers of cruft. I'm not talking about code made by inexperienced developers who still have a lot to learn.

I've seen all that. I've written all that. I've left code behind I would be embarrassed to show in public. I'm shocked some of it is still in use, and I'm sure people who have to maintain it will curse my name. That is part of the job.

What I'm talking about is pure, unadulterated shit code. No structure, no logic, no consistency and barely functioning only under very limited conditions. Utterly incomprehensible unless you immerse yourself deep into the mind of the author like an FBI profiler and a serial killer.

No, there is no one "right" way of writing code, but boy there are an awful lot of "wrong" ways.

[fennecfoxen]

I know what this guy is talking about. It's the sort of code where the programmers spend 80 lines copying key-value pairs from one Perl hash to another Perl hash instead of doing it in 3-4 lines with a loop, because they don't know any better. coughibmcough

(Of course, this is among the least of their offenses.)

I try not to work at places like this.

[chriswarbo]

I thoroughly agree that there is a difference between hacky code and shit code. I've seen far too much code which isn't even attempting to solve the right problem, but is so buggy that its myriad problems compound to make it sometimes appear that the original problem is solved. Things which takes weeks to understand, and only went unnoticed due to an extraordinary unlikely coincidence of errors at all levels of the stack which Rube Goldberg would be proud of.

[kabouseng]

I would suspect that such practices are more prevalent in the web development world. Enterprise software and embedded development (my focus area) suffers far less from the pure unadulterated "shit" code pattern.

Mostly I suspect that is because the software development practices such as code reviews and coding standards are actually enforced.

[btilly]

I would hope that embedded is better. But the "Enterprise software" that I have seen is generally horrible.

[AndyKelley]

I once was responsible for maintaining code like this:

There were 3 client-side javascript files. They were named something like this:

foo.js foo2.js foo-z.js

Each file was about 4,000 lines long. All 3 were nearly line-for-line identical, save for about 500 lines of differences each, strewn wantonly about. For some of the URLs the app would use foo.js, for some other URLs it would use foo2.js, and for yet more of the URLs it would use foo-z.js.

There were 4 files on the server like this which did the same thing - copied line for line and then changed in various places.

After refactoring these files together and eliminating the duplicate code, I ended up deleting something like 8,000 lines of code. I quit soon after - by then I was already looking for another job.

That code was shit. There is no question about it.

[loup-vaillant]

Have you never seen a piece of code that sucked so much that you could shrink it by a factor of at least 2?

You lucky swine… Much (possibly most) code I have had to deal with was that ugly.

[sitkack]

Almost all code except the stuff written by the Masters of Succinctness can be shrunk by a factor of 2. Order of magnitude reduction is the only impressive metric.

[loup-vaillant]

I talk about code that I can shrink by a factor of 2. Most often without even understanding what the code does, just applying local correctness-preserving transformations.

I'm talking about horrors such as (this was real, production code):

  bool flag = true;
  if (var1 == const1)
  {
    if (var2 == const2)
    {
      // quite a lot of code
      flag = false;
    }
  }
  if (flag == true)
  {
    // a little piece of code.
  }

Clearly, someone forgot to clean up their code. It doesn't take a Master of Succinctness to realize that

  if (var1 != const1 ||
      var2 != const2)
  {
    // a little piece of code
  }
  else
  {
    // quite a lot of code
  }

is much better (the code represented by the comments didn't touch the flag). Plus, such simplifications tend to compound. After a first pass, I often see more possible reductions that can be used for a second, sometimes a third pass.

[corresation]

I don't know whether code verbosity is a measure of shit (indeed, that is one of those arguable points where one guy likes the single line ultra-functional version, and the other likes the same split into 20 lines).

I'm not disagreeing on the notion that there is some shit code in the world. Of course there is. But if anyone thinks that all or most code is shit, it often says more about the speaker. And I don't mean this as a personal attack on anyone, as it is possible that someone is in particularly dire code straights, but by and large the people who I've known who think all code is shit tend to be of questionable talent.

I have a friend who is constantly regaling the horrors they meet on the roadways because, in their opinion, everyone is a shit driver. Only it's my friend who is the shit driver, and their reactionary, panicked driving technique puts them in such constant peril that they can only imagine that everyone else is to blame.

[droidist2]

I like your driving analogy. It's very true. Those who talk the most shit often are shit, like how some men call women bad drivers even though women are actually less costly to insure.

Bad driver stereotypes piss me off because they often work under the assumption that cautious drivers are bad drivers and aggressive drivers are good drivers. Hell I bet Asian women are really the safest drivers.

[loup-vaillant]

There are a number of experiments that suggest that overall, the best predictor of shit (mostly, cost and bugs) is size. Once you account for size, almost every other predictor tend to be more noise than signal.

So, while there are ways to make code so short that it becomes incomprehensible (code golf?), most of the time, less code is almost always a good thing. A case in point would be the factorial in Haskell:

  fac i = product [1..i]