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: RobG on 8 Apr 2010 10:27 On Apr 8, 4:22 pm, Andrew Poulos <ap_p...(a)hotmail.com> 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." The context has been lost here. The Wikipedia article is mostly about using lines of code to estimate the size and complexity of a project. Clearly, in that context, 10,000 lines of code will almost certainly have more bugs than 10 as the application and the functionality it provides is much more complex. Note also that many software bugs are not coding errors per se but specification errors - the code may be doing exactly what the programmer intended it to do, but that may not be what the client wanted. My original comment was about the amount of code used to implement a particular piece of functionality. In that case, you are comparing maybe 3 or 4 lines of plain JS code with one or two lines of jQuery. There's a thread on the jQuery forum that demonstrates the issue perfectly: <URL: http://forum.jquery.com/topic/retrieving-value-of-checkbox-in-table-cell > where a reply to a question comes up with the following line of code (my wrapping): $('#myCheckBox').attr("checked", $('td input[type=checkbox]', this).attr("checked") ); The plain JS equivalent might be (presuming a reference to the row in question has already been found): var el = document.getElementById('#myCheckbox'); el.checked = row.getElementsByTagName('input')[0].checked; The plain JS is an extra 20 characters and is two lines not one, it could be either more concise or longer and more robust depending on things like whether it should deal with zero, one or many inputs in the row and so on. Despite its extra length, I'll bet it runs very much faster than the jQuery equivalent (although the jQuery can likely be optimised for speed). Regardless, I know which one I'd be happier trying to debug, maintain or optimise. -- Rob
From: Matt Kruse on 8 Apr 2010 10:59 On Apr 8, 9:27 am, RobG <rg...(a)iinet.net.au> wrote: > where a reply to a question comes up with the following line of code > (my wrapping): > $('#myCheckBox').attr("checked", $('td input[type=checkbox]', > this).attr("checked") ); > The plain JS equivalent might be (presuming a reference to the row in > question has already been found): > var el = document.getElementById('#myCheckbox'); > el.checked = row.getElementsByTagName('input')[0].checked; Absolutely, using jQuery for stuff like this is absurd. Or at least using it in this way is absurd. The _biggest_ problem I have with jQuery is that users tend to start solving every problem in "the jQuery way", which is often unnecessary and obfuscates otherwise very clear code. It's adding a layer where none is needed. My original comment about LOC, though, refers more to writing code to do a task when you could just call reusable code. Writing your own code to add/remove a class on hover of an object is surely more error- prone than calling something like: $(element).hoverClass('hover'); So reducing to 1 LOC has a real advantage in reducing the potential for bugs, assuming the method called is known to work correctly. Reducing LOC by just compacting syntax and reducing clarity rather than wisely calling reusable methods is often setting yourself up for MORE bugs, as I think you pointed out. Matt Kruse
From: "Michael Haufe ("TNO")" on 8 Apr 2010 11:31 On Apr 8, 2:02 am, Antony Scriven <adscri...(a)gmail.com> wrote: > > add x y = x - y > > :-) Looks like a feature to me. "add" is cromulent for subtraction.
From: Antony Scriven on 8 Apr 2010 11:49 On Apr 8, 4:31 pm, Michael Haufe wrote: > On Apr 8, 2:02 am, Antony Scriven <adscri...(a)gmail.com> wrote: > > > add x y = x - y > > > :-) > > Looks like a feature to me. "add" is cromulent for > subtraction. You of all people should know that that doesn't apply during divulsification.
From: Garrett Smith on 8 Apr 2010 14:03
RobG wrote: > On Apr 8, 4:22 pm, Andrew Poulos <ap_p...(a)hotmail.com> 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: [...] > > $('#myCheckBox').attr("checked", $('td input[type=checkbox]', > this).attr("checked") ); > > The plain JS equivalent might be (presuming a reference to the row in > question has already been found): > > var el = document.getElementById('#myCheckbox'); .......................................^ Invalid character for an ID. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |