450 Million Lines of Code Can't Be Wrong: How Open Source Stacks Up

An anonymous reader writes "A new report details the analysis of more than 450 million lines of software through the Coverity Scan service, which began as the largest public-private sector research project focused on open source software integrity, and was initiated between Coverity and the U.S. Department of Homeland Security in 2006. Code quality for open source software continues to mirror that of proprietary software — and both continue to surpass the industry standard for software quality. Defect density (defects per 1,000 lines of software code) is a commonly used measurement for software quality. The analysis found an average defect density of .69 for open source software projects, and an average defect density of .68 for proprietary code."

Comments

Correction

[Sla$hPot]

"450 Million Lines of Code Can't Be Wrong"
should have been
"450 Million Lines of Code Can't ALL Be Wrong"

Re:Correction

[bobbied]

You mean: "exit(-1);" ?

Re:Correction

[hduff]

It mean over 300,000 lines of code are wrong, most of it in the app I keep trying to use.

Re:Correction

[Anonymous Coward]

It mean over 300,000 lines of code are wrong, most of it in the app I keep trying to use.

Not necessarily wrong, it could be that it is insecure or exploitable.

Re:Correction

[Anonymous Coward]

The solution is simple. Add more meaninglessly verbose lines!

Write

if (blah.something(nain,jahaha,verboten)) while (betty == evil) kill(kayne);

like this

if
    (
        blah.something(
            nain,
            jahaha,
            verboten
        )
    )
{
    while
        (betty == evil)
    {
        kill(
            kayne
        );
    }
}

And when they complain, reply with the usual thought-terminating "Think of the retards! " clichee, and get the bonus of implying all your coworkers are morons who can't even comprehend the former version, while making them say sorry to *you*. (At least if they follow standard "social" norms.)

P.S.: Inb4 "Your English is bad.": I know. It's my fourth one our of five, and I still have my bad moments when it's three in the morning. But I felt like reading Luxemburgish is a bit too much for the average Slashdotter. ^^

Re:Correction

[Anonymous Coward]

Most line-of-code counters understand the syntax of the language they're analyzing, and will realize that those needless newlines can be disregarded.

They also know how to ignore comments and empty whitespace.

1963 called, it wants its state of the art back.

Re:Correction

[Anonymous Coward]

Windows isn't an app.

Re:Correction

[ILongForDarkness]

No just one critical line in the constructor of each project. All broken but broken slightly :) Bugs don't matter until they effect features I use :)

Re:Correction

[Anonymous Coward]

I was thinking 450 Million Lines of Code Can't Be Right! (The odds against it are crazy.)

Re:Correction

[kraut]

Your English is fine. Your German isn't.

Nein! Nein! Nein!

P.S. Reductio ad absurdum much.
P.P.S. If you confess to knowing Luxemburgish, just how A do you think your C is going to be?

Re:Correction

[kraut]

Well, it certainly isn't an operating system either.

Re:Correction

[Anonymous Coward]

450 Million Lines of Code Can't Be Wrong

And now, my young Jedi Programming Apprentice, we will introduce you to the concept of the "for loop":

perl -e 'for ($i = 0; $i != 450E6; $i++) { print "print \"This line is wrong.\\n\"; # line $i\n"; }'

Here is the Dark Side version:

perl -e 'for ($i = 0; $i != 450E6; $i++) { print "print \"By reading this, you agree to give away all your money to my lawyers.\\n\"; # line $i\n"; }'

A contract like that in most legal jurisdications might be viewed as slightly improper, possibly even wrong, but as 450 million lines of code can't be wrong...

65 million lines of HOST file can't be wrong

[Anonymous Coward]

Just ask apk!

Re:65 million lines of HOST file can't be wrong

[Anonymous Coward]

Just ask apk!

You mean Jeremiah Cornelius?

Re:65 million lines of HOST file can't be wrong

[Anonymous Coward]

I see one of his sock puppets voted me down.

Re:65 million lines of HOST file can't be wrong

[fisted]

i think he means a corrupted slashdot luser who penetrated the moderation system.

Re:65 million lines of HOST file can't be wrong

[Anonymous Coward]

pentrated

Re:65 million lines of HOST file can't be wrong

[Anonymous Coward]

i think he means a corrupted slashdot luser who penetrated the moderation system.

All lusers use condoms.

Defects fixed for proprietary may differ.

[CodeReign]

Propietary defects are ones that may cause financial harm. FOSS defects are ones that cause annoyance.

I know that our code has more defects than we'd consider fixing purely because the CBA isn't there.

Re:Defects fixed for proprietary may differ.

[Cenan]

Propietary defects are ones that may cause financial harm. FOSS defects are ones that cause annoyance.

I know that our code has more defects than we'd consider fixing purely because the CBA isn't there.

I'm guessing you mean defects in propietary software only gets fixed if they have an impact on the bottom line? Otherwise that whole reply makes no sense.

Anyways, that is not much different from the OSS model. Whoever cares about the sub-system that has a bug, fixes it, and if nobody cares (or has the skills to fix it) it can go ignored for years. The selector for OSS is different, but the end result is the same: nobody gives a fuck about the end user unless it directly affects their day/paycheck/e-peen.

Re:Defects fixed for proprietary may differ.

[Anonymous Coward]

My company uses FOSS, and I can assure you that there have been bugs in the FOSS software that have caused financial harm.

Conversely, there are bugs in proprietary software that we use that are annoying and have to be worked around, but cause us no great financial difficulty, because they can be worked around.

FOSS has no exclusive claim to "only has defects that will annoy you," just as proprietary software has no exclusive claim to "only containing defects that will affect your bottom line."

I'm honestly not sure if you're trying to knock FOSS, or jock FOSS, but either way - you're completely wrong.

Re:Defects fixed for proprietary may differ.

[Vanderhoth]

A fangirl?

Re:Defects fixed for proprietary may differ.

[Dishevel]

A fangirl?

No. The exact opposite would be a HateBitch.

Re:Defects fixed for proprietary may differ.

[Bigby]

No, I think the GP is getting at the point that code analyzed in the analysis likely includes critical proprietary software. Software that needs to work and so they invest the time in making sure it does.

Meanwhile, the open source side probably included code that is not critical, based on reverse engineering, or experimental in nature. Not that both the proprietary and open source code bases didn't contain both, but I think the context of the code is quite different.

The results would be much more meaningful if they compared the code quality of GIMP vs Photoshop, Firefox vs IE, or Linux/X/KDE/Gnome vs Windows. Comparing anything in the open source world to code using in NASA missions or medical devices is bad, especially when you include those with useless stuff like xclock or some open source tetris.

Re:Defects fixed for proprietary may differ.

[fisted]

you should get your opposites right

Re:Defects fixed for proprietary may differ.

[Anonymous Coward]

Explain.

Re:Defects fixed for proprietary may differ.

[jellomizer]

So hows that Kool-Aid?

Somehow the idea on how a product is licensed will affect its quality is very absurd.

For most open source projects you will only have a small handful of contributors about the same many for a traditional software company. You got good developers and bad ones. Some OSS software is just crap, others strive to be excellent. The same with commercial applications too.

Any differences in the community vs commercial interest really tend to balance themselves out.
You have a problem in your code. A small fraction of people will actually go into the source and fix it for themselves, as they risk having a separate fork and cannot upgrade their systems. A small fraction of people will pay the company extra money to fix the problem. Most will either decide if they can deal with the issue or not. And either not use the OSS project (reducing the popularity of the project and causing less involvement) or not buy the product making giving the software development firm less money to create software.

The real advantage of Free as in beer software vs commercial is the fact you can try a bunch of lemons before you make your final decision. For a comerical app you often need to pay up front and deal with what you got.

Re:Defects fixed for proprietary may differ.

[CodeReign]

Correct, as a developer I'd like to fix bugs in my enterprise level software but the overhead required to do so is high enough to outway the benefits.

On the other hand, if you are a developer for a FOSS project you are able to correct broken code at your leisure, submit it for peer review and have it accepted. The overhead is still there but it's spread out to feel less visible (IMHO). I'm perfectly fine writing a fix and having it be rejected for being inadequate. I'm less okay with spending 4 hours having people sign things so that I can correct a defect that takes 2 minutes of development work.

Re:Defects fixed for proprietary may differ.

[CodeReign]

So hows that Kool-Aid?

It's delightful but you seem to have missed the point. I am saying that people are free to fix bugs at their leisure for FOSS projects, for enterprise applications you are not permitted (usually) to fix a bug because it exists. You have to prove that there is a value add from fixing the bug and that value add cannot be that it makes your life easier (unless you can provide quantitative measures of productivity increase)

Re:Defects fixed for proprietary may differ.

[Cenan]

Correct, as a developer I'd like to fix bugs in my enterprise level software but the overhead required to do so is high enough to outway the benefits.

On the other hand, if you are a developer for a FOSS project you are able to correct broken code at your leisure, submit it for peer review and have it accepted. The overhead is still there but it's spread out to feel less visible (IMHO). I'm perfectly fine writing a fix and having it be rejected for being inadequate. I'm less okay with spending 4 hours having people sign things so that I can correct a defect that takes 2 minutes of development work.

Well sure, but that really has nothing to do with the cost of a bug. The motivation for fixing the bug may be different, but the data release tells us that the two have nearly identical impact when ground down to a (useless) number.
We could go into the merits of using static analysis of code to say anything about code quality other than: "there are 0.69 rookie mistakes for every 1000 lines of code", but that is a whole other story.

The article does a poor job of covering up that this is Coverity peddling their --Warnings_as_Errors --Pedantic solution to a problem the compiler people have solved already.

Fight'n Words

[Anonymous Coward]

Code quality for open source software continues to mirror that of proprietary software ....

That thar is fight'n words, pardner!

Open Source is SUPERIOR!

Re:Fight'n Words

[bzipitidoo]

Sure makes the emacs vs vi wars look petty. This is a religious dispute between the believers in greedy capitalism, who think such forces lead to the best balance of highest possible quality at reasonable expense, in all endeavors, and everyone else.

