jQuery crashes again
in [JavaScript]
|
Prev: FAQ Topic - How do I generate a random integer from 1 to n? (2010-04-03)
Next: active (x)html newsgroup?
From: Matt Kruse on 7 Apr 2010 22:27 On Apr 7, 8:51 pm, RobG <rg...(a)iinet.net.au> wrote: > > Plus, more code written = more opportunity for bugs. That's a > > given. > No, it's not. > Do you have statistics showing a correlation between lines of code and > number of bugs for pieces of code that provide equivalent > functionality or implement equivalent logic? I'm not going to go look it up, but I have the impression that I've read statistics to this effect many times. Fewer LOC = Fewer bugs I may be incorrect. Of course, it's not a 100% rule. Compact code that obfuscates clear logic is not preferrable to more readable code. But generally speaking, in larger projects, if you can write fewer lines of code then I think you will have fewer bugs. Why? Because if you solve a problem once and it is correct, then each time to call it you are getting correct behavior AND you are reducing duplicated code to a single function call. So reducing LOC by obfuscation is not good, but reducing LOC by reusing as much as possible is a good thing. > 2. I am certainly not accusing you (or anyone else here) of that, but > it tends to be the more arrogant and over-confident developers who > insist on writing the most concise code they can, to the point of > obfuscation. They are a PIA. Indeed. And the jQuery source used to be very much more in this direction, which they have fortunately moved away from for the most part. Matt Kruse
From: "Michael Haufe ("TNO")" on 8 Apr 2010 01:22 On Apr 7, 9:27 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > I'm not going to go look it up, but I have the impression that I've > read statistics to this effect many times. > Fewer LOC = Fewer bugs > I may be incorrect. A correlation perhaps, I doubt anything more can be proven. In Haskell for example, if the code compiles then it has no bugs (or so the saying goes).
From: Andrew Poulos on 8 Apr 2010 02:22 On 8/04/2010 3:22 PM, Michael Haufe ("TNO") wrote: > On Apr 7, 9:27 pm, Matt Kruse<m...(a)thekrusefamily.com> wrote: >> I'm not going to go look it up, but I have the impression that I've >> read statistics to this effect many times. >> Fewer LOC = Fewer bugs >> I may be incorrect. > > A correlation perhaps, I doubt anything more can be proven. In Haskell > for example, if the code compiles then it has no bugs (or so the > saying goes). <url: http://en.wikipedia.org/wiki/Source_lines_of_code > states that "A number of experts have claimed a relationship between the number of lines of code in a program and the number of bugs that it contains. This relationship is not simple, since the number of errors per line of code varies greatly according to the language used, the type of quality assurance processes, and level of testing, but it does appear to exist." Though the experts are unnamed and no citation is provided. Andrew Poulos
From: Antony Scriven on 8 Apr 2010 03:02 On Apr 8, 6:22 am, Michael Haufe wrote: > On Apr 7, 9:27 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > > > I'm not going to go look it up, but I have the > > impression that I've read statistics to this effect > > many times. > > Fewer LOC = Fewer bugs > > I may be incorrect. > > A correlation perhaps, I doubt anything more can be > proven. Minimising complexity is the key issue and LOC is just one place to look for that, and certainly it's sometimes the wrong place to look. Anecdotally, I reckon I see and make more bugs in SQL than any other language, and it is very concise for its problem domain. In this case the language is simple but the entities being manipulated are complex (cf. jQuery). Another anecdote. When colleagues have asked me for help with fixing bugs in javascript, I would recommend a two-stage process. First, remove all $ symbols. Second, run the code through JSLint. The effect this simple process has had on eliminating bugs is remarkable. Notice that both stages have a general effect of reducing complexity, even if you end up with a few extra lines of code. Finally, I think it's worth mentioning that of course abstraction can be a very powerful tool, but it's of paramount importance that library code is of the highest quality. Furthermore, if you don't have a support contract then you have to be in a position to debug and fix library code yourself if something goes wrong. And the internals of jQuery are very complex, which is something you have to weigh against any perceived gain in using the library. > In Haskell for example, if the code compiles then it has > no bugs (or so the saying goes). add x y = x - y :-) --Antony
From: Antony Scriven on 8 Apr 2010 03:18
On Apr 8, 7:22 am, Andrew Poulos wrote: > On 8/04/2010 3:22 PM, Michael Haufe ("TNO") wrote: > > > On Apr 7, 9:27 pm, Matt Kruse<m...(a)thekrusefamily.com> > > wrote: > > > I'm not going to go look it up, but I have the > > > impression that I've read statistics to this effect > > > many times. Fewer LOC = Fewer bugs I may be > > > incorrect. > > > A correlation perhaps, I doubt anything more can be > > proven. In Haskell for example, if the code compiles > > then it has no bugs (or so the saying goes). > > <url:http://en.wikipedia.org/wiki/Source_lines_of_code> > states that > > "A number of experts have claimed a relationship between > the number of lines of code in a program and the number > of bugs that it contains. This relationship is not > simple, since the number of errors per line of code > varies greatly according to the language used, the type > of quality assurance processes, and level of testing, but > it does appear to exist." You snipped the opening quotation, which I think is more relevant: `The central enemy of reliability is complexity. Geer et al.' > Though the experts are unnamed and no citation is > provided. You've found an anecdote about an anecdote, which is even flimsier than my evidence. Something not mentioned is the complexity of the bugs involved. A bug deep inside complex library code could be much harder to fix than several off-by-one errors, say. It becomes especially hard if `fixing' the bug breaks other code. --Antony |