Understanding Misunderstandings in Source Code [pdf] | Hacker News Reader

Understanding Misunderstandings in Source Code [pdf]

ssl.engineering.nyu.edu

54 pointslainon8 comments

I'd like to see more work like this. There are 1001 opinions on code style, but I've seen very little effort to objectively validate which pieces of common advice result in fewer defects.

I can recommend Code Complete by Steve McConnell. One of the primary aspects of this book that makes stand above other best-practices books is how much of it is sourced from software engineering research, although not the entirety. If nothing else, the bibliography is full of articles similar to the OP.

> I'd like to see more work like this.

Me too, but not so much with subjects that have just a couple of months experience with the language.

I'd prefer to identify things that still confuse programmers with, say, five years.

Things that confuse noobs contain a lot of noise. If we craft a coding convention based on that, we might end up with:

  i = 1;
  total = 0;
  while (i <= 100) {
    total = total + a[i - 1];
    i = i + 1;
  }

because the noobs were confused by zero-based arrays; increment operators like i++; and the jumpy, out-of-order evaluation of for(;;) syntax.

The most useful caveat, from the paper:

  Since the average professional software engineer has more experience than our average subject,
  the effect sizes reported may be overstated for some populations

I enjoy challenging myself in little code golfing here and there and writing things as short as possible and sometimes trying to do as few lines as possible seems better. In reality f the line count and write more clear short horizontal lines so when someone brings up your code in a tiny terminal window they can still read your thoughts like a book.

Watching some functional programmers use immutable variables to show their intent of what they are doing was very helpful. Example : Whippedcream = whip(cream); Vs Cream = whip(Cream);

I find if/else to be more confusing than ternary operators. One of the reasons is that it always defines what the else clause is, while that usually doesn't happen when using if.

I'd agree that someone who is not used ternary operators might be confused with this, as I have been before, but I find it to be much cleaner now that I've been using it. It's also a little harder to debug.

I'm finding Table 2 hard to interpret. What are the "delta correct" numbers?

what does the end code outputs?

Reply on news.ycombinator.com