The greedy capitalists think that if you aren't sweating and stressing over your job and the money it provides to feed your hungry children, not to mention your house and car payments, fearing that the loss of your job will ruin your career so that you will never be able to find another, then you aren't motivated enough to really help a capitalist endeavor succeed. They pressure you to put yourself on the hook with none too subtle hints, couched in plausibly deniable talk of "team spirit" and "dedication" and "commitment". The coworker who buys a new car gets all kinds of praise for, in essence, being such a good wage slave/capitalist consumer. If that doesn't do the trick, managers reveal a few personal details about their choices in housing and transportation, to set an example, and encourage a little bit of "keeping up with the Joneses" envy. If that still doesn't work, they remove the people who aren't falling for it, as those sort set a bad example. Makes for a good object lesson for the survivors of the layoff. Extreme balances on credit cards, massive house payments, and other such horrible burdens become, in this whacked out world, bragging rights. The savvy worker therefore has to appear to toe the party line, while carefully holding back in ways that do not show, because sometimes one ends up stuck under a boss who doesn't know when to quit pushing, and the only healthy alternative the worker has is to leave.

Naturally, they're afraid of open source, readily equating it with Socialism and even (gasp!) Communism, which they have feared for decades. They don't understand the motivations behind open source, and therefore don't trust it. They've been told that open source fits just fine with capitalism (and it does!), but they can't believe that. I think that attitude more than anything, this dogmatic belief in the holiness of wealth and ownership, has propped the likes of Microsoft up beyond all reasonable objective assessment of the true value of their offerings.

Re:Fight'n Words

[Anonymous Coward]

Unfortunately, you're completely correct.

Re:Fight'n Words

[Anonymous Coward]

Sure makes the emacs vs vi wars look petty. This is a religious dispute between the believers in greedy capitalism, who think such forces lead to the best balance of highest possible quality at reasonable expense, in all endeavors, and everyone else.

Actually, it's a dispute between that small group of greedy capitalists and the even smaller group that apparently feels the universe will provide for those who are pure of heart and lacking of greed. The vast majority of people are far too busy living their lives to get involved in such nonsense.

Re:Fight'n Words

[TapeCutter]

Wow you sure put a lot of thoughts into other people's heads. I don't know about the US but here in Australia contributing to a well known OSS project is something you put on your CV, not something you hide like a drug habit. Many OOS devs are also commercial devs in their day job (or would like to be), hardly surprising they write similar quality code for both endeavors.

Re:Fight'n Words

[Subject-17]

It's similar in the US. OSS development is definitely something to put on your resume (and even more so on a CV). It shows you like programming enough to do it in your spare time, which means you're less likely to be applying for a job just for the paycheck, and probably have more knowledge of programming that what is simply required by your position. Also, if they really want, they have access to a real world code samples from you.

it contradicts the definition

[nimbius]

the very definition of 'proprietary software' indicates you dont have access to the code to calculate defect density, and even if you did you cannot independently verify the code you have is production code. how did the researchers quantify it?

Re:it contradicts the definition

[Anonymous Coward]

Pay no attention to the man behind the curtain.

Re:it contradicts the definition

[GrugVoth]

We use coverity where I work on proprietary code and part of their service is to report, anonymously obviously, the defect count, type and lines of code etc back to coverity if you want to. Via this they can get an idea of the defects found using their tool over a very large code base.

Re:it contradicts the definition

[Anonymous Coward]

Wrong. There are quite a few organizations who have access to Windows source code, yet Windows is still proprietary software. Proprietary just means that you cannot freely share, not that you have no chance to get the source code.

Re:it contradicts the definition

[robthebloke]

Is AOL one of them?

Re:it contradicts the definition

[Chris Mattern]

We use coverity where I work on proprietary code and part of their service is to report, anonymously obviously, the defect count, type and lines of code etc back to coverity IF YOU WANT TO.

Am I detecting a selection bias here? Coverity can run their tests against all of open source. Coverity can run their tests only against that proprietary code that decides to use it and report the results--and it strikes me that only the better, and more open, proprietary shops would be doing this. Is Mircrosoft reporting their code? I doubt it. Is Oracle?

Re:it contradicts the definition

[Chris Mattern]

Wrong. There are quite a few organizations who have access to Windows source code, yet Windows is still proprietary software.

For the purposes of evaluating the Coverity Scan results, it's irrelevant whether other organizations have access to Windows source code. The question is: Does Coverity have that access, and did they use it in compiling their results? I will admit I don't know, but I sincerely doubt it. According to the article, the proprietary results are only from those who are Coverity clients.

Re:it contradicts the definition

[Anonymous Coward]

Considering that Microsoft is listed as a Coverity customer here (select the "Software and Internet" tab), it's actually quite possible that they do have access to Windows metrics. I know it's gonna seem impossible to believe, but Microsoft isn't still shipping Windows ME. Their software has dramatically improved in recent years. It's not perfect, but it's quite a bit more stable than it used to be.

And for all the people whining about selection bias, there isn't any more bias for FOSS than there is for Proprietary: FOSS projects have to register with coverity to be included in their scan service. Any project reporting to Coverity (FOSS or Proprietary) must value quality enough to USE Coverity and report metrics. Coverity is not just spidering SourceForge and going "LOL FOSS SUCKS."

Here's the list of open source projects that Coverity covers currently - looking through the list, there's quite a few heavy hitters in there (including the Linux kernel, which their report notes as a "benchmark" for FOSS quality), and not a lot of one-off SourceForge abominations.

Re:it contradicts the definition

[Bigby]

I want to know how a tool can automatically detect defects. Sure, it can get syntax and a few semantic stuff. But most defects are not syntax errors. How does coverity catch when a required field isn't required for some reason? How does it catch UI glitches? How does it test performance? Memory loads?

Re:it contradicts the definition

[Registered Coward v2]

We use coverity where I work on proprietary code and part of their service is to report, anonymously obviously, the defect count, type and lines of code etc back to coverity IF YOU WANT TO.

Am I detecting a selection bias here? Coverity can run their tests against all of open source. Coverity can run their tests only against that proprietary code that decides to use it and report the results--and it strikes me that only the better, and more open, proprietary shops would be doing this. Is Mircrosoft reporting their code? I doubt it. Is Oracle?

I doubt they ran it against all open source software; just some subset that ideally mirrored the proprietary code in complexity and application. If so it would be a reasonable comparison. Since TFA says they used some 300 OSS programs of various sizes I'd say it was a reasonable approximation of real world defect rates. Since the TFA doesn't name any proprietary products included in the survey it is harder to decide if they are valid results but I am willing to give them the benefit of doubt.

Re:it contradicts the definition

[chill]

You might try just RTFA.

...and an average defect density of .68 for proprietary code developed by Coverity enterprise customers.

Re:it contradicts the definition

[steelfood]

Is Mircrosoft reporting their code?

That would be unfairly skewing the numbers upwards against proprietary software, what with both Windows RT and 8 being completely defective and all.

Re:it contradicts the definition

[Anonymous Coward]

You're kidding, right? Static analyzers have been around for years.

Re:it contradicts the definition

[vux984]

But most defects are not syntax errors.

I'd be surprised if coverity even bothers with syntax errors. I mean your compiler catches those and if the project doesn't even build its not something you can even theoretically release.

I think it focuses on:
using unitialized variables, unreachable code, buffer overruns, memory leaks, division by zero, infnite loops, sql injection vulnerabilities.

potentially it might be able to catch some threading / synchronization / race condition issues as well.

I don't know, I'm just speculating, but a lot of this stuff can (at least sometimes) be detected by automated means.

Re:it contradicts the definition

[shreak]

Coverity performs "Static Analysis". Static analysis is a well respected technique in the industry and can find classes of software defects that are typically difficult to find through code inspection and testing.

Specifically it can analyze entire call chains and find access to null or un-initialized variables. Compilers typically only do this within a single compilation unit (i.e. a file) while an SA tool like Coverity will do it over an entire call chain over multiple files.

Other classes of defects that SA will find:
- Memory leaks or double frees
- variables passed out of range
- unreachable code
- Buffer overruns (BUFFER OVERRUNS!)
- Sign issues

It can be very painful to start using SA late in your project development. Getting a clean SA run is a major pain since you've probably got tons of little errors. Once you have a clean run (or if you start with SA analysis) keeping it clean saves you major headaches (and keeps your code reviews a little less frustrating)

Re:it contradicts the definition

[Anonymous Coward]

> I doubt they ran it against all open source software; just some subset that ideally mirrored the proprietary code in complexity and application.

Complexity and application have nothing to do with the selection bias mentioned. The selection bias is in the confidence of the vendors.

Re:it contradicts the definition

[Onymous Coward]

Even then not a reasonable comparison. The ability for the scanned proprietary softwares' teams to decide on inclusion feels to me like it would really influence the stats.

Would you expect there to exist any correlation between how shoddy software is and how likely the authors are to share information about how shoddy their software is? I would expect some correlation.

Re:it contradicts the definition

[Registered Coward v2]

Even then not a reasonable comparison. The ability for the scanned proprietary softwares' teams to decide on inclusion feels to me like it would really influence the stats.

Would you expect there to exist any correlation between how shoddy software is and how likely the authors are to share information about how shoddy their software is? I would expect some correlation.

Let's accept the premise that proprietary vendors only submitted what they considered their best code. If the code bases tested matched similar function OSS codebases, then it is a valid comparison of similar types of software. It would say that OSS and proprietary software; of similar functionality, has similar defect rates (for certain size code bases). As with any study, the results should be taken with a grain of salt until you see the underlying methodology and data. That, of course, will not stop people form trumpeting the results as proof *their* OSS project is as good as proprietary in terms of errors, even though such a conclusion is not valid; but it does give people some assurance that OSS code, in general, is as reasonably good as its proprietary equivalent. It would be interesting to see exactly what was included in each data sets and such information would help shed light on the conclusions. In addition, depending on what OSS software was included, you could make a case that much shoddy OSS software was left out depending on what was included in the sample; which is why I conclude that as long as similar types of programs were tested it is a valid comparison.

Re:it contradicts the definition

[ILongForDarkness]

It at least is supposedly anonymous so MS and Oracle could very well be reporting their code. If Coverity allowed you to search by size of projects it might give them away: hmm OS project with 500M lines of code, who could that be?

Re:it contradicts the definition

[maxwell demon]

Unreachable code doesn't need to be a defect. For example, consider the following function:

int foo(int n)
{
  if (INT_MAX < LONG_MAX)
  {
// use algorithm 1
  }
  else
  {
// use algorithm 2
  }
}

Now on every compiler, one of the branches will be dead code, yet this is not a defect. You might argue that one should use conditional compilation here, but that's no correctness issue. The code as written is certainly not wrong.

Re:it contradicts the definition

[dvice_null]

If you are really interested. There are some open source programs that do static analysis also. Have a look e.g. at the source code of Cppcheck ( http://cppcheck.sourceforge.net/ ) to see how it works. E.g. some potential performance issues are pretty easy to detect, e.g. using i++ instead of ++i for objects. Or passing a copy of string instead of a reference.

If you want to know what kind of faults can be found or what do they look at on the source level, here is a list of bugs that Cppcheck has found from open source projects (obviously not everything is listed, but it should give you a pretty good picture):
https://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Found_bugs

Re:it contradicts the definition

[shreak]

That's fine if it's expected (and you can tell your SA tool that it's expected so it's not flagged). Unreachable code that's not expected is a maintenance issue at best and and in many cases indicates a software defect. At the very least wouldn't you want to be made aware that your unreachable code?

Re:it contradicts the definition

[loufoque]

Tools to do this are available for free. Most software projects use open-source solutions rather than coverity.
All coverity does is put it all in one nice package for continuous integration.

Re:it contradicts the definition

[shreak]

I agree, there are free tools that do this. Some are pretty good (cppcheck). I'm not going to pimp for Coverity (or other $$ products) but I will say that they offer features over and above what the free stuff does. They also have a pretty high cost. A few of the features are actually very nice additional analysis that I haven't found in free stuff. The majority of the stuff offered by commercial products are based around integration into a large multi-developer environment and defect tracking processes. As always, you (or your organization) needs to figure out the cost vs benefit before committing to any (free or $$) tool.

Re:it contradicts the definition

[amaurea]

Even then not a reasonable comparison. The ability for the scanned proprietary softwares' teams to decide on inclusion feels to me like it would really influence the stats.

Would you expect there to exist any correlation between how shoddy software is and how likely the authors are to share information about how shoddy their software is? I would expect some correlation.

Let's accept the premise that proprietary vendors only submitted what they considered their best code. If the code bases tested matched similar function OSS codebases, then it is a valid comparison of similar types of software.

I don't see how you're answering the grandparent's concern here. Are you assuming that the code quality is only a function of the function of the code? Otherwise, why would an OSS project in category X be better than average just because a better-than-average proprietary X was submitted?

Let's make this a bit more concrete: Imagine that the defect density of proprietary projects is normal-distributed with a mean of 0.6 and a standard deviation of 0.1. Then you would expect the defect density to vary between less than 0.5 and more than 0.7, with 68% lying between those numbers. If high quality projects are preferentially submitted for review, then the mean of that subset will obviously be lower than 0.6. Let's say that the projects that were sent in were a web browser (0.55), a pdf reader (0.49) and a video player (0.50). You're saying that it would be fair if we compared this with open source web browsers, pdf readers and video players. But just as these categories happened to fluctuate low in error density in the proprietary side, these categories may just as well happen to have atypically high error rates on the OSS side. In fact, unless the quality of the project is strongly correlated with the category it is in, then you would expect the mean on the OSS web browsers, pdf readers and video players to be the same as the total mean, since *they were not selected based on their own quality*, unlike the proprietary software.

Your argument about comparisons of similar types of software would only make sense if there were only one proprietary program of the type in question, and that is the one that was submitted for testing. Otherwise, you would expect to be comparing a better-than-average properietary foo with an average OSS foo.

I think the grandparent is completely correct that there is a potential bias here. But I have no idea how large it is.

Re:it contradicts the definition

[JonySuede]

But that snippets does warrant a comment that include a tag to disable the warning. This is what I like the most about static analysis; worst case: it forces my developers to comment the hairy pieces of code, typical case: they residing to avoid the need to comment and we have a more maintainable code base. To the same goal, I also use the static analyzer to limit cyclomatic complexity the ennemy #2 of maintenance. #1 being useless shorthanded naming convention or lack of.

Re:it contradicts the definition

[TapeCutter]

And the assumption you're making is that proprietors will select only their best code for independent review. Having been in the industry for over 20yrs that assumption does not match my experience.

Re:it contradicts the definition

[TapeCutter]

Coverity doesn't need to see the source code, they just need the client to send them the numbers their tool spat out. Many will, some won't, but I don't think that has anything to do with wanting to hide poor results, communisim, or greed.

Re:it contradicts the definition

[Registered Coward v2]

Even then not a reasonable comparison. The ability for the scanned proprietary softwares' teams to decide on inclusion feels to me like it would really influence the stats.

Would you expect there to exist any correlation between how shoddy software is and how likely the authors are to share information about how shoddy their software is? I would expect some correlation.

Let's accept the premise that proprietary vendors only submitted what they considered their best code. If the code bases tested matched similar function OSS codebases, then it is a valid comparison of similar types of software.

I don't see how you're answering the grandparent's concern here. Are you assuming that the code quality is only a function of the function of the code? Otherwise, why would an OSS project in category X be better than average just because a better-than-average proprietary X was submitted?

No, I am saying it would be a valid comparison between OSS and proprietary code if programs that perform the same function were tested in each category. OSS quality has no impact on proprietary quality, and vice versa; but if you compare OSS and proprietary web browsers tehn it would be a reasonable comparison of teh quality of each vs the other.

Let's make this a bit more concrete: Imagine that the defect density of proprietary projects is normal-distributed with a mean of 0.6 and a standard deviation of 0.1. Then you would expect the defect density to vary between less than 0.5 and more than 0.7, with 68% lying between those numbers. If high quality projects are preferentially submitted for review, then the mean of that subset will obviously be lower than 0.6. Let's say that the projects that were sent in were a web browser (0.55), a pdf reader (0.49) and a video player (0.50). You're saying that it would be fair if we compared this with open source web browsers, pdf readers and video players. But just as these categories happened to fluctuate low in error density in the proprietary side, these categories may just as well happen to have atypically high error rates on the OSS side. In fact, unless the quality of the project is strongly correlated with the category it is in, then you would expect the mean on the OSS web browsers, pdf readers and video players to be the same as the total mean, since *they were not selected based on their own quality*, unlike the proprietary software.

The problem is you are assuming they all have a normal distribution. While that may be true for a large data set (in fact the central limit theorem would say so); we don't know what the distribution is for individual categories. While we don't know what exactly made the data set we do know teh results for various sizes of code. It seems a reasonable assumption that similar types of programs would have similar size code bases so you don't have really good small proprietary programs skewing results for really large ones or vice versa; and similarly for OSS code.

Your argument about comparisons of similar types of software would only make sense if there were only one proprietary program of the type in question, and that is the one that was submitted for testing. Otherwise, you would expect to be comparing a better-than-average properietary foo with an average OSS foo.

Not really; especially a the high end where there are relatively few products in each category. There aren't that many commercial choices in many of the categories; and also relatively few OSS as well. As a result it is less likely all the bad ones got left out, if they were you wouldn't have much of a data set. So, assuming they had similar software in each category the comparison drawn would be valid. Could we say any one program is equal to another? No, but we could say that for large programs OSS software is as bug free as proprietary; and vice versa.

I think the grandparent is completel

Re:it contradicts the definition

[amaurea]

No, I am saying it would be a valid comparison between OSS and proprietary code if programs that perform the same function were tested in each category. OSS quality has no impact on proprietary quality, and vice versa; but if you compare OSS and proprietary web browsers tehn it would be a reasonable comparison of teh quality of each vs the other.

I would agree if representative sample sets from each category were selected. The problem is that the self-selection effect might make the proprietary sample set non-representative.

Not really; especially a the high end where there are relatively few products in each category. There aren't that many commercial choices in many of the categories; and also relatively few OSS as well. As a result it is less likely all the bad ones got left out, if they were you wouldn't have much of a data set.

Actually, you don't need to leave out all the bad ones for this to result in a bias. It is enough that bad ones are slightly underrepresented. The effect will be bigger the more extreme this is, and your example is the most extreme version of this. That would result in a huge bias, but I don't think anything that extreme will be happening here.

The size of the data set does not affect the importance of systematic effects like these. Statistical estimates have two main error sources: Statistical errors and systematic errors. Statistical errors are due to limited sample size, and basically quantify the probability that what you see are simply due to random chance rather than being a real effect. The more data you have, the easier is is to exclude this possibility, so statistical errors decrease with sample size. Systematic errors, on the other hand, are errors due to faults in your model and uncorrected biases, etc. The only way to reduce these errors is to improve your analysis - they don't go away just because you throw more data at them. Conversely, they aren't any bigger if you have few samples either.

In my field (astronomical data analysis) we often report our estimates like a = 5.512 +- 1.2(stat) +- 0.7(syst), which indicates both the best estimate and the statistic and systematic uncertainty of this estimate. It would have been nice if Coverity had done that here too. Right now we're left at guessing what these errors might be, which isn't very useful.

I am not saying there is no bias and without seeing specifically what comprised the test data we don't know what and how big any bias is. I take issue with comments that the results are invalid because people assume all OSS was tested but proprietary was cherry picked. They don't like the results so the immediate reaction is to claim they are false.

I agree that we don't know how big the bias is, or whether any attemt was made to quantify and compensate for it. But selection bias is definitely a reasonable bias to look for in this case. Note that people aren't claiming that Coverity cherry picked which experiments to analyse. They are claiming that mature projects confident in their code quality would be more likely to submit their code to Coverity for checking in the first case. That said, I think the numbers that were reported are good news even as they are. They show that OSS is on par with proprietary software in terms of code quality, despite many pointy haired bosses' insistance that it must be much worse.

Compelling numbers

[Anonymous Coward]

Compelling numbers, friend.

I'd like to have my own personnel verify thi... ah, right.

Auto scan

[Anonymous Coward]

It must be just me, but if we could simply find all these defects with a scan, why weren't they fixed before release?

Re:Auto scan

[Anonymous Coward]

Because they were all marked as WONTFIX in the bug database. :-)

