Live data from Hacker News

The code culture problem

fraustollc.com

151–160 of 162 posts

Re: The code culture problem

#151
post #70

Earlier quoted context omitted.

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.

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.

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.

Re: The code culture problem

#152

Earlier quoted context omitted.

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.

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…

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]

Re: The code culture problem

#153

Earlier quoted context omitted.

> What do you think makes your code good? Answering for myself: (1) it's short. Often significantly shorter than my colleagues'. (2) it has few bugs, if our bug tracker is to be believed (I reckon I'm not very confident about that one). On the other hand, I tend to be slower, especially when I have to write against less than optimal APIs.

But short code isn't necessarily a garrant for good code. I went through a teenage phase where I would strive to write the shortest code possible. It's cringe worthy, and working my back into it seems scarce impossible. If you drew out the program logic, it'd look like an Eldridge terror. It just isn't good code. But yes, if you're writing War and Peace in order to parse XML, it's unlikely you're writing good code.

I try to write the simplest code possible. It always end up being shorter than if I didn't.

Also, of two okay-looking pieces of code, I noticed that the shortest is almost always the simplest. Which makes size a pretty good metric.

Re: The code culture problem

#154
post #98
post #35

Earlier quoted context omitted.

I'm just going to ask the question... What do you think makes your code good? I bet the next guy that comes around in 15 years and reads your legacy code (Grats on having code actually runs for 15 years!) will think it's the worst piece of shit ever created and are sure to think you are one of the worst developers in the world.

Why would you bet that? We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or…

> relentlessly applying a critical eye on everything I write and others write

Honestly, I believe that this is one of the best habits I've developed at my current workplace. We use Code Collaborator (a code review tool) for about 90% of all commits; I like using to get at least one pair of eyes on my code, but even further, I only even send out a review after I've gone through my own diff with a fine-toothed comb.

Re: The code culture problem

#155
Except usually the code is shit, and that's ok. Sometimes I'm even talking about my own code and that's ok too.

The first step to fixing a problem is admitting the problem exists. Attempting to cover it up it with words like, "well I'm sure there is a good reason for that" or "Hrm that could be better but I know we had crazy deadlines." Are just excuses and don't really help.

If looks like shit and smells like shit... well it's probably shit.

We are all big kids here, no need to sugar coat things.

Re: The code culture problem

#156
post #85

Earlier quoted context omitted.

If I can open a project and refactor some piece of code to be 1/10th of it's former size, while making it both more readable and more efficient without changing what it does than it's shit. In such cases I honestly don't care how good the original coder was supposed to be or what excuses he has. And yes, if I write code that can be optimized that way, I will be the first to admit that it's shit.

It's easier to refactor something that has already been created than to create that thing. This is why refactoring is such a good thing. It doesn't mean the original creation was "shit", it just means that it was massively improved by refactoring, which is sort of the point.

That's like saying, hey that rough draft of my essay is just fine to use. Not it's not, it's a rough draft, clean it up (refactor your code).

Re: The code culture problem

#157
post #40

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

>I've been in this business for over 25 years [...] The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. [...] Most code out there is shit code. Denying it is not going to help either. I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to…

It is amazing how many software developers think they are awesome. And then of course think everyone else is shit.

Unfortunately that pretty much means everyone is shit relative to someone else.

So its important to remember, you are shit too.

Re: The code culture problem

#158
post #40

Earlier quoted context omitted.

>I've been in this business for over 25 years [...] The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. [...] Most code out there is shit code. Denying it is not going to help either. I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to…

I think it's a bad case of "dislike due to knowledge". It's stark in the arts, but it applies to almost every human endeavor. As an example in the arts, I dance, and I'm good at it according to almost everyone who sees me dance. But I see myself as a terrible dancer. If I make a video of me dancing, others see every part that's well executed. I'm accustomed to them, and I tend to ignore those parts in favor of every…

I do like code which has comments which describe the level of confidence the author has in some sections (I feel a happier refactoring code which is marked as being suboptimal).

But in my experience those comments are usually found above cases where it's possible to make a fix in one line rather than one hundred. (sleeping a thread for 0ms rather than re-architecting a gigantic callback structure).

Re: The code culture problem

#159
Good article, couldn't agree more. Its about time someone spoke up about the extreme negativity that has become coding culture. I've worked in companies with very negative developer culture and more positive developer culture and found the latter to produce far superior software (on time, in budget, less bugs etc.).

Re: The code culture problem

#160

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

In my experience, shit code tends to start with a competent developer solving a problem in a way that seemed reasonable at the time, and then requirements changing, new features getting added, and everything is in a hurry so it never gets refactored.

Well, sometimes I do see code that's really very bad and I can't imagine how someone was ever able to type something like that, but that's rare. Usually it's competent people with the best of intentions but as lack of ability to predict the future.

Post reply on HN