Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Dmitry A. Soshnikov on 23 Dec 2009 05:03 On Dec 23, 2:19 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [snip] > > Yes, Dmitry is correct, you're both right. I wasn't explicit enough, or > used terminology that was open to interpretation. > > Changed to: > * Use of == where strict equality is required > Where strict equality is required, the strict equality operator must be > used. The strict equality operator should always be used to compare > identity. > The previous description (with ===) was quite understandable too, and goes without saying, I meant not that. I mean that there's no any reason to use === with `typeof' operator. So you can easily always use: if (typeof blaBla == 'undefined') { ... } 'cause, repeat, algorithms are equivalent in this case as `typeof' always returns value of string type. /ds
From: Dr J R Stockton on 23 Dec 2009 14:39 In comp.lang.javascript message <+KuB1xEneKMLFwQf(a)J.A830F0FF37FB96852AD0 8924D9443D28E23ED5CD>, Tue, 22 Dec 2009 11:04:07, John G Harris <john(a)nospam.demon.co.uk> posted: >On Mon, 21 Dec 2009 at 15:52:55, in comp.lang.javascript, Garrett Smith >wrote: > > <snip> >>Formatting: >> * Tabs used instead of spaces. > >Spaces are preferred, I hope. Some like larger indents. And a good viewing system can be set to make a tab equivalent to two or three spaces. On the Web, however, tabs will normally be worth up to 8 spaces, and should not be used as the indent unit since most readers will find that too big. AFAICS, however, tabs are fine for comment and in code strings and in simple tables. The primary objection is not to tabs as such, but to an over-wide indent unit however produced. AFAIK, in browser output, it is safe to assume tab stops at 8n+1; it may not be so if the output goes, or is taken, elsewhere. It should not be at all difficult to write script that will take tabbed textarea content and replace tabs by appropriate spaces, including tab stops at 2n+1 in leading whitespace, otherwise 8n+1. That should slim the broader authors reasonably well. The FAQ site could, on another page, offer such routines. On long lines : while it is nice if everything fits in 72 characters, that is not of prime importance. What matters is that the sending agent must not machine-wrap lines of code (as it rightly will for text). A well-designed receiving agent (such as yours) should not impose a fixed right margin, and material that really needs longer lines should be sent with those longer lines. Desperate readers with primitive newsreaders should always be able to save the article and read it a la Notepad. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links; <URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ; <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
From: Dr J R Stockton on 23 Dec 2009 15:33 In comp.lang.javascript message <hgp1oo$vee$1(a)news.eternal- september.org>, Mon, 21 Dec 2009 15:52:55, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >Rich Internet Application Development Code Guildelines (Draft) Remember the spelling/grammar checker. > * non-localized strings You should mean non-internationalised strings, since that is a list of bad things. Generally, one does better to list the good things. > * inconsistent return types >Methods should return one type; returning null instead of an Object >may be a fair consideration. Where successful operation of a routine cannot return anything resembling false, ISTM reasonable and useful to return something resembling false if the routine has failed to do what was wanted. >Strategies: > * Modifying built-in or Host object in ways that are either error >prone or confusing (LOD). Include : using without explanation jargon or any other than well-known acronyms & abbreviations >Strings: > * use of concatenation to repeatedly (repeatedly create and >discard temporary strings) >Instead use String.prototype.concat(a, b, c) or htmlBuf.push(a, b, c); Remember that the chief use of JavaScript by the untended FAQ readership is to produce smallish pieces of code without much looping, running in a Web browser as a result of a user action. There is no point at all in telling a general FAQ reader that the less machine-efficient methods are wrong, if they work perfectly well and the code will complete within 100 ms. Writing the fastest code in a nice intellectual exercise for consenting participants, but it should not be imposed overall. The best code is easily-maintainable code, which generally means using a form of code which will be readily understandable to the author in three months time. >RegularExpressions > Be simple, but do not match the wrong thing. Generally - test not only that it works when it should, but also that it does not work when it should not. Include - don't repeat code where it can reasonably be avoided. Use temporary variables, or functions or methods, for this. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7) Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
From: Dr J R Stockton on 24 Dec 2009 16:42 In comp.lang.javascript message <hgsftu$dnu$1(a)news.eternal- september.org>, Tue, 22 Dec 2009 23:12:58, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: {with RegExps] >Trying to match leap years would be excessively complex. >Instead, the date validation can be addressed where the expression is used. Well, in the context I agree. But, for the festive season, the following code alerts 7777 only (that was added to show that the loop runs); the middle line does with a reasonably simple RegExp tell whether Y is leap. for (Y=0 ; Y<11111 ; Y++) if ( /([^5AF]0|[48CG])$/i.test((Y+400).toString(20)) != !!(2-new Date(Y+400, 1, 29).getMonth() ) || Y == 7777 ) alert(Y) The first 400 saves worrying about 1-digit years; the second compensates and saves worrying about years before 100. Tested only in FF 3.0.15. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05. Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: David Mark on 24 Dec 2009 19:08
On Dec 23, 3:33 pm, Dr J R Stockton <reply0...(a)merlyn.demon.co.uk> wrote: > In comp.lang.javascript message <hgp1oo$ve...(a)news.eternal- > september.org>, Mon, 21 Dec 2009 15:52:55, Garrett Smith > <dhtmlkitc...(a)gmail.com> posted: > > >Rich Internet Application Development Code Guildelines (Draft) > > Remember the spelling/grammar checker. > > > * non-localized strings > > You should mean non-internationalised strings, since that is a list of > bad things. > > Generally, one does better to list the good things. > > > * inconsistent return types > >Methods should return one type; returning null instead of an Object > >may be a fair consideration. > > Where successful operation of a routine cannot return anything > resembling false, ISTM reasonable and useful to return something > resembling false if the routine has failed to do what was wanted. > That's an over-generalization. Functions that return nothing result in the undefined value. That shouldn't mean they failed. It really depends on the function, but there is no general reason to return a "truthy" value. > >Strategies: > > * Modifying built-in or Host object in ways that are either error > >prone or confusing (LOD). > > Include : using without explanation jargon or any other than well-known > acronyms & abbreviations typeof x == 'unknown'; // ActiveX (is that okay?) (x); // Boom > > >Strings: > > * use of concatenation to repeatedly (repeatedly create and > >discard temporary strings) > >Instead use String.prototype.concat(a, b, c) or htmlBuf.push(a, b, c); > > Remember that the chief use of JavaScript by the untended FAQ readership > is to produce smallish pieces of code without much looping, running in a > Web browser as a result of a user action. "...as a result of a user action" is the operative phrase. Such results _need_ to be as fast as possible. If you've ever typed into an "autocomplete" widget, you know what I'm talking about. > There is no point at all in > telling a general FAQ reader that the less machine-efficient methods are > wrong, if they work perfectly well and the code will complete within 100 > ms. Huh? Repetitive string concatenation is a performance killer (particularly in IE). > > Writing the fastest code in a nice intellectual exercise for consenting > participants, but it should not be imposed overall. I don't see what that has to do with excessive concatenation. > The best code is > easily-maintainable code, which generally means using a form of code > which will be readily understandable to the author in three months time. Pushing strings to an array and then joining (instead of concatenating) is not going throw anyone (at least not anyone who should be programming JS). > > >RegularExpressions > > Be simple, but do not match the wrong thing. > > Generally - test not only that it works when it should, but also that it > does not work when it should not. Seems sensible. > > Include - don't repeat code where it can reasonably be avoided. Good. > Use > temporary variables, or functions or methods, for this. Temporary variables? And it's not exactly clear what "this" is. :) |