69 is good

[youn]

definitely more fun than 68 :P

Re:69 is good

[BasilBrush]

The 1970s called. They want their joke back.

Re:69 is good

[Anonymous Coward]

And the definition of 68 is...
You do me and I'll owe you one.

Re:69 is good

[Anonymous Coward]

1990s David Spade called, he want his easy-to-write joke formula back.

Re:69 is good

[Anonymous Coward]

yer mum called. She wants me back.

Re:69 is good

[Anonymous Coward]

That's funny... she wants me penis.

Re:69 is good

[Anonymous Coward]

Get off the internet, dad! You're embarrassing me! You always do this when you've been drinking!

Re:69 is good

[Anonymous Coward]

And you, shut up! You're not my real dad! Stop trying to be him!

and all the children are above average

[Anonymous Coward]

"Code quality for open source software continues to mirror that of proprietary software — and both continue to surpass the industry standard for software quality."

What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality? Because if there is only open source and proprietary then they can't both be better than average. Or perhaps the programmers are from Lake Wobegon?

Re:and all the children are above average

[clodney]

"Code quality for open source software continues to mirror that of proprietary software — and both continue to surpass the industry standard for software quality."

What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality? Because if there is only open source and proprietary then they can't both be better than average. Or perhaps the programmers are from Lake Wobegon?

I had the same reaction, right down to the Lake Wobegon reference. Perhaps they are differentiating between software offered for sale versus tools internal to a business? To some extent that would also explain the difference in quality - cost to fix is much higher if you have shipped thousands of copies, versus telling the one consumer of a report in finance to ignore the one number that is wrong.

Re:and all the children are above average

[ZahrGnosis]

Wow, yeah, I posted an almost identical sentence myself. Eerie. (Although I didn't have a Wobegon reference... sorry). But yeah, it seems like an odd sentiment. Internal use software is still either "proprietary" or "open source"... isn't it? But good point. If someone calculated the bugs in my excel macros as if they could be used for general purpose computing I'd be in sad shape. (ObNote: I use excel macros as rarely as possible, and normally only at gunpoint).

Re:and all the children are above average

[ZorroXXX]

The selection of sample projects is biased. For proprietary software, the data is taken from projects that at least cares as much for code quality that they run some tools (e.g. at least Coverity) to analyse it. I would suspect that the industry standard is below that because there exists some companies that mostly only consider "get the product out the door". For open source the selection is probably also somewhat scewed, in that they have analysed relatively large, mature and highly successfull projects. I would assume those have higher quality than the average sourceforge/github project.

Re:and all the children are above average

[hardluck86]

Industry Standard != Industry Average

Re:and all the children are above average

[Gr33nJ3ll0]

This is a good point. To build on it, the results reported from the propertiary code has had coverity at least run against it, and usually the problems that it reports fixed. This does not appear to have been done in the case of the Open Source software, which was just scanned, but never given a chance to fix. In that circumstance I would have expected a much much higher result for the Open Source software, because Coverity often reports on very pedantic issues, which are often not important to overall software quality. Further these issues would not show up in anything other than Coverity, making the initial scan the first time these issues were brought to life.

Re:and all the children are above average

[Cenan]

The selection is biased yes. But not for the reason you imagine. It's biased because only developers who care about the quality of their code run tools to determine that quality. All the shitty OSS and propietary code outthere didn't participate in the study. The dataset was built with usage statistics from the service and you have to register your project with Coverity in order to participate.

Re:and all the children are above average

[Anonymous Coward]

"industry standard for software quality" says nothing about averages, dummy. Industry standard is a minimum threshold, apparently commonly set by QA and Engineering organizations, that code must have "fewer than X defects per KLOC." And apparently both FOSS and Proprietary software exceed that industry rule of thumb.

I'm not sure why this is throwing you for such a loop - were you dropped on your head as a baby? Did you experience a near-drowning that cut off blood supply to your brain and thus damaged your cognitive function? We'll never know. But, perhaps this thought exercise will let light dawn on Marblehead:

The speed limit on a road is marked as 65 mph. Two cars drive down the road, both doing 75 mph. They both get pulled over and ticketed for exceeding the speed limit. Why? (Hint: Averages and Standards aren't the same. Consider the difference as you formulate your answer.)

Extra credit brain busters for you:
1) Imagine a 3rd car joins the first two on the road, doing 50 mph. Now the average speed of all cars on the road is 66.6 mph - above the speed limit. Do all 3 cars get a ticket? Why or why not?

2) Imagine a 3rd car joins the first two on the road, doing 40 mph. Now the average speed of all cars on the road is 63.3 mph - below the speed limit. Does any car get a ticket? Why or why not?

Re:and all the children are above average

[Anonymous Coward]

Many companies have software that is developed for a specific purpose and does not fall under these broad categories.
Firmware is software, but is part of hardware.
Some companies develop software that is not for sale but it serves some specialized purpose internal to the company. It is not really proprietary but more likely IT or domain-specific.
I would expect that consultants who retain copyright on their code but provide the code to their customers fall into another bucket.

Re:and all the children are above average

[Zero__Kelvin]

I just read the Wikipedia article on Lake Wobegon, and it seems that you are referring to "The Lake Wobegon Effect". Unfortunatley this term is ill-coined. It is indeed possible for all the children to be above average in fictional Lake Wobegon, since they are a very small subset of all the children in the world.

"What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality?"

As far as exceeding industry standards you are confusing a standard with a mean. For example, the industry standard size for a byte is 8 bits. If your bytes have 9 bits in the software you design then you have exceeded industry standards ;-)

Re:and all the children are above average

[Registered Coward v2]

"Code quality for open source software continues to mirror that of proprietary software — and both continue to surpass the industry standard for software quality."

What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality? Because if there is only open source and proprietary then they can't both be better than average. Or perhaps the programmers are from Lake Wobegon?

I had the same reaction, right down to the Lake Wobegon reference. Perhaps they are differentiating between software offered for sale versus tools internal to a business? To some extent that would also explain the difference in quality - cost to fix is much higher if you have shipped thousands of copies, versus telling the one consumer of a report in finance to ignore the one number that is wrong.

An industry standard has nothing to do with actual practice. It is not an average. All it says is it is an acceptable error rate is x.

Re:and all the children are above average

[Bigby]

Correct. I would hope the industry average for heart surgery is above the industry standard. Likewise, the industry standard for politicians is far higher than what you get with the average.

Re:and all the children are above average

[Anonymous Coward]

So who is setting this "standard" that is so low that virtually all software is exceeding it?

Re:and all the children are above average

[Anonymous Coward]

So who is setting this "standard" that is so low that virtually all software is exceeding it?

The industry, of course.

Re:and all the children are above average

[AmiMoJo]

Perhaps it means commercial mass market software, as opposed to vertical software written for one company or that is only used to support one hardware product.

Re:and all the children are above average

[ThatsNotPudding]

What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality?

Anything featuring the words SCADA or Nuclear Reactor.

Re:and all the children are above average

[Anonymous Coward]

"Code quality for open source software continues to mirror that of proprietary software — and both continue to surpass the industry standard for software quality."

What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality? Because if there is only open source and proprietary then they can't both be better than average. Or perhaps the programmers are from Lake Wobegon?

Limnux

Re:and all the children are above average

[Anonymous Coward]

This is a good point. To build on it, the results reported from the propertiary code has had coverity at least run against it, and usually the problems that it reports fixed.

This does not appear to have been done in the case of the Open Source software, which was just scanned, but never given a chance to fix. In that circumstance I would have expected a much much higher result for the Open Source software, because Coverity often reports on very pedantic issues, which are often not important to overall software quality. Further these issues would not show up in anything other than Coverity, making the initial scan the first time these issues were brought to life.

There are quite a few open source projects that regularly scan with Coverity and fix defects it finds. Coverity even has an entire program of providing free scans for open source projects.

Re:and all the children are above average

[Anonymous Coward]

bespoke

Re:and all the children are above average

[hawkinspeter]

The customers.

I'm pretty sure they can

[Anonymous Coward]

I don't think that it will be that hard to find at least 450 million lines of code that are wrong.
Heck, I can probably find that in my unfinished/abandoned projects folder.

Some things can't be measured objectively

[Hentes]

Errors per lines of code may give you a hard number, but that number has nothing to do with the quality of code. It only takes one well-placed error to ruin a piece of software.

Re:Some things can't be measured objectively

[MadKeithV]

It's still a better measure than not trying to measure it at all

Re:Some things can't be measured objectively

[Anonymous Coward]

Unless you are saying proprietary or open source software has a particular penchant for making such "well-placed" errors, you can in fact get a very good idea of quality of code in general from these numbers.

Re:Some things can't be measured objectively

[Hentes]

No it isn't. In this case, you have to ask the subjective but professional opinion of developers.

Re:Some things can't be measured objectively

[gorzek]

You are wrong, and here's why.

With no measurements at all, you cannot make informed judgments about the quality of your software. You can only guess. This means you would be unable to convince anyone (sane and intelligent) that your product has n bugs. "Because I say so" is not a metric.

With a poor measurement--such as one that ranks all defects equally--you have information, but now it's bad information. If you share the information but not the method(s) used to gather it, you can convince people you're right, because you have data about it. Never mind if you are stacking up Product A with 1 show-stopping bug against Product B with 50 cosmetic bugs or unhandled corner cases. By this bugcount-only metric, Product A looks better, and that's just stupid.

You need good measurements, and sometimes that includes measurements which cannot be quantitatively calculated without human intervention. A human programmer (or QA or other support person) who is familiar with a product will know just how severe a given bug is in terms of its impact. It is why, after all, bug tracking systems generally allow you to prioritize work by severity, fixing the worst bugs first.

Poor information is worse than no information because it can lead you to make the wrong decisions with confidence. With no information, at least you know you are shooting in the dark.

Re:Some things can't be measured objectively

[Anonymous Coward]

