"Professional Javascript" review
in [JavaScript]
|
Prev: Limit of 4K
Next: Detecting Internet Explorer 6
From: David Mark on 1 Nov 2009 15:54 On Nov 1, 3:37 pm, VK <schools_r...(a)yahoo.com> wrote: > John G Harris wrote: > > You're just upset that no-one wants to believe your complicated and > > incoherent description instead of our simple and clear version. > > ------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If that was a joke then a really good one - I admit it. Isn't that always the way? People who refuse to read and learn get frustrated and blame the messenger for unwanted epiphanies. Easier to live in Fantasyland I guess.
From: Garrett Smith on 4 Nov 2009 22:45 kangax wrote: > Garrett Smith wrote: >> kangax wrote: >>> Here's a review of "Professional Javascript" by Zakas >>> (http://thinkweb2.com/projects/prototype/professional-javascript-review/) >>> >>> >> Review review: >> >> From the review: >> | "Logically, a null value is an empty object pointer" >> Plainly false. Null is a primitive value. In java (not javascript) >> Reference Variables can have the value null, and what is written above >> is conceptually fine for programming in java, but the type of thinking >> might be better off abandoned for javascript programming. > > Which is why I wrote "Some things in this chapter sound questionable". Yes, that was clear. [snip] >> There is a long standing bug in JScript (still in the latest in IE8) >> where the parameter in a |catch| block does not result in augmented >> scope for that block. Instead, the identifier is added to the containing >> scope. >> >> Is this not mentioned? > > It is. Here's an excerpt: > Ah, good. >> >> Yep. >> >> The FAQ should really have a section on Functions. > > Or just a link to NFE article ;) > It explains functions thoroughly. For FAQ, maybe a short section with 1-2 questions, though. For example: What is |(function(){ /*...*/ })()| ? A link to the closure article, and NFE article. [snip] >> >> | It would be nice to see alternative example which would avoid run-time >> | try-catch in favor of single load-time test >> >> I see. The performance video "speed up your javascript" also has an >> example doing the same thing (against advice in that same video). > > YUI is doing it too. > Could have used a generalization inference. By abstracting common properties of instances, a general formulation of how other such instances will behave can be inferred. Such as: var CAN_SLICE = false; try ( [].slice.call(document.childNodes); CAN_SLICE = true; } catch(ex) { } > One could argue that it's a safer approach (testing features at run > time) but I have yet to see an implementation where, say, one element > would have certain property/method and another element (of the same > type) � didn't. > Making an assertion about the specific object based on what it does would be stronger than making an assertion about what something similar does. However, generalization inference should not be ruled unsafe; the situation needs to be examined to determine if such inference is suitable. >> >> | There were moments when I didn�t share same vision as Mr. Zakas, such >> | as the one where he recommends to use comments in places where there >> | are large amounts of code; I believe in a different approach � >> | breaking code into smaller, more understandable chunks, rather than >> | adding comments on top. >> >> Your review should recommend your influence on advice for writing such >> "clean code". > > Not sure what you mean here. > You mentioned the book "Clean Code" to me before. That book discusses functions with a strong emphasis on small functions. In video: http://www.viddler.com/explore/RoyOsherove/videos/15/ (Jorge should appreciate that) Reminds me of last visit to the local planetarium... Anyway, past the intro, he talks a bit about functions. Basically, the same thing you're talking about -- keeping them short. I've found that when I want block scope, it's time to consider another function. Example: function a(){ var a, b, c, d, // statements. // [...] if(condition) { var q, w, e, f; } } Contrived, but what I would consider in refactoring, is to extract the part in the if(condition), followed by the vars, an eligible candidate for Extract Method. [snip] > If someone is looking for a book, this is the one I would recommend (and > maybe Flanagan's too). However, nothing compares to reading specs, clj > archives and constant practice. At least, this is how I grokked most of > what I know about Javascript :) > Practice, discussion, testing, code reviews. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: kangax on 9 Nov 2009 12:59
Garrett Smith wrote: > kangax wrote: >> Garrett Smith wrote: [...] >>> The FAQ should really have a section on Functions. >> >> Or just a link to NFE article ;) >> > > It explains functions thoroughly. > > For FAQ, maybe a short section with 1-2 questions, though. > > For example: > > What is |(function(){ /*...*/ })()| ? > > A link to the closure article, and NFE article. That would make sense. [...] >>> >>> | It would be nice to see alternative example which would avoid run-time >>> | try-catch in favor of single load-time test >>> >>> I see. The performance video "speed up your javascript" also has an >>> example doing the same thing (against advice in that same video). >> >> YUI is doing it too. >> > Could have used a generalization inference. > > By abstracting common properties of instances, a general formulation of > how other such instances will behave can be inferred. > > Such as: > var CAN_SLICE = false; > try ( > [].slice.call(document.childNodes); > CAN_SLICE = true; > } catch(ex) { } Yep, that's what I was referring to. Unfortunately, nothing like that was present in a book. > > >> One could argue that it's a safer approach (testing features at run >> time) but I have yet to see an implementation where, say, one element >> would have certain property/method and another element (of the same >> type) � didn't. >> > Making an assertion about the specific object based on what it does > would be stronger than making an assertion about what something similar > does. Definitely. > > However, generalization inference should not be ruled unsafe; the > situation needs to be examined to determine if such inference is > suitable. And time shows that this inference is generally safe. We'll see how it turns out to be in the future. > >>> >>> | There were moments when I didn�t share same vision as Mr. Zakas, such >>> | as the one where he recommends to use comments in places where there >>> | are large amounts of code; I believe in a different approach � >>> | breaking code into smaller, more understandable chunks, rather than >>> | adding comments on top. >>> >>> Your review should recommend your influence on advice for writing such >>> "clean code". >> >> Not sure what you mean here. >> > > You mentioned the book "Clean Code" to me before. That book discusses > functions with a strong emphasis on small functions. > > In video: > http://www.viddler.com/explore/RoyOsherove/videos/15/ > (Jorge should appreciate that) > > Reminds me of last visit to the local planetarium... > > Anyway, past the intro, he talks a bit about functions. Basically, the > same thing you're talking about -- keeping them short. Yes. Keeping them short is the key to success :) Easy to comprehend, easy to maintain, easy to test, easy to refactor. It adds more overhead, though. We all know how function calls can slow scripts down, especially in older engines without optimizations. > > I've found that when I want block scope, it's time to consider another > function. > > Example: > > function a(){ > var a, b, c, d, > > // statements. > // [...] > if(condition) { > var q, w, e, f; > } > } > > Contrived, but what I would consider in refactoring, is to extract the > part in the if(condition), followed by the vars, an eligible candidate > for Extract Method. Exactly. [...] -- kangax |