Michael, I recently read Crockford's book "The Good Parts" and I absolutely share your opinions about bowing down to the master! That said, I think that his arguments simply make a lot of sense more than anything else, and it's useful to have a prescribed style at least to _start_ with, rather than picking and choosing at will.
Roderigo, I've been hacking a bunch of javascript lately, and thought I'd reply to some of your admirably empassioned comments! > Regarding Crockford code writing rules, I've heard about him but have never > been interested on reading his tips at all... I don't like the idea of > following some rules without understanding the reasoning. Since I never had > problem in organizing my js, I didn't find the need for looking for some > guides on this topic. Crockford's rules are backed by pretty strong logic. I'd recommend reading "The Good Parts" ... he has some compelling arguments. My personal opinion on organization of js that we should have some consistency. Unlike Rails, where I always feel I know where to put my code, with js it often feels like I'm guessing. > For example, once you know the caveats of not using the semi-colons, I don't > see any problems in using that feature. Actually, I dislike using > semi-colons since the code is cleaner for my taste when not using > semi-colons, unless you have multiple statements in the same line. Yes this > can make sense, for instance: One of the arguments for consistent semi-coloning is that in some cases, non properly ended statements will break js minifier tools. Given the huge surge in gzipping and minifying JS for performance, and the hassle of trying to find the missing semi-colon, I've tended toward including the little shits. > var r=[]; for (var i in ary) r.push(ary[i]*2) > > I also don't like the idea of using some tool for formatting code. For > instance, the above code would be indented in Netbeans, probably as: I think Michael was referring to JSLint (http://jslint.com/) ... it's not a formatting tool, it's a _correctness_ tool, based on c++ lint, from back in the day. > > var r=[]; > for (var i in ary) { > r.push(ary[i]*2); > } > > Some people may argument that this is much cleaner/better than it was. I > don't think so. Why? Because I think that some simple idea should read as a > single statement. 4 lines for doing that little job is too much for me. The > problem is that some scripts may have thousands of lines. If you waste space > like the code above, it becomes difficult to read other's code and get the > idea without having to scroll lots of pages to finish reading some function, > for instance. I would argue that if you want to read this as a single statement, you should abstract it into a function. For me, the overhead of parsing out the single statement far exceeds the convenience of having it on a single line. > Another common code writing mistake I see on people's code: > > function x() { > if (! exception_condition) { > // several lines of code > } > } > > This is much better written as: > > function x() { > if (exception_condition) return; > // same lines of code without unnecessary nested statements > } Nice tip. > About defining all variables at the beggining of some function is not a > great thing at my opinion. It is much better to have a fluid source code > where you are only concerned about some variable when you are reading the > related code. Also, I always avoid declaring variables unnecessarily. That > is because there is no standard way for giving it a scope. For instance, > when you are reading code like this: > > function x() { > var x = ... // something meaninful > // we are using the value of x here > // ... > // here follow several other lines where x is no more relevant > // how can the reader know that? He will be worried what else can be > affected if he refactors the above x related code. > } > I see assigning variables up top as something similar in concept to attr_accessor in Ruby. ... I think if you keep functions short, than the issue of relevance shouldn't really creep in. > There are several situations where variable declarations are unnecessary. > For instance, using jQuery: > > var el = $('<div/>') > var body = $('body') > body.append(el) > > This could be written using no variable as: > > $('<div/>').appendTo('body') I think this is just an example of a smart refactoring. > Or even as: > > $('<div/>').text('content').appendTo('body').click(function(){alert('clicked: > ' + $(this).text())}) > > or > > $('<div>content</div>').click(function(){alert('clicked: ' + > $(this).text())}).appendTo('body') > > I usually use this approach whenever possible. I think it is much clear for > other developers trying to understand what the code does. When there is some > declared variable, you have no idea when and what it will be used for. > > Also, I don't like to see 80 characters only page delimiter because most > screens nowaday are wide and have small height. This mean we should avoid > several lines of code in favor of lengthy lines. What I mean is that there > was some reasoning for using 80 characters delimiter in the past that is no > more valid nowadays. It is much better to get as much code as possible > without the need of scrolling, unless the code readability is affected, > which I don't think is the case in the above examples. Here is where I disagree with you most. I don't think the 80 character limit has anything to do with screen resolution. Maybe it's because I don't really mind scrolling, but I'd much rather scroll down than across, and I'd much rather read a number of short statements down, than a long statement sideways. I'm a huge fan of the jQuery style of chaining functions on new lines: $('<div/>').text('content') .appendTo('body') .click(...) > I don't see any problems either with the ++ and -- operators, but of course > someone should understand how they work. And Javascript should be tested as > well, the language is not an exception. There are good frameworks for that, > as Selenium, for instance. So, why avoid the great features of the language? > These operators works exactly the same way as C, C++ and Java... Javascript has some great unit testing frameworks too. > Well, actually I was wondering writing some post about this topic on my > site, but ended up never writing about it. Maybe, now that I have already > written part of the content in this email, I can put this on my site :) I > always wanted to write about this for some years now whenever I have to read > other's code in my company :) > > Here I have only given JS examples, but there are other subjects in other > languages as well I would like to cover... > > Sorry for the post-in-email-shape :) Too long for an e-mail, probably, but > please don't blame me. You have inspired me with this subject ;) Very cool discussion to be having. —P > > Thanks for reading until here, :) > > Regards, > > Rodrigo. > > Em 04-07-2010 09:09, [email protected] escreveu: >> >> Hi, >> >> Yes, automatic semi. insertion is a feature - and a most horrible one! >> >> I am unwilling to discuss it though: I must admit I completely and >> uncritically submit to "higher authority" and Javascript-god Douglas >> Crockford as far as code writing rules are concerned, since as far as >> I'm concerned that guys simply is GOOD, or at least so much better >> than ANY other voices I have heard so far (where Javascript is >> concerned). I *highly* recommend the Crockford-videos on Yahoo's >> developer theater for anyone writing Javascript. Okay, "uncritically" >> is not quite right, to me his statements simply make sense. The only >> exception I occasionally take is usage of the ++/-- operators, >> although I limit myself to using them in the head of for-loops only. >> When listening to Crockford one must not forget of course that his >> advice is especially targeted at developers of mashup-able enterprise >> large(r)-scale JS apps where *teams* rather than individuals have to >> work with the code for a long time again and again, and not so much >> for handfuls-of-lines-of-code for "beautifying" HTML pages. >> However, since Rails is a framework IMHO those high and very strict >> coding standards should apply to its JS code. >> >> Yes, I'm willing to contribute and not just complain and I'll try to >> do so - time permitting, which right now is a little scarce (I'm a >> week behind schedule in a JS project and also just opened a restaurant >> in Nuremberg, Germany, with an Italian cook/friend :-) ). >> >> About redeclared variables: >> 1) see function handleMethod, variable field. >> 2) Further down in event handler document.on("submit",...) variable >> "element" is declared twice. >> >> Crockford gives a compelling case for putting all var-statements into >> the TOP of the function instead of declaring them as they are used. I >> forgot was the argument was, but it was very compelling. Crockford is >> strong both in theory (computer science: programming languages) as >> well as in practice. I may sound odd to freely admit I forgot the >> argument and not to care, but I don't care - if you listen to the >> Crockford videos you'll understand :-) Seriously, I'm not nearly as >> good as this guy and since his videos are publicly available why >> should I try to repeat his statements, which is all I can do? >> >> Thanks for the github pointers to the prototype and jquery components, >> I wasn't aware of them but only of the code bundled with rails >> directly. Contributing to the Guides is on my TODO list... I wasn't so >> much calling for other people's action but was/am much more interested >> in finding background info - such as those github links. One usually >> assumes much more intention than there is when one doesn't know all >> the things that are NOT going on ;-) >> >> Michael >> >> >> >> On Jul 2, 1:31 pm, Rodrigo Rosenfeld Rosas<[email protected]> wrote: >> >>> >>> Michael, please take a look at ECMAScript specification, section 7.9 - >>> "Automatic Semicolon Insertion": >>> >>> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262... >>> >>> This is not an error but a feature. The only case where this could lead >>> to some problem is code like this: >>> >>> var l = variable.length >>> (function(){alert('a')})() >>> >>> In this case, if we miss the semicolon, this would be interpreted as: >>> >>> var l = variable.length(function(){alert('a')})() >>> >>> You get the point. But this is only to mention that it is ok to not put >>> the semicolons at the end of the line. I barely put them when writing >>> Javascript... >>> >>> About repeated variable names, I didn't find any case. Could you point >>> me one? Remember that you can define the same variable multiple times in >>> different scopes, such as functions. This is no problem. >>> >>> But I'll take the chance to discuss another issue I've just opened >>> yesterday on Github: >>> >>> http://github.com/rails/jquery-ujs/issues#issue/11 >>> >>> It would be great if the jQuery driver supported including the CSRF >>> token in all AJAX post calls, such as "$.load(url, {data: sample})". >>> >>> What do you think? >>> >>> Rodrigo. >>> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- Paul Campbell [email protected] - - - - - - - - - - - - - - - - - - - web http://hypertiny.ie blog http://www.pabcas.com twitter http://www.twitter.com/paulca github http://www.github.com/paulca phone +353 87 914 8162 - - - - - - - - - - - - - - - - - - - -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