Not necessarily, and the question whether it is or not is empirical.

Re:Some things can't be measured objectively

[Anonymous Coward]

you have to ask the subjective but professional opinion of developers.

Ah, that explains the most famed professional riposte: "But it meets the Spec!"

Because "grossly unfit for actual purpose" is manifestly not a "defect", as every Luser shude kno.

Re:Some things can't be measured objectively

[Bigby]

I could be. But it is a bad assumption to think it is. It will lead to a false sense of quality.

Re:Some things can't be measured objectively

[Anonymous Coward]

A code analyzer isn't going to detect cosmetic bugs and it keeps track of the types of bugs it finds. The analyzer can compare similar categories of bugs and weight different ones differently.

Re:Some things can't be measured objectively

[Rich0]

Errors per lines of code may give you a hard number, but that number has nothing to do with the quality of code. It only takes one well-placed error to ruin a piece of software.

Better still, how do you even measure it? I can understand REPORTED errors per lines of code, but not errors per line of code. How do you know if a line of code contains an error?

And the differences could be a matter of error reporting. When was the last time you were able to log something on Microsoft's bug-tracking DB?

Re:Some things can't be measured objectively

[mcphail]

The line which tends to ruin my software is: /* Copyright (c) 2013 Neil McPhail */

(Sigh)

Re:Some things can't be measured objectively

[VanessaE]

Never mind if you are stacking up Product A with 1 show-stopping bug against Product B with 50 cosmetic bugs or unhandled corner cases.

Ordinarily I would agree with this, but there is a caveat to consider - that one "show-stopping" bug might only be seen by 5 or 10 percent of your userbase, who would quickly learn not to use the feature that triggers that bug, but those 50 cosmetic bugs will become so visible and glaring and unavoidable that you'll have users going, "Good G*d, this thing looks like shit! How I can I trust such a crappy-written program?", especially if those users are part of the general public, rather than a closed, business-users-only crowd.

In other words, Product B really *IS* worse, even if it objectively functions better.

I'm not saying those cosmetic bugs should necessarily be given the same weight as the showstopper, but to downplay them because they're "only cosmetic" is to ignore that rather sizable portion of your userbase, who care at least as much about spit and polish as they do about functionality.

Defect density

[Anonymous Coward]

If the defect density is 0.69 per 1000 lines of code, then of 450 million lines of code, more than 300000 are wrong. Therefore, so is the title.

The study is not really conclusive

[brainscauseminds]

Actually, this study does not say anything directly about code quality, because Density = Total Defects Found / Code Size. The problem is with the "Total Defects Found" part. How they are found and how they are reported may differ vastly from one project/company to other. The report sais that the quality of code increases with larger codebases in propertiary projects. In fact, the best you can say is that the metric decreases with larger codebases in propertiary projects. Maybe many of the defects have not been found yet in propertiary projects. Maybe they have less manpower to seek the errors, maybe they just don't care as long anything does not crash. But smaller defects may be in the code. Open source code is more open to "finding the defects", thus possibly obtaining worse "quality" they are talking about in the article. I think this has to be kept in mind when reading the report.

OSS defects

[Cyko_01]

Everyone knows OSS doesn't have defects, it just develops random features

Re:OSS defects

[SCHecklerX]

Relevant: http://www.xkcd.com/1172/

Re:OSS defects

[TWiTfan]

The problem with open source software isn't the code quality, it's poor UI and poor documentation. Way too many open source projects bring on great programmers, but few, if any, designers or technical writers. The result is software with great functionality, but buried beneath horrid UI's and poor (or non-existent) documentation. I wish I had a nickel for every OSS project website I've been to where the only documentation in sight was a long list of bug-fixes, or whose UI was so confusing as to make it unclear what the software is even FOR.

Not every software project has to be as well designed as Apple, but Jesus, if you expect a typical consumer to memorize a ton of obscure command-line commands to use software that doesn't even properly document those commands, then you really need to help from a proper designer and technical writer (much as programmers are loathe to admit that designers and writers serve an actual useful purpose).

Re:OSS defects

[Anonymous Coward]

*portrait of penguin with flipper pointed to viewing technical writers*
Open Source's Uncle Tux Needs *YOU*.

(c) brought to you by the teach_your_daughter_/_son_to_document_code_today project.

The more the code sucks, the more it costs

[Anonymous Coward]

Stuff written in less popular old obsolete languages that is very sloppy yet unique and confusing and difficult to wrap your head around and extremely buggy is a pain and thus it costs companies money to pay someone to do work on it. Not only does it take an intuitive person who can tolerate annoyingly crappy code, but they'd be stupid to take the job in the first place unless the payoff was worth it. Since open source is free and clean and popular, its friggin awesome.

What else is in the "industry"?

[ZahrGnosis]

and both [proprietary and open-source software] continue to surpass the industry standard for software quality

... What else is there? And why is this unknown third type of code dragging down the "industry"?

Re:What else is in the "industry"?

[fredrated]

Exactly my question, what else is there besides proprietary and open source? How can they both surpass industry standards?

Re:What else is in the "industry"?

[swillden]

Exactly my question, what else is there besides proprietary and open source? How can they both surpass industry standards?

I think that's based on the unstated and unsupported -- but not entirely unreasonable -- assumption that proprietary and open source projects that don't care enough about quality to run Coverity on their code have lower quality levels than those that do.

However, I don't believe Google uses Coverity, and we have a pretty serious focus on code quality. At least, in my 20+-year career I haven't seen any other organization with quality standards as high as Google's, so I'd put Google forth as a counterexample to the assumption, and I'm sure there are many more. I have no idea if it the assumption is valid overall.

Re:What else is in the "industry"?

[Anonymous Coward]

Perhaps you've overlooked the little factoid that industry 'averages' and industry 'standards' are not the same?

Re:What else is in the "industry"?

[stillnotelf]

There is a huge third group: the military and aerospace industries. Unfortunately, their standards are even higher, like one bug per 420000 lines of code, so they're obviously not the group we need to make this math work.

Maybe the "industry standard" is whatever buggy math it is that makes that statement make sense to the original author?

Re:What else is in the "industry"?

[ZahrGnosis]

Military still seems "proprietary" to me. If they meant "commercial", I could see a difference. I also considered "embedded" or "firmware" style code that, while software, is more closely tied to a physical hardware implementation. All of those still seem either "proprietary" or "open source", though, and you're right (@stillnotelf) that these would raise rather than lower industry averages.

It could include things like javascript that is just out-in-the-wild. If you were to strip programmatic pieces from websites that were one-offs... things that were neither marketed nor sold, and not really managed as software, just put out there, code quality would probably drop. I'm thinking of websites with funny animations or just hand-coded scripts to do navigation or whatnot. These wouldn't be "open source" in the sense that there's no statement of open copyright, and they wouldn't be "proprietary" in the sense that noone is marketing or working to save or publish or reuse the code, and while copyright may exist noone is really worried about projecting it (due to the one-off nature). Still, it's a weird statistic.

I wonder if they meant a "standard" as in a target or an accepted limit that is somewhat arbitrary rather than an "average" (which the article actually uses) of real-world code. This would make sense since the average they cite is exactly 1.

Re:What else is in the "industry"?

[stillnotelf]

Military still seems "proprietary" to me. If they meant "commercial", I could see a difference.

You're right on the denotations...but I think by connotation and common use, there's a difference. For example, there is no way the US government is reporting bugs in its fighter jet code to Coverity, even anonymously. Maybe we can call military "ultraproprietary" or "hyperproprietary" or "guys-in-black-suits-etary." I think maybe the "standard" is the old average - in past years, with no way to accurately get data, error rates were estimated at 1 defect per 1000 lines. Now they're lower - either code is getting better, or the old estimate was too high.

Re:What else is in the "industry"?

[HaZardman27]

That is a very specialized segment of military you're referring to. I've been involved in enterprise software development in the military, and their standards weren't anything like that.

Re:What else is in the "industry"?

[Anonymous Coward]

It's easy. The standard is low. The statement doesn't say they are both above average, only that they are above standard. If the standard for fuel economy is 10 mpg, and all cars beat it, then you can say they all surpass industry standards.

Unforeseen consequences

[tedgyz]

Quality metrics can have unexpected side effects.

Re:Unforeseen consequences

[Alain Williams]

/* This
* comment
* is
* part
* of
* the
* corporate
* edict
* to
* reduce
* the
* defect
* rate
* reported
* by
* Coverity
*/
  printf("hello world\n");

Re:Unforeseen consequences

[rnturn]

Good grief... I certainly hope that Coverity's analyzer strips out comments before it starts evaluating code. Even the dimmest pointy-haired manager would see right through that scam.

Re:Unforeseen consequences

[Chris Mattern]

Most code metrics (except for those that specifically evaluate comments) strip out comments before compiling. However, you can always do this:

print
  (
      "hello world\n"
  )
;

Could probably split up the string too, but I'm too lazy to look up the exact syntax for that.

Re:Unforeseen consequences

[angel'o'sphere]

Most code metric tools don't use new line seither but only count ";", "," and "}".
(Because depending on definition ... see: Watts S. Humphrey, Personal Software Process ... every parameter you pass to a function is considered ONE LINE OF CODE).
So this: f(1, 3*4, "sup?") and this
f(1,
3*4
,
"sup?")
are the same kines of code.

Re:Unforeseen consequences

[Anonymous Coward]

Most code metric tools don't use new line seither but only count ";", "," and "}".

Well, then ...

#include <stdio.h>
 
int main(int argc, char** argv) /* the program takes no arguments, but the comma improves the Coverity score */
{
  {
    {
      {
        printf((((("dummy", 0, 0, "Hello world\n")))));;;;;;;;;;;;
;
;
        {
;
;
        }
      }
    }
  }
}

Re:Unforeseen consequences

[sjwt]

Or maybe it counts comments as errors, if you need to comment on your code, its not intuitive enough!

Re:Unforeseen consequences

[Anonymous Coward]

Oh look - somebody who's never used a static analysis tool.

Re:Unforeseen consequences

[Anonymous Coward]

But that's often true.

Re:Unforeseen consequences

[aardvarkjoe]

