Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Garrett Smith on 29 Dec 2009 18:56 Dmitry A. Soshnikov wrote: > On Dec 29, 9:48 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > [snip] > >> - DO not use delete operator with host object (IE Errors) > > Again, too categorical. If you know what you are doing, it can be > useful to use `delete'. Better to write "Be carefull using delete > operator with host objects because... (IE Errors)". I suppose the same is true for `in` operator, to a lesser extent. That can fail in a few cases. "ownerDocument" in document; // false in BB9k its there. "9999" in document.styleSheets; // true in IE. Which Host object in IE does delete work on? I know it fails with window, but have not tried with other objects. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 29 Dec 2009 20:04 Dmitry A. Soshnikov wrote: > On Dec 28, 9:25 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Dmitry A. Soshnikov wrote: >>> 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. >> [...] >> >> What I have as draft includes most of what I wrote in the last message. >> The advice to create a top-level function advise creating a method as a >> member of the global object, having the same problems. >> >> Instead, a separate interface should be created. The interface should be >> clearly defined, cohesive, and unlikely to conflict with other objects >> that use the system. >> > > Formally, there's no full protected "interface" from this point of > view. Will you name it `MyVeryOwnNamespace', and tomorrow, the same > name will be in all `libraries' and in ES itself. So, naming > collisions should not be treated as the main reason. > >> >>>>> 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. >> You can do that, but it doesn't fit what I think of as OOP. It is an >> abstraction using inheritance, but it lacks encapsulation and modularity. >> > > What exactly do you mean? Please explain. > Modifying the public interface of String changes Strings to be something different. Any code that uses String now has that change. Creating a separate file for string utils does not impose a global change dependency. Putting the captilize function in a separate separates the concern so that only as many modules as necessary depend on that module. This minimizes dependencies, which makes code change possible. The less dependency you have, the easier it is to change. There is no room for confusion in the intended interface with other modules. Modifying built-ins prototypes maximizes the dependency. Everything has String.prototype, right? Well, now if you modify that, then everything has that modification. Instead, the code should be doing the opposite; instead of maximizing scope, it should be minimizing scope. That way, when somebody wants to change it, he can. And (bonus) if he did a good job at minimizing dependency, it's easy (and he doesen't have to retest the entire system). >> It is more like a reverse-inheritance type of scheme that changes String >> in a way that may or may not be forwards-compatible. Object.create, for >> a coincidental example, is now a built-in method, but exists as a >> user-defined method in some codebases. >> >>>> 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 ;) >> Util is not a descriptive package name. >> >> Not for Java, and not for Ext.js. >> >> Take a look at java.util and please tell me Date have to do with Arrays >> or TimerTask? Nothing, right? >> >> Well javascript borrowed from Java, too. We've got the poor Date class >> and Math. Many of the Math properties could have been moved to Number >> and/or Number.prototype, depending on the property. Math.floor could be >> Number.prototype.floor(), We could have 3.45.round() instead of >> Math.round(3.45). Number.PI, Number.max(10, 11, 12). Well that is all >> fiction made up but for me it makes way more sense than having a >> separated Math class. >> > > Yeah, it could easily be `3.45.round()' instead of `Math' I agree. > >> It seems worth considering changing that to Ext.string, and adding the >> capitalize method to it. >> >> Ext.string.capitalize("foo"); >> >> Collisions to that would be deliberate and you would know right off what >> the capitalize method is, where it is defined, and not have to worry who >> buggered String.prototype or if the buggering was a dual- action effort >> on part of multiple third party libraries. >> > > But there's no difference, will somebody put `capitalize' into the > `String.prototype' or will define own `Ext' or `Ext.string' namespace > - tomorrow, it can easily appear in all other libraries and in ES > itself. So, don't use name collision as a reason. > > Moreover, I tell, people which use libraries think vice versa - they > think: "we don't not modify String.prototype as we're using 3rd-party > frameword, which can put tomorrow (in the next version) `capitalize' > method into it. So let's make our own namespace such as > OutSuperDuperNamespace.string and put `capitalize' there." And > tomorrow, OMG, that framework provides the same > `OutSuperDuperNamespace' and even `OutSuperDuperNamespace.string' > breaking down all the project. So, that's not the reason. > First off, who creates a namespace like "OutSuperDuperNamespace". Then, of those people, who then goes on to include *another* library that also the same (fruity) namespace? A sensible developer would organize the coe into modules. Obviously "DOM" (in any case) would be likely to conflict on global level. I use, for example, APE.dom. And that way, there is no need to worr about a getPosition or getCoords, or getStyle function. I have the DOM module, which is all about the dom, then within that there are modules for style, position, events, and each aspect is organized so that it is pretty narrow, small and easy to test. That is modularity. >> The capitalize method would not localize consistently, as noted recently >> on ES-Discuss[1]. If the string is translated and included literally, >> this doesn't occur. >> > > I understand, but that's completely another question, and doesn't > touch the discussing topic. > >> In ES5, a property can be defined has having [[Writable]] = false. >> >> This can happen in Object.create, with Object.defineProperty, setting >> writable: false. >> >> Object.freeze seals an object and makes its properties unmodifiable by >> setting [[Writable]] to false. >> >> Creating a sealed object eliminates the possibility for conflicts with >> another Ext.string.capitalize. >> > > Yep, thanks, I've also read ES-5 spec already. So, you're moving to > the way I told - better to suggest to use some static language in such > case, but not the language with dynamic mutable objects and statement > as a rule: "Do not touch your own objects". > "Do not touch your own objects" sounds like the exact opposite of what I meant. > So, if you'll write something like: "Remember that augmenting built- > ins may cause naming conflicts, bla-bla... but the same can be with > any other name in the program - no matter where it's - in global or in > own namespace" - that's will be normal. It will sound like suggesting > from your own opinion. > It's more than conflicts. Conflicts cause errors, but rigid APIs with a lot of interdependency make change hard. > But if you'll write - "Augmenting built-ins - is a bad practice" - > that will be categorical and wrong, and I can statement, that person > which spread that not completely understand the goal of dynamic > languages (I do not mean exactly you, I'm telling abstractly now). I'm not completely sure what that means. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: kangax on 29 Dec 2009 22:34 On 12/25/09 6:32 PM, Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: [...] >>> A suitable alternative may be to omit the closing TD tag altogether >>> (valid in HTML 4.01 and draft HTML 5). > > Wrong. It is Valid in HTML 4.01 Transitional only. As for the "HTML 5" ^^^^^^^^^^^^^^^^^ Are you sure about that? <http://www.w3.org/TR/REC-html40/sgml/dtd.html> [...] -- kangax
From: Dmitry A. Soshnikov on 30 Dec 2009 03:59 On Dec 30, 4:04 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > > On Dec 28, 9:25 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> Dmitry A. Soshnikov wrote: > >>> 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. > >> [...] > > >> What I have as draft includes most of what I wrote in the last message.. > >> The advice to create a top-level function advise creating a method as a > >> member of the global object, having the same problems. > > >> Instead, a separate interface should be created. The interface should be > >> clearly defined, cohesive, and unlikely to conflict with other objects > >> that use the system. > > > Formally, there's no full protected "interface" from this point of > > view. Will you name it `MyVeryOwnNamespace', and tomorrow, the same > > name will be in all `libraries' and in ES itself. So, naming > > collisions should not be treated as the main reason. > > >>>>> 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. > >> You can do that, but it doesn't fit what I think of as OOP. It is an > >> abstraction using inheritance, but it lacks encapsulation and modularity. > > > What exactly do you mean? Please explain. > > Modifying the public interface of String changes Strings to be something > different. Any code that uses String now has that change. > Nope, it hasn't. Sorry, bug that's just a demagogy. The code will have that changes when it will *use* that changes. And please, show me, how many changes you'll need to do for modifying method name from e.g. `capitalize' to `capitalizeMethod', if that method uses in e.g. 10 files and doesn't matter where it is described - in `String.prototype.capitalize' or in `VeryOwnStringNamespace.capitalize' How many? Please count and tell me. So, please, do not use demagogy as the logical arguments. > Creating a separate file for string utils does not impose a global > change dependency. > Does. Absolutely the same. Take the example above - please count the changes you need - in *real* dependency - when some code *uses* that name: 'string'.capitalize() or VeryOwnStringNamespace.capitalize ('string'). > Putting the captilize function in a separate separates the concern so > that only as many modules as necessary depend on that module. > Nope, how can't you see - that the dependency is equal in case you're describing. > This minimizes dependencies, which makes code change possible. The less > dependency you have, the easier it is to change. > It doesn't minimizes as dependency is equal. But, yep it's true that "The less dependency you have, the easier it is to change" - but it doesn't related to the case. > Modifying built-ins prototypes maximizes the dependency. I've already described my meaning why augmenting of built-ins could be the issue - only if: (a) augmenting Object.ptototype till we haven't control of {DontEnum}/ [[Enumerable]]. This point goes without saying. But when we'll have control of [[Enumerable]], I thinks it could be very useful. (b) Using 3rd-party libs. But from this point of view - there's no difference, where to describe your objects. (c) If some, using some augmented built-ins, will have a habit to use 'string'.capitalize(), he can be confused not founding this method in other project. But again - there's no difference which habit he has: 'string'.capitalize() or VeryOwnStringNamespace.capitalize() - there will be no such method in other project. Or, maybe just psychological difference - in case of 'string'.capitalize() user can think that it's really own method - but, that's problem of the user - he first should learn language on which he writes. So - the dependency is equal. > Everything has > String.prototype, right? Absolutely right. > Well, now if you modify that, then everything > has that modification. > Of cause not. "Everything" will have that modification when that "everything" will *use* that modification. And there's no difference between 'string'.capitalize() vs. VeryOwnStringNamespace.capitalize() - dependency is equal. > > > Moreover, I tell, people which use libraries think vice versa - they > > think: "we don't not modify String.prototype as we're using 3rd-party > > frameword, which can put tomorrow (in the next version) `capitalize' > > method into it. So let's make our own namespace such as > > OutSuperDuperNamespace.string and put `capitalize' there." And > > tomorrow, OMG, that framework provides the same > > `OutSuperDuperNamespace' and even `OutSuperDuperNamespace.string' > > breaking down all the project. So, that's not the reason. > > First off, who creates a namespace like "OutSuperDuperNamespace". Then, > of those people, who then goes on to include *another* library that also > the same (fruity) namespace? > The main idea (and understand that) is to show that you don't exactly know what will some library provide "tomorrow". So your own "APE.dom" may be overridden by all of that libs you'll use. > A sensible developer would organize the coe into modules. I know what modules are, be sure. `String.prototype' - is the kind of a module itself. And if you are sure what you are doing, it's absolutely not a bad practice to put `capitalize' into it. > Obviously > "DOM" (in any case) would be likely to conflict on global level. I use, > for example, APE.dom. > That's good, but you understand that if you'll using dozen of 3rd- party libs combined, your "APE.dom" theoretically can just gone in one moment - when all the libs will provide the same names and structure. Do you see the difference in this case from augmenting built-ins for own goals (when you know and understand what are you doing)? > And that way, there is no need to worr about a getPosition or getCoords, > or getStyle function. I have the DOM module, which is all about the dom, > then within that there are modules for style, position, events, and each > aspect is organized so that it is pretty narrow, small and easy to test. > > That is modularity. > I know what modularity is. Why do you mention this? Do I say something against modules? Or do I suggest do not use modules? But keep in mind, that `String.prototype' - is the kind of a module itself. > > > But if you'll write - "Augmenting built-ins - is a bad practice" - > > that will be categorical and wrong, and I can statement, that person > > which spread that not completely understand the goal of dynamic > > languages (I do not mean exactly you, I'm telling abstractly now). > > I'm not completely sure what that means. > That just means - that ideologically it's normal to augment built-ins if language is constructed so and if this fact is in it's ideology. So, I don't propagate everyone to augment built-ins (I think you think so about my position, so I'm telling you - nope). My position is to be fair for augmenting built-ins (which means, it against the categorical statement "Augmenting built-ins - is a bad practice"). To augment or not in this case - everyone choose - understanding all the issues. /ds
From: John G Harris on 30 Dec 2009 11:22
On Wed, 23 Dec 2009 at 19:39:41, in comp.lang.javascript, Dr J R Stockton wrote: >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. Anyone who has set up their tab stops to view tables are not going to be happy setting up 30 or so tabs to view a bit of javascript. Tabs are convenient for writers but a nuisance for readers. Two spaces are necessary and sufficient for the indent interval. We are assuming, of course, that sensible people use a fixed-pitch font. Anyone who uses a variable-pitch font deserves to be confused. >The primary objection is not to tabs as such, but to an over-wide indent >unit however produced. <snip> Very true. John -- John Harris |