4 ms·

There is a direct and measurable causal relationship between number of LOC and number of bugs. This was discussed at length on Stack Exchange podcast #9 (I beli

There is a direct and measurable causal relationship between number of LOC and number of bugs. This was discussed at length on Stack Exchange podcast #9 (I believe) when the author of "Making Software" was a guest. This exact topic was discussed at length. Java is for better or worse more verbose than Python, which means more lines of code which means more opportunity for bugs. It is hardly nonsensical. That opinion is a product of language-centric parochialism with no regard for actual fact. Ditto for the "just work" line being a "delusion." Like it or not, Python does indeed "just work" in most cases. This isn't unique to Python of course, but I do think that is a fair opinion of the author to hold.

arethuza 15y ago
"There is a direct and measurable causal relationship between number of LOC and number of bugs" I don't believe it is a simple linear relationship otherwise we'd all be using Perl or APL. More likely there is a "sweet spot" in the verbosity/terseness spectrum that is occupied by languages like Python.
- mattdeboard 15y ago
  Well, I'm not going to carry the banner for the authors' research, but that is not the case they make. According to them, more lines of code = more bugs.
  - seabee 15y ago
    Maybe those Perl one-liners weren't so useless after all...
- sambeau 15y ago
  I think that the real relationship is between clauses and bugs and in many languages a line equates near 1:1 to a clause. This is not the case for Perl & APL: each line can contain a multitude of clauses and the relationships between them can be complex to unravel. Conversely some languages (e.g. at the extreme end assembly language) require multiple lines to express a complete clause. Complex manually expressed type systems can be similar in effect to both cases. A single line can become complex to unravel e.g this kind of thing: int (*(*vtable)[])(); Reading complex regular expressions also exhibit similar problems in deciphering. Hence in Perl they are often broken over multiple lines with /x. We seem naturally drawn to using lines as logical delimiters: code is maybe similar to poetry in this respect. Also, in similarity to poetry, single clause lines allow us to annotate our thinking on the same line by way of a comment. One clause per line is probably a natural sweet spot. If my theory is correct then the relationship between lines and bugs will still be linear but APL would have a multiplier greater than one while assembly's multiplier could be a fraction (e.g. 5 vs 1/5).
  - russell 15y ago
    If I had to nominate favorite chapters in a book, it would be the one in the Vax C manual that walked you through translating C declarations into English and English to C. There was also a program that would do the same They saved me from mental meltdown more than once.
- power 15y ago
  It could be linear with a different constant multiplier for each language. Perl would presumably have a higher multiplier than Java given its density.
  - seabee 15y ago
    Sounds like the kind of scaling tools like CLOC can display. http://cloc.sourceforge.net/ http://cloc.sourceforge.net/
dustingetz 15y ago
static type checking is like compile-time asserts -- it doesn't add to solution complexity, it just verifies assumptions about inherent existing complexity.
- pekk 15y ago
  Satisfying a rigid, static type checking system often requires adding additional code which may not be significant to the solution. In other words, verifying assumptions requires additional code. Which assumptions actually need to be verified? Bondage-and-discipline languages do force you to do more thorough checking, but that doesn't necessarily mean the code is clearer or more concise. That isn't even the point of a bondage-and-discipline language. Getting normal things done with static type checking is not always simple; sometimes code gets skewed toward satisfying the type system. This is not completely unlike the way some people pepper their code with statements that serve no purpose except to shut up a lint tool, or make their test code simpler by making their solution code more complex. Assertions are an interesting case, as the programmer controls what gets verified and when, rather than being forced to code around an inflexible static checking system that inserts itself into language syntax.
- bad_user 15y ago
  it doesn't add to solution complexity Yes it does.
deleted 15y ago
[deleted]
smackfu 15y ago
"There is a direct and measurable causal relationship between number of LOC and number of bugs" Does that apply cross-language, or just within a given language?
- mattdeboard 15y ago
  From what I understand, raw number of lines of code, taking absolutely nothing else into consideration, is the most reliable indicator of bug count by a wide margin. I bought the book this morning to read it for myself but haven't had a chance yet due to work. It's Chapter 8 of "Making Software" (which can legally be had for free I believe)
canadiansaur 15y ago
'There is a direct and measurable causal relationship between number of LOC and number of bugs.' So if i write unit tests, that increases the number of lines of code, thus increasing the bug count right? The static type information in java is more akin to unit tests than actual programming logic - they decrease the bug count, not increase it. Whether they decrease the bug count enough to make up for the productivity loss is the part that is debatable
- famousactress 15y ago
  I agree with you.. static type information reduces potential test cases which makes it more like unit tests than LOC which will impact the bug count negatively.. but even though the author argues that the 'extra' Java code is type information, I think that's overly simplistic. Java also lacks mechanisms for re-use that languages like python have.. that increases LOC and redundancy in a way that I think will tend to affect the bug count negatively. In my experience, done right it's a bit of a wash. There's more potential cases to test in python.. but the tests are easier generally to write, and the code is more concise and easier to read. With pretty extensive experience at this point in both languages I wouldn't say I've experienced a significant difference in bug trends at all, frankly.