Good grief... I certainly hope that Coverity's analyzer strips out comments before it starts evaluating code. Even the dimmest pointy-haired manager would see right through that scam.

I'm pretty sure that you're underestimating how dim managers can be.

Re:Unforeseen consequences

[Anonymous Coward]

Also, you are assuming pointy-haired managers would even look at source code.

The quality fairy

[swm]

FTA:

As projects surpass one million lines of code, there’s a direct correlation between size and quality for proprietary projects, and an inverse correlation for open source projects.

The article gives numbers: above 1M LOC, defect density increases for open source projects, and decreases for proprietary projects.
Increasing defect density with size is plausible: beyond a certain size, the code base becomes intractable.
Decreasing defect density with size is harder to understand: why should the quality fairy only visit specially big proprietary projects?

Perhaps the way those proprietary projects get into the MLOC range in the first place is with huge tracts of boilerplate, duplicated code, or machine-generated code.
That would inflate up the denominator in the defects/KLOC ratio.
But then that calls the whole defects/KLOC metric into question.

Re:The quality fairy

[K. S. Kyosuke]

Decreasing defect density with size is harder to understand: why should the quality fairy only visit specially big proprietary projects?

That might have something to do with market penetration and resources dedicated to maintenance...? Those huge proprietary projects probably happen to be the stuff that almost everyone gets to use.

Re:The quality fairy

[Anonymous Coward]

Decreasing defect density with size is harder to understand: why should the quality fairy only visit specially big proprietary projects?

That might have something to do with market penetration and resources dedicated to maintenance...? Those huge proprietary projects probably happen to be the stuff that almost everyone gets to use.

Actually, what most likely happens is that for large corporate projects there's a quality initiative that is throwing actual resources at the code quality task - for example, static analysis tools, teams of QA, etc., etc., that are typically lacking from a large open source project.

Re:The quality fairy

[gutnor]

Maybe also 1 MLOC means popular in both OSS and Proprietary world. In proprietary, popular is slowly becoming legacy, the stuff you cannot change. On the other hand, in the OSS world, popular means load more contribution from people, the time they chose to keep quality on the core feature and the community go wild with the rest of the codebase.

Re:The quality fairy

[Anonymous Coward]

It's probably safe to assume that there's a direct correlation between the size of a project and its age; i.e. bigger projects are older and hence more mature.

In the proprietary arena, there is also a likely correlation between the age of a project and its popularity; i.e. unpopular ones don't get funded so they fail. And of course, there's a correlation between the popularity of a project and the amount of resources (e.g. man-hours) that can be spent on it because popularity translates directly to sales. And of course, the more resources spent on it, the better the quality.

In other words, big proprietary projects go along with big corporations that can afford to spend the time and money to fix the bugs.

Colours in graphs

[Alain Williams]

Why on earth do they choose 2 colours that are hard to tell apart in that graph ? They were black & dark blue. It took me several seconds to work out which was which. Many other reports/... seem to do similar.

Re:Colours in graphs

[drinkypoo]

Why on earth do they choose 2 colours that are hard to tell apart in that graph ?

here you go

Re:Colours in graphs

[maxwell demon]

I can see the difference immediately. Maybe it's your monitor settings?

Code quality

[140Mandak262Jamuna]

First of all code quality is difficult to measure, and the number of (known) defects per 1000 lines of code is a very poor metric. I could do more (good and bad) in one line of code than a novice who write voluminous code. Leaving that aside, what drives/motivates creating good quality code?

In open source, a defect gets fixed when someone feels the urge to fix it. Most of the time it is because it is their own dog food. Many open source projects are actually used by their own developers and they fix the issues that irritate them most. And rest of the bugs are based on impact on other users and passion about the software project

In a closed source project, it is often the bugs that affect the loudest paying customer gets fixed. If it is not going to advance sales, it wont get fixed.

Given this dynamic it is not at all surprising both methods have similar levels of that elusive "quality". I think software development should eventually follow the model of academic research. There is scientific research done by the universities that have no immediate application or exploitation potentials. The tenured academic professors teach courses and do research on such topics. Then as the commercialization potential gets understood, it starts going towards sponsored projects and eventually it goes into commercial R&D and product development.

Similarly we could envision people who teach programming languages to college maintaining open source projects. The students develop features and fix bugs for course credit. As the project matures, it might go commercial or might stay open source or it could become a fork. The professors who maintain such OSS projects should get similar bragging rights and prestige like professors who publish academic research on language families or bird migration or the nature of urban planning in ancient Rome.

Re:Code quality

[bussdriver]

Given the massive bias the US government has towards expensive private software contractors, I am surprised the results were so close.

