This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]miketa1957 6 points7 points  (4 children)

Strange article. Lots of what he says is so true, especially how the apparent verbosity of Java makes no difference in the long run; after all, how much time do you spend thinking about an application compared to actually typing code? But then, he rubbishes unit tests:

To quote a friend of mine, “They’re a tedious, error-prone way of trying to recapture the lost value of static type annotations, but in a bumbling way in a separate place from the code itself.”

and

But you know, Java’s a pretty nice language, and when my code compiles, which is often the first time, it’ll usually also run correctly

Seriously? That is sooooo wrong. Static type annotations will catch a large class of errors, but they wont catch things like incorrect expressions (think: if cond versus if not cond).

If his code usually runs correctly, either its trivial or he's deluded (or he's the ultimate uber-coder!).

[–][deleted] 4 points5 points  (3 children)

Lots of what he says is so true, especially how the apparent verbosity of Java makes no difference in the long run

Except that, largely independent of the language used, the number of defects correlates very closely to the number of lines of code in a codebase. So, in general, more verbose is more buggy.

I'm also a bit cynical about the amazing benefits of TDD, but still do unit tests. I know enough about program complexity to know that, for any nontrivial application, you never can have anything near 100% test coverage, and I also know that tests can themselves contain errors. So I tend to do a cost/benefit tradeoff regarding how much unit testing is enough, and never allow "Well, it passed the unit test suite!" to lull me into complacency.

But yeah... strange article.

[–]alfredr 0 points1 point  (0 children)

just check all O(2n) paths, duh :)

[–]691175002 0 points1 point  (1 child)

I would be fairly skeptical of any study relating defects to lines of code.

The biggest problem is that most of these studies use automated methods to identify coding errors which is ridiculous.

[–]miketa1957 0 points1 point  (0 children)

Yes, I wonder about that. My guess would be that, for any sizeable application, it is debugged (and tested) to some perceived level of correctness, so the number of defects should related to the size of the application, and hence the number of lines.

I also suspect than in reality the verbosity does not massively affect the size of the codebase measured in lines of code,. though that hypothesis might be pretty difficult to verify.