Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Thomas 'PointedEars' Lahn on 27 Dec 2009 07:36 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > RobG wrote: >> >> Garrett Smith wrote: >> >> > 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). >> [...] >> > 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*? TD is one *element* type, SCRIPT is another. <http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1> > I think not as we are talking about just one (ending) tag (not both). Iff you had meant "tag type" to distinguish between start tags and *end* tags, which AIUI you have not, then that would have been acceptable. The term would be potentially unclear, though. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: David Mark on 27 Dec 2009 11:48 On Dec 27, 7:36 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > RobG wrote: > >> >> Garrett Smith wrote: > >> >> > 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). > >> [...] > >> > 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*? > > TD is one *element* type, SCRIPT is another. > > <http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1> Are you kidding? > > > I think not as we are talking about just one (ending) tag (not both). > > Iff you had meant "tag type" to distinguish between start tags and *end* > tags, which AIUI you have not, then that would have been acceptable. As you understand what? Was my explanation unclear? > The > term would be potentially unclear, though. I don't think so in this case.
From: Eric Bednarz on 27 Dec 2009 12:03 Garrett Smith <dhtmlkitchen(a)gmail.com> writes: > 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." Read again what I wrote. Without a prolog, you trigger quirks mode. There is no “and/or” involved either, as comment declarations preceding the document instance set are part of the prolog as well. When you write | * Use standards mode, with DOCTYPE first (no comment, xml prolog). you probably mean “no XML declaration”. 'Prolog' is clearly defined by XML 1.0, and it's not what you want it to be. (I can live with the term 'comment' in a practical HTML context, but when pretending that it is useful to validate a HTML document against its document type declaration subset, SGMLese should be used throughout an 'comment declaration' would be correct.)
From: Dmitry A. Soshnikov on 27 Dec 2009 15:13 On Dec 27, 10:45 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [snip] > A public library that modifies > the built-ins can't really be trusted to work with other code. > I understand, and told myself, that's this is the only (again - the only.) reason. And from this point of view, you should mention this just as a warning for authors of libraries, but not as a rule for programming on ECMAScript. Augmenting of built-ins is kind of additional "plug-ins", additional functionality, which is treated as *own* which provides the way to write more clear and elegant code. Just like host environment provides additional objects to complete the program state, your augmenting provides additional functionality. There's no difference from the functional point of view - will you put this code into the prototype of the built-in object, or will define some global (or in your own namespace) function. But from the ideological point of view, difference *is*. And repeat, that dozen of 3rd-party, all of them (all of them!) can provide the same global function `hideElement' and cause the name conflict. So, - only just a suggestion or a warning, but not the rule, 'cause that's ECMAScript, but not a some static language. And for me, it's a good practice to put functionality there where it's place (e.g. `trim' or `capitalize' for strings in the String.prototype). > > > So, again, it's absolutely normal to augmenting objects in ES, > > providing good documentation of what have you augmented (and for whole > > code in general). > > > 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. > > I do not agree that util is a good name for a package. Packages or units > of code should be organized by usage pattern. > > "util" is a kitchen sink. > That's not mine, that's real example from ExtJS library. I mentioned that to show how the code can converts into the overloaded massive long lines using everywhere things such as procedure-like style `Ext.util.Format.capitalize(string)'. Yeah, influence of Java is conclusive in ExtJS library ;) /ds
From: Dr J R Stockton on 27 Dec 2009 16:51
In comp.lang.javascript message <hh63qh$ee8$1(a)news.eternal- september.org>, Sat, 26 Dec 2009 14:47:43, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >Dr J R Stockton wrote: >> 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: >It may be worth considering assigning priority labels to certain things. >For example: "Use valid HTML" an "Use standards mode" would be priority >1 guidelines, while "Use efficient string concatenation techniques" >might be a Priority 2, while Much less than Priority 2, unless you can show a reasonable proportion of common practical cases where optimising concatenation makes a noticeable (not a measurable) difference to the time seen between initiating action and visible results. >>> * 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. >> > >Functions that return multiple type provide more variance to the caller. > >Sometimes this happens on accident, where the function was >intended to return one type, but can return a value of a different type. > >Functions that return only one value type (including undefined) do not >burden the caller with having to check the return type. > >It is something to look for in code where the function may, for example, >return a number in one case and a string in another case. > >Functions that return multiple type have their place. A method might >return an object, but return null if the operation failed. So it is not >a rule, but something to consider when looking the code. One does not need to check the return type if the mutually exclusive return alternatives are to give something which will pass as false and to give something which will not pass as false. Result = FunctionOfAllSortsOfThings(......) if (!Result) { ... /* it failed */ ... ; return } // Code using good Result ... Result = FunctionOfAllSortsOfThings(......) if (Result) { /* Code using good Result */ ; return Answer } // moaning & wailing For an example, see FAQ 4.2 How can I create a Date object from a String? OTOH, my recently-posted Leading Zero function LZ takes care always to return a string (unlike function LZ(N) { return N<10 ? "0" + N : N } ); then Y+LZ(M)+LZ(D) works as well for Oct-Dec as it does for Jan-Sep. Really, the recommendation should be against functions returning unexpected types. >SRP The Single Responsibility Principle > A class should have one, and only one, reason to change. >OCP The Open Closed Principle > You should be able to extend a classes behavior, without modifying it. >LSP The Liskov Substitution Principle > Derived classes must be substitutable for their base classes. >DIP The Dependency Inversion Principle > Depend on abstractions, not on concretions. >ISP The Interface Segregation Principle > Make fine grained interfaces that are client specific. TMA. -- (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) |