Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: David Mark on 26 Dec 2009 18:24 On Dec 25, 6:19 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > On Dec 22, 10:38 pm, RobG <rg...(a)iinet.net.au> wrote: > >> On Dec 22, 9:52 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> > * Not escaping ETAGO. > > For better understanding, the exact term "ETAGO delimiter" should be used.. > > >> > Replace: "</" + "script>" > >> > with: "<\/script>"; > >> > Replace: "</td>"; > >> > with: "<\/td>"; > > >> I don't understand the issue here, is it specifically with the TD end > >> tag? Or is it more generally with end tags in HTML sent as an XHR > >> response? > > > No, it refers to markup in script (e.g. document.write calls). > > ACK > > > Nothing to do with the tag type. > > The *what*? I thought this was comp.lang.javascript, not > alt.scriptkiddie.misc. The type of tag serialized in the string (e.g. TD vs. SCRIPT). Are you proposing to refer to these as *elements*? I think not as we are talking about just one (ending) tag (not both).
From: Dr J R Stockton on 26 Dec 2009 17:14 In comp.lang.javascript message <7895e8b5-1f6f-4a3c-9e09-11d5379a3973(a)n1 3g2000vbe.googlegroups.com>, Thu, 24 Dec 2009 16:08:38, David Mark <dmark.cinsoft(a)gmail.com> posted: >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: >> > * 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. "A implies B" does not imply "not A implies not B", although the converse seems to be taught in American schools. If the "main results" of a function are obtained other than through the returned value of the function, then one can still return false if it fails, but one should then return true if it succeeds. But clearly I had in mind a function which returns its main results. >> >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 A pointless remark. >> >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. Utter nonsense. If the calculation and display take less than about 100 ms from user initiation, there is no benefit in speeding them up. FF 3.0.15, XPsp3, P43GHz, <URL:http://www.merlyn.demon.co.uk/js-misc0.HTM#MLS> : 100,000 sequential concatenations of a 9-character string, by Turtle, takes under 0.06 seconds. That, for a member of the intended FAQ readership, is rarely of any importance. >> 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). Perhaps you should test that assertion. Possibly you are an aged person, raised on JavaScript in early browsers running on 486/33 CPUs or similar, when code ran a hundred or more times slower than it does today. Nevertheless, the real point which you show no signs of having grasped is that, for most of the work of those who the FAQ is intended to help the difference between the various methods will be at most a few milliseconds, which DOES NOT MATTER. If a string is short enough to be displayed of an ordinary Web page of reasonable size, then any method of joining its natural parts will be fast enough. >> 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. Your problem. >> 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. :) Your problem. It is repeating code where it can reasonably be avoided. Examples : Don't repeat getElementById on the same element unnecessarily; save the reference in a temporary variable, for readability. Don't multiply repeat, with different variables, such as M D h m s, if (M<10) M = "0" + M but use a function such as function LZ(n) { return (n!=null&&n<10&&n>=0?"0":"") + n } or function LZ(n) { return (n<10?"0":"") + n } -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links; Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc. No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
From: Garrett Smith on 26 Dec 2009 18:50 Eric Bednarz wrote: > Garrett Smith <dhtmlkitchen(a)gmail.com> writes: > >> * Use valid html. > > If that really was a valid requirement for web authoring, it wouldn't be > joined by deep confusion about very basic and simple issues in almost > all cases. > >> * Use standards mode, with DOCTYPE first (no comment, xml prolog). > > Well, that didn't take long. The document type declaration *is part of > the prolog*, in both XML and SGML productions. Maybe so, but for HTML, no comments and no prolog will trigger quirks mode in IE. They should both be avoided for this reason. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 26 Dec 2009 18:57 Garrett Smith wrote: > Eric Bednarz wrote: >> Garrett Smith <dhtmlkitchen(a)gmail.com> writes: [...] >> Well, that didn't take long. The document type declaration *is part of >> the prolog*, in both XML and SGML productions. > Maybe so, but for HTML, no comments and no prolog will trigger quirks > mode in IE. They should both be avoided for this reason. Correction: "comments and/or prolog will trigger quirks mode in IE." -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Asen Bozhilov on 27 Dec 2009 06:38
Dmitry A. Soshnikov wrote: > If you still wanna to write this as a rule, please mentioned, that > it's not the rule, but *just your own suggestion and own meaning*, > meanwhile other people can choose different (good) way augmenting > object and write in OOP-style such as `string.capitalize()' instead of > long ugly `Ext.util.Format.capitalize(string)'. Especially in own > project. You are absolutely right, but augmentation Object.prototype can be harmful and confused. If implementations use native object produced via `new Object()` as a VO and internal [[Prototype]] refer Object.prototype, any augmentation of `object' referred from Object.prototype can be harmful and confused. See below: Object.prototype.x = 10; var x = null; (function() { window.alert(x); }()); Expected value of `x` is `null`, but if VO is implement as a native object value of `x` will be 10. Because: | 10.1.4 Scope Chain and Identifier Resolution | 1. Get the next object in the scope chain. | If there isn't one, go to step 5. In that case next object is VO/AO associated with EC created from anonymous function. | 2. Call the [[HasProperty]] method of Result(1), | passing the Identifier as the property. [[HasProperty]] lookup in prototype chain and will be return `true` in that case. | 3. If Result(2) is true, return a value of type Reference | whose base object is Result(1) and whose property name | is the Identifier. {base : VO, propertyName : x}; So in my case *expected* value is primitive number value 10. See and next example in Firefox 3.5: Object.prototype.x = 10; (function() { window.alert(x); //10 expected ReferenceError }()); window.alert(this instanceof Object); //false window.alert(this.__proto__ === Object.prototype); //false How it is implement Global Object in Firefox 3.5? We can see Global Object does not refer from internal [[Prototype]] object referred from Object.prototype. And we can see that `object' doesn't inherit in explicit way from Object.prototype. The question is, how it is implement that object? Regards. |