MBAs, Politicians and incompetent journalists LOVE poor metrics. Americans love simplistic binary metrics (sorry no citation just experience, it's the culture.)

Remember klocs? That went on a while. Sounds like this metric dates back to those days-- they don't measure programmers by 1000s of lines coded anymore but they didn't learn their lesson and kept the defect rate measures...

Academics? Sciences? get with the real world, nobody bothers unless it is found to improve the bottom line Usually, it has to be forced to even be seriously considered... Proof by example using science and academic results is SUCH a change they call those who employ it "innovators" and they usually get all the undeserved credit as well.

Re:Code quality

[chrism238]

I think software development should eventually follow the model of academic research. There is scientific research done by the universities that have no immediate application or exploitation potentials. The tenured academic professors teach courses and do research on such topics. Then as the commercialization potential gets understood, it starts going towards sponsored projects and eventually it goes into commercial R&D and product development.

It sounds like you have a very 1980's appreciation of university research.

Re:Code quality

[Dcnjoe60]

Given the massive bias the US government has towards expensive private software contractors, I am surprised the results were so close.

Well, it could be that there really isn't a correlation between quality and what you pay for programming, at least beyond some point, so a good, but lower paid, open source programmer writes just as good code as a good, but higher paid proprietary programmer.

Or, it could be the higher paid programmers really do turn out better code, but the nature of open source, with multiple people reviewing it mitigates the difference. I hate to use a sports analogy, but I will anyway. I am a lousy golfer, but I can putt fantastically. If I am playing a normal round of golf, I will most likely lose. However, in a four man scramble, where the best ball is played, people want me on their team, because once the ball makes it to the green, I can usually get it in the cup with a single putt. Likewise, the programmers working on an open source project might not have the expertise as the high priced specialist, but they may have those who contribute the right parts to make the whole project successful.

I would venture that in reality, it is a combination of both of the above. Good programmers turn out good code, regardless of whether it is proprietary or open source. Plus, the open source model makes up for weaknesses in the skills of individual programmers.

Re:Code quality

[LeadSongDog]

number of (known) defects per 1000 lines of code is a very poor metric

It's not a poor metric, but it is a metric of something which isn't very useful. If I already knew the unfixed defects in the product, I'd just fix them.

More useful metrics relate to simplicity and testability. Is every module understandable on its own by a cleanroom reviewer who first saw it ten minutes ago? How free is the code from hand-tuning? How few parameters are passed? Are there state variables that go uninitialized? How small are the largest individual modules? How completely does the test code exercise all branches? How thoroughly has the test code itself been tested?

Re:Code quality

[bussdriver]

I meant to say the US Gov likes to support it's highly paid contractors who in turn "contribute" to it's politicians.

As far as software quality. It is largely a numbers game. The more eyeballs the better. Sure some people are better than others but overall the majority are of average skill and if you just throw a ton of them at it you'll more than make up for the smart ones. Open or not it comes down to the human power put into it. That being said, project leaders probably have more to do with success/failure than any other factor. Open source has the same problem; they can fragment too much, but private software can fail to fire managers quickly enough and there is zero choice outside of what marketing & management want.

Forks happen; revisions happen more often. So do you compare MS IE against Safari? KHTML? just webkit? or googles new fork? Do you use builds that remove apple and google cruft? If you don't need the bloat having less of it has to improve quality... even if you can't realistically measure quality - the larger the program the more space you have for bugs. Just as the higher the population the likely you have more crimes (which is why we use percentages on those statistics.)

Small well made components that work simply together is unix design philosophy and good software design- large distributed groups of developers will tend to work better and probably trend towards that; even with zero software engineering experience (which the private stuff has enough of to have similar aims but being more of a dictator like hierarchy they don't have to be.) Getting a 100% volunteer unpaid complex monolithic program out I would think would be a hard thing for open source to do... but I doubt most problems require that approach.

Re:Code quality

[Anonymous Coward]

This is exactly how BSD software used to evolve. Look for example a BerkeleyDB.
There's only one catch: this method ensures that the free version of the software is quasy-useless and second rate.

Re:Code quality

[Rich0]

First of all code quality is difficult to measure, and the number of (known) defects per 1000 lines of code is a very poor metric.

That word "known" is a BIG one. It is critical to the metric, and I'd strongly question whether the known vs actual ratio is the same in proprietary and open-source software. The latter usually makes it MUCH easier to report problems, but on the other hand usually involves less structured or regression testing.

If I'm using Openoffice and it doesn't paginate a document correctly I just log an entry on their bugzilla (or whatever they use). If MS Word does the same thing I hit print preview a few times and count to 30 before hitting print and hope it works, unless I buy 20k licenses from them.

"both continue to surpass the industry standard"

[Anonymous Coward]

Where everybody is above average. Or is there a 3rd category of software other than proprietary and open?

Re:firsty posteh?

[Anonymous Coward]

Dude,

Go in for treatment. Please.

Re:"both continue to surpass the industry standard

[Anonymous Coward]

Proprietary, open, and 'subject to endless litigation regarding its status' (SCO and friends), maybe?

Re: third kind of software

[rnturn]

``What is this third kind of software that is neither open source nor proprietary which is bringing down the average industry standard for software quality?''

Internally-written software that is not being released for ``external'' consumption, perhaps? There's likely far more of that in use than what is being sold for profit or being given away.

And eating toast CAN cause cancer.

[Anonymous Coward]

What, however, are the propensities for it compared to other sources?

Question?

[Dcnjoe60]

Code quality for open source software continues to mirror that of proprietary software — and both continue to surpass the industry standard for software quality. Defect density (defects per 1,000 lines of software code) is a commonly used measurement for software quality.

Since there are two types of software open source and proprietary and both of them surpass the industry standard for software quality, what exactly is the industry standard based on?

The article states that the industry standard is 1 defect per 1,000 lines of code. But at the rates given, open source is 1 defect in 1,449 lines of code and proprietary software is 1 defect in 1,470 lines of code. Maybe it's time to change the industry standard?

HIgher defect density indicates BETTER code

[raymorris]

Counterintuitively, defect density is actually an INVERSE indication of quality - better quality code will have MORE defects per line.
The reason I say that is because better code has fewer lines per problem. Consider strcpy(), a function to copy array of characters (a C string). You can't use strcpy() in your cd - you're supposed to create strcpy(), copying each element of the array.
Take a moment to consider how you'd write that before looking below.

Roughly how many lines of code did you use to copy an array? Here's what a typical corporate programmer might do:
while (source[i] != '\0')
{
    dest[i] = source[i];
    i++;
  }

So one error in that code would be 1 defect per five lines or so.

Here's all the code you need, what a better programmer would write:
while (*dest++ = *src++);

If the typical programmer and the expert both had exactly one error, the expert would have five times as many bugs PER LINE than the typical programmer! So you're better off with code that has a higher density of errors - better code will have fewer lines per error.

This is the same reason LOC is an inverse indicator of productivity. Yesterday I fixed a junior programmers code tat looked like this:

if ($category = 'rings') {
        $page = 'rings.html'
}
if ($category = 'necklaces') {
        $page = necklaces.html'
}
if ($category = 'bracelets') {
        $page = 'bracelets.html'
}
if ($category = 'loose_stones') {
        $page = ''loose_stones.html'
}
if ($category = 'charms') {
        $page = 'charms.html'
}

Of course I changed that code to, well, zero lines, I just used the $category variable where he had used the $page variable. Code which accomplishes a task in zero to one line is better software, written by a better programmer, than code that uses eightteen lines to accomplish the same thing.

Re:HIgher defect density indicates BETTER code

[Anonymous Coward]

I sure hope it didn't look like that, because users will always end up at 'charms.html', no matter what category you selected. (Senior tip: you're gonna want to use == for comparison, friend.)

Furthermore, you've determined that the category and the page name will ALWAYS match in the way that you've hard-coded? There's certainly more efficient ways of doing this mapping, but frankly, your code is more brittle and will require FAR more changes the first time the category-to-page mapping ever changes such that $page != "$category.html". Category could never become 'settings & mounts', for example?

But sure, Junior, given your clear ability to write clean, bug-free code... tell us all your thoughts about how best to determine software quality, and how software is improved by ripping out lines with no thought to the longer term ramifications of that action.

And one last thing: an "expert coder" would know that there's zero value in re-implementing strcpy, and would use a reference implementation that's been tested by hundreds of thousands of other programmers already, rather than retyping the same goddamned thing himself, and introducing errors like you did in your "here's what the junior coder did," example. A junior coder would be the one smugly congratulating himself on wasting time reinventing the wheel instead of delivering a usable product.

Re:HIgher defect density indicates BETTER code

[Rich0]

Here's all the code you need, what a better programmer would write:
while (*dest++ = *src++);

The problem with that is that when the next non-expert developer comes along they won't grok the code and might break something when things change. Suppose the string delimiter changes for some reason - would a non-expert even appreciate that you're checking for the delimiter there?

Compact code is not necessarily better, unless you accompany it with a comment or something. You also omitted the extra code to set your pointers to the start of the string (though you also omitted initializing your loop counter). Your code would definitely perform better, assuming the compiler didn't appreciate the effects of the loop and implement it in the same way. Actually, I might be wrong on performance - I'm not sure if a move against two indexed memory locations is slower on modern x86 than a MOVSB or whatever. The loop would also be fewer instructions with the MOVSB though I'm not sure if that matters on a modern processor with all the hardware optimizations/etc. I know that x86 can reference indexed memory locations in a single opcode, though not all x86 instructions execute in the same number of clocks...

Re:HIgher defect density indicates BETTER code

[maxwell demon]

And the next day the $category "partner_shop" was added, whose $page is "http://partnershop.com/landing_page.php?partner=your_shop" ...

Re:HIgher defect density indicates BETTER code

[chgros]

while (source[i] != '\0')
{
        dest[i] = source[i];
        i++;
    }

So one error in that code would be 1 defect per five lines or so.

Here's all the code you need, what a better programmer would write:
while (*dest++ = *src++);

Your "better code" is actually not equivalent (the first loop doesn't copy the nul terminator). Even if it was equivalent, I don't think I would necessarily call it "better". This particular piece happens to be fairly idiomatic and many would understand it, but cramming as much semantics in one line as possible is usually not a good idea. I agree that in general less code is better for equivalent behavior, but usually that means better factoring, not putting more code in one line.

Re:HIgher defect density indicates BETTER code

[Subject-17]

Ahem.
while ( strcmp( (*dest++ = *src++), '\0') != 0 );
or, if you feel that's a bit much (personally, I do)
while ( (*dest++ = *src++) != '\0' );

Otherwise, yeah, much agreed.

Also, I'd still have a

if ( !empty($category) )
$page = $category + '.html';

just for readability's sakes. Also, if you ever need to handle a category in a custom fashion, it's easy to modify the code as such:

if ( empty($category) ) {
//Error! Mayhaps set $page to "#"?
}
else if ( strcmp($category,'value') === 0) {
//set page to something special
}
else { //default behavior
$page = $category + '.html';
}

Using a switch would be good to, but you'd still have to text for emptyness before calling the switch

Anyway, probably procrastinated too much here as is

Open is better

[Murdoch5]

The more eyes that can view a piece of code the more bugs can be spotted and the better the algorithm development can be. Open source code is also a great way to teach young developers because the best way to learn to programming to is to read code and program, something which can't be easily done by locked down software.

At least half of those lines

[Anonymous Coward]

At least half of those lines come from PHP alone! Magnificent!

the inconvenient truth

[Anonymous Coward]

most "open source" is written by people working for corporations, so this comparison is idiotic in its design.

Define "defect"

[chill]

What are they counting as a "defect"?

Their FAQ lists example, but ends with "and many more".

Which leads us to the question of who set the "industry standard" at 1.0, and what did THEY define "defect" to mean? If it is a standard there should be a standard list of defect types.

Re:Define "defect"

[Anonymous Coward]

They define "defect" as "defects we can detect with our static analyzer" which allegedly covers a significant share of programming errors (not logic errors).

WTF does this have to do with "Homeland Security"?

[moeinvt]

"Coverity Scan service ... was initiated between Coverity and the U.S. Department of Homeland Security"

If software is a "Homeland Security" issue, shouldn't they be focusing on the proprietary software that most consumers, businesses and government agencies are using?

what is a defect?

[hraponssi]

the article mentions "defect" 18 times but does not define it. a few examples in the end but really, what are they measuring?

Defect density by itself is a poor metric.

[flayzernax]

You can have poorly written code, but a good program.

You can have perfectly written code, but a shoddy bit of software.

Take for example an OS that hangs because the network layer is pegging the CPU somewhere some how.

Vs an OS that continues to be responsive even if the network layer overloaded.

So if they are looking at .69 defect density vs .68 defect density. The community driven software which is designed for an end user vs for a marketing staff to force up-on an end user is going to be close to 100% better.

Re:WTF does this have to do with "Homeland Securit

[Anonymous Coward]

Most OSS projects, even when used in critical places, don't have the money to pay for this very expensive (AFAIK ~ 50k$) tool. Proprietary vendors get payed for their product and can spend money for this tool or other ways (like more staff) to reduce the defects.

HACK THE PLANET!

[Anonymous Coward]

HACK THE PLANET!

Re:WTF does this have to do with "Homeland Securit

[servognome]

It doesn't matter if it's proprietary or open source, the danger is in any system that is compromised.
Homeland security needs to protect infrastructure and other interests that can impact that state of the nation. Something as benign as somebody hacking the AP twitter feed and posting that a bomb injured the president cost the market over $100B. A series of hacking attacks can result in economic or social destabilization.
Software is also built in layers, so some parts are proprietary, others are open, but a vulnerability in either one can cause issues with all parts of the system.

And betamax was better....

[Tomsk70]

...and look how that turned out.

Yuh Huh

[Greyfox]

Just because you get paid to program doesn't mean you crap daisies and unicorns.

I've seen the guts of a fair bit of commercial code, and it's usually not that great. Couple of stories; back in the OS/2 days I had a customer complain that the OS/2 time API specified you could set milliseconds, but this didn't appear to be the case. Well I just so happened to have access to the assembly language function in OS/2 that did that (IIRC it was shipped on one of their dev CDs) and upon examination it appeared that it was keeping an eye on 2 different interrupts. The first one was a clock tick interrupt that happend every few milliseconds and incremented the millisecond counter by however many milliseconds that was (22 sticks in my head for some reason.) However, a comment in the function stated that these could occasionally be missed, and so whenever the periodic 1-second interrupt rolled around, it would zero the millis out. Brilliant.

Every IBM story should have a Sun story to go along with it, as karmic retribution for that time I was walking along behind some of their engineers and they were dissing on the code quality in the Linux kernel. Yeah well, I've seen the code out of Sun, too. Like that webapp they did where all the authentication routines were static methods. Worked great as long as there was only one user!

If anything, professional programmers are on average worse. I had to clean up behind one, back in the '90's, who didn't realize that C strings were null terminated. Every fucking string in her code (Which she'd apparently NEVER compiled or run) was exactly long enough for the constant string she was assigning. These people sneak into your company and work there until getting caught. Usually they have another job lined up and bail just before getting caught. At least the open source guys ENJOY programming.

Bad business processes

[OrangeTide]

What this tells me is that current business practices are flawed. There are commercial software companies that are able to produce quality code that exceed most, if not all, open source projects. But such companies are not the norm.

Here are some questions we should ask:
1. Does commercial software have a realistic incentive to reach for excellence in coding? Maybe..
2. Does commercial software have enough resources to produce excellent software? Demonstratable so, but..
3. Does commercial software use their resources efficiently and effectively? I suspect not.

what is a fault?

[umghhh]

It strikes me that over last few years I see less and less faults indeed. The way I look at it tho is that people will automatically reject the idea that the software is at fault unless it brakes in a visible way. Other than that you are for a tough discussion about it and unless you have it black on white that something should do B after A but it does C instead you have no chance. In other words - because we skipped the specification phase we do not have a specification we can verify the applications against i.e. we have less faults....

OTOH majority of code is not hand written anyway but copy-pasted and/or automatically generated by some fancy tool so of course you have less faults.

Amazing

[Anonymous Coward]

Tomorrow's headline:

"Unfortunately, a bug in the code used to detect programming errors caused these estimates to be severely under-estimated..."

The definition of defect

[Anonymous Coward]

Presumably the definition of defect is something flagged by Coverity, a tool similar to lint. We use where I work. It is slightly better than gcc -Wall or g++ -Wall. Being clean in Coverity is like being clean in any such tool. It finds a lot of dangerous code and brain-dead bugs, but can't ensure good or correct code.

Selection bias

[DaveV1.0]

If the 300 open source projects weren't randomly selected (and judging from the article, they weren't), they aren't a representative sample of open source projects.