arethuza 15y ago

"There is a direct and measurable causal relationship between number of LOC and number of bugs" I don't believe it is a simple linear relationship otherwise we'd all be using Perl or APL. More likely there is a "sweet spot" in the verbosity/terseness spectrum that is occupied by languages like Python.

mattdeboard 15y ago
Well, I'm not going to carry the banner for the authors' research, but that is not the case they make. According to them, more lines of code = more bugs.
- seabee 15y ago
  Maybe those Perl one-liners weren't so useless after all...
sambeau 15y ago
I think that the real relationship is between clauses and bugs and in many languages a line equates near 1:1 to a clause. This is not the case for Perl & APL: each line can contain a multitude of clauses and the relationships between them can be complex to unravel. Conversely some languages (e.g. at the extreme end assembly language) require multiple lines to express a complete clause. Complex manually expressed type systems can be similar in effect to both cases. A single line can become complex to unravel e.g this kind of thing: int (*(*vtable)[])(); Reading complex regular expressions also exhibit similar problems in deciphering. Hence in Perl they are often broken over multiple lines with /x. We seem naturally drawn to using lines as logical delimiters: code is maybe similar to poetry in this respect. Also, in similarity to poetry, single clause lines allow us to annotate our thinking on the same line by way of a comment. One clause per line is probably a natural sweet spot. If my theory is correct then the relationship between lines and bugs will still be linear but APL would have a multiplier greater than one while assembly's multiplier could be a fraction (e.g. 5 vs 1/5).
- russell 15y ago
  If I had to nominate favorite chapters in a book, it would be the one in the Vax C manual that walked you through translating C declarations into English and English to C. There was also a program that would do the same They saved me from mental meltdown more than once.
power 15y ago
It could be linear with a different constant multiplier for each language. Perl would presumably have a higher multiplier than Java given its density.
- seabee 15y ago
  Sounds like the kind of scaling tools like CLOC can display. http://cloc.sourceforge.net/ http://cloc.sourceforge.net/

dustingetz 15y ago

static type checking is like compile-time asserts -- it doesn't add to solution complexity, it just verifies assumptions about inherent existing complexity.

pekk 15y ago
Satisfying a rigid, static type checking system often requires adding additional code which may not be significant to the solution. In other words, verifying assumptions requires additional code. Which assumptions actually need to be verified? Bondage-and-discipline languages do force you to do more thorough checking, but that doesn't necessarily mean the code is clearer or more concise. That isn't even the point of a bondage-and-discipline language. Getting normal things done with static type checking is not always simple; sometimes code gets skewed toward satisfying the type system. This is not completely unlike the way some people pepper their code with statements that serve no purpose except to shut up a lint tool, or make their test code simpler by making their solution code more complex. Assertions are an interesting case, as the programmer controls what gets verified and when, rather than being forced to code around an inflexible static checking system that inserts itself into language syntax.
bad_user 15y ago
it doesn't add to solution complexity Yes it does.

deleted 15y ago

[deleted]

smackfu 15y ago

"There is a direct and measurable causal relationship between number of LOC and number of bugs" Does that apply cross-language, or just within a given language?

mattdeboard 15y ago
From what I understand, raw number of lines of code, taking absolutely nothing else into consideration, is the most reliable indicator of bug count by a wide margin. I bought the book this morning to read it for myself but haven't had a chance yet due to work. It's Chapter 8 of "Making Software" (which can legally be had for free I believe)

canadiansaur 15y ago

'There is a direct and measurable causal relationship between number of LOC and number of bugs.' So if i write unit tests, that increases the number of lines of code, thus increasing the bug count right? The static type information in java is more akin to unit tests than actual programming logic - they decrease the bug count, not increase it. Whether they decrease the bug count enough to make up for the productivity loss is the part that is debatable

famousactress 15y ago
I agree with you.. static type information reduces potential test cases which makes it more like unit tests than LOC which will impact the bug count negatively.. but even though the author argues that the 'extra' Java code is type information, I think that's overly simplistic. Java also lacks mechanisms for re-use that languages like python have.. that increases LOC and redundancy in a way that I think will tend to affect the bug count negatively. In my experience, done right it's a bit of a wash. There's more potential cases to test in python.. but the tests are easier generally to write, and the code is more concise and easier to read. With pretty extensive experience at this point in both languages I wouldn't say I've experienced a significant difference in bug trends at all, frankly.