Re:Selection bias

[OrangeTide]

did they select 300 open source projects that weren't abandoned because of excessive bugs?

Although I do find Banshee, Miro, Amarok, Rhythmbox, and xnoise to be very buggy for open source software. (all music player apps) But, I'm not sure if those were included in this study, I suspect most of them were.

Re:Selection bias

[DaveV1.0]

You suspect? No, you hope because it would feed into your world view that FLOSS is as good, if not better, than proprietary software. But, without how and which projects were selected, this is just a bunch of propaganda. The thing that really sticks out to me is that the projects listed in the article all have paid contributors. That would be people being paid to work on the code. Something that you won't see in the vast majority of FLOSS projects because they don't have corporate patrons and they don't earn any money.

What does it mean to be a professional programmer?

[OrangeTide]

There is a big difference between getting paid to show up to work, and getting paid to write solid robust software.

Re: third kind of software

[Anonymous Coward]

For fuck sake, PLEASE STOP THAT! ` ` and ' ' are NOT proper quotation marks!

And yet it continues to suck (mostly)

[wakeboarder]

First off: I'm glad that people write software and don't care about being compensated for it. But I continually find that open source software is written by programmers for programmers. I'm an engineer, when I sit down at a piece of software, I expect it to work and be able to use it intuitively. Most open source projects write code or come up with gui's that are so arcane it takes you a week to figure out how to use it, I don't have that kind of time and I don't have that kind of time when I work. I've picked up several block diagram programs that are free\open source in the last few days, they are not intuitive and have a huge learning curve just to get them to work. Paid projects have people that sit around all day and says "How can I improve the interface to make it more usable"

Your points have all been disproven over and over

[Anonymous Coward]

http://slashdot.org/comments.pl?sid=3040317&cid=40946043
http://slashdot.org/comments.pl?sid=3040729&cid=40949719
http://slashdot.org/comments.pl?sid=3040697&cid=40949343
http://slashdot.org/comments.pl?sid=3040597&cid=40948659
http://slashdot.org/comments.pl?sid=3037687&cid=40947927
http://slashdot.org/comments.pl?sid=3040425&cid=40946755
http://slashdot.org/comments.pl?sid=3040317&cid=40946043
http://slashdot.org/comments.pl?sid=3038791&cid=40942439
http://slashdot.org/comments.pl?sid=3024445&cid=40942207
http://slashdot.org/comments.pl?sid=3038597&cid=40942031
http://slashdot.org/comments.pl?sid=3038601&cid=40942085
http://slashdot.org/comments.pl?sid=3040803&cid=40950045
http://slashdot.org/comments.pl?sid=3040867&cid=40950563
http://slashdot.org/comments.pl?sid=3040921&cid=40950839
http://slashdot.org/comments.pl?sid=3041035&cid=40951899
http://slashdot.org/comments.pl?sid=3041081&cid=40952169
http://slashdot.org/comments.pl?sid=3041091&cid=40952383
http://slashdot.org/comments.pl?sid=3041123&cid=40952991
http://slashdot.org/comments.pl?sid=3041313&cid=40954201
http://slashdot.org/comments.pl?sid=3042199&cid=40956625
http://slashdot.org/comments.pl?sid=3029723&cid=40897177
http://slashdot.org/comments.pl?sid=3029589&cid=40894889
http://slashdot.org/comments.pl?sid=3027333&cid=40886171
http://slashdot.org/comments.pl?sid=3042451&cid=40959497
http://slashdot.org/comments.pl?sid=3042547&cid=40960279
http://slashdot.org/comments.pl?sid=3042669&cid=40962027
http://slashdot.org/comments.pl?sid=3042765&cid=40965091
http://slashdot.org/comments.pl?sid=3042765&cid=40965087
http://slashdot.org/comments.pl?sid=3043535&cid=40967049

Re:Your points have all been disproven over and ov

[Anonymous Coward]

You sure did own apk hard. He's not going to reply because he's crying to his mommy. apk has proven himself to be technically incompetent and unemployable time and time again. Congratulations to brave people like you who put him in his place. I can't believe how thoroughly you DESTROYED him. Great job.

Re:Your points have all been disproven over and ov

[Anonymous Coward]

I agree -- apk gets his ass spanked every time he posts. He must have a fetish for being spanked or else he'd stop coming back for more.

Re:Your points have all been disproven over and ov

[Anonymous Coward]

You guys are right -- APK completely demolished in this tech debate as he always does. Why does he keep coming back for more when he knows he'll never win?

Auto correcting code

[peawormsworth]

Defect density (defects per 1,000 lines of software code) is a commonly used measurement for software quality. The analysis found an average defect density of .69 for open source software projects, and an average defect density of .68 for proprietary code.

If its that easy to determine which lines of code are defective, then why not simply allow the detection software to make the fix? For example, if you are certain the code is incorrect, then you certainly must know what is the correct code, or you cannot say for sure that it is wrong.

Bad Metric — Lines of Code

[oldCoder]

Let's say two different programs, A and B, do the same thing, and they each have 6 bugs. If program A has twice as many LoC (Lines of Code) as program B, then program A gets the higher score! Program A has half the error density of program B; But program A is clearly inferior, as it uses more memory, uses more disk space, probably runs more slowly, and is harder to debug.

I can easily fatten up any program to use more LoC, and not just with newlines, with real code, that might even be executed now and then. Coverity could, I suppose, counter my sabotage with a code-coverage tool to find the bloat, but there are sneaky ways to fool that, too.

So you're saying the longwinded code is broken

[raymorris]

Your "better code" is actually not equivalent (the first loop doesn't copy the nul terminator).

So you're pointing out that the longwinded code doesn't even result in a valid C string. Ergo, the longer code is broken.

<quote> Even if it was equivalent, I don't think I would necessarily call it "better".</quote>

The authors of every major language library call it "better". That example is copy-paste from glibc and everyone from Stroustrup to Knuth has used the same code.
Given that Knuth knows far better than anyone on Slashdot, I'll stick with what he uses.

Jeremiah Cornelius: Grow up

[Anonymous Coward]

You're embarassing yourself Jeremiah Cornelius http://slashdot.org/comments.pl?sid=3581857&cid=43276741 since you posted that using your registered username by mistake (instead of your usual anonymous coward submissions by the 100's the past 2-3 months now on slashdot shown in your post I just repiled to in fact) giving away it's you spamming this forums almost constantly, just as you have in the post I just replied to.

Re:Jeremiah Cornelius: Grow up

[Anonymous Coward]

Shut up, Paul.

You've gotten badly owned in every tech debate on Slashdot.

There will never come a day where you will when.

You're just pathetic.

Go away.

Re:Jeremiah Cornelius: Grow up

[Anonymous Coward]

That wasn't the case in the 3 links posted here on hosts http://it.slashdot.org/comments.pl?sid=3725365&cid=43659719 where APK pwned you anonymous coward trolls. You failed.

Re:Jeremiah Cornelius: Grow up

[Anonymous Coward]

Just who is this "Paul"?

Please. Let us all in on the game.

Re:Jeremiah Cornelius: Grow up

[Anonymous Coward]

"Paul" is my name for when APK posts unsigned posts pretending to be an "APK supporter" (something that doesn't actually exist). It's very obvious that it's him posting them, and somewhat amusing that he persists in this lunacy. Basically "Paul" is one of APK's alternate trolling personas (or maybe a legitimate alternate personality). I based the name on the phrase "robbing Peter to pay Paul".

Re:Jeremiah Cornelius: Grow up

[Anonymous Coward]

Interesting. I get it.

I like "The Walrus was Paul" as in "Paul is dead."

Re:Your points have all been disproven over and ov

[Anonymous Coward]

Didn't appear to be the case here, 3x in a row http://it.slashdot.org/comments.pl?sid=3725365&cid=43659719 and all of Jeremiah Cornelius' "$10,000 Challenge" spams don't count. They're purest trolling, the only thing he does (like the online pest he is).

Jeremiah Cornelius = Paul

[Anonymous Coward]

He won't answer a simple question http://slashdot.org/comments.pl?sid=3733655&cid=43678303 (since he outright lies on trolling others by ac posts, uses sockpuppets galore, & was caught doing so in the link below red-handed), & he also claims to have worked at Microsoft (b.s., imo because of what I state next), & yet got completely spanked by "yours truly" on actual computer technical information regarding custom hosts files - very fundamental networking & algorithmically oriented stuff no less, real CSC-101 stuff http://it.slashdot.org/comments.pl?sid=3725365&cid=43659719 (which he can't disprove, but it certainly did prove his ac trollings which he outright lied about & by the 100's that he gave away he was doing here http://slashdot.org/comments.pl?sid=3581857&cid=43276741 ).

Bottom-line here? Hey - Unlike YOU, I don't NEED 'support' like you do, sockpuppet master: Facts did you in & they're ALL I need.

APK

P.S.=> You fail Jeremiah Cornelius - you're pitiful... apk