Why are namespaces considered bad practice in JavaScript?
I've been told namespaces shouldn't be used, as they 'pollute' the global scope. I wonder what are the alternatives?
When I want to define utility functions and / or constants eg for a website, a simple way to go would be to define them by namespaces, that way the damage to the global scope is restricted to one object only.
If namespaces are bad practice, a couple of questions comes to mind:
This question is a result of a discussion started on a post on the benefits of using extend.js.
why is this bad practice?
namespaces themself are bad because it's an unnecessary concept.
Having objects with properties and methods is acceptable. It's also fine to have a "module" token which is similar to a "namespace" but instead the meaning is that you have one "module" token per file which contains all your properties and methods. This is different from a "namespace" because it's only created / altered in a single file and isn't exposed as a global token.
what's the scope of this declaration (web applications / dynamic websites / static websites etc.)?
All ECMAScript, never create new global tokens
what are the alternatives?
Rather then having namespaces you should favour multiple "file local" tokens. Meaning that each file / "module" should be wrapped in a closure and you should have access to multiple local variables inside this closure.
Global variables are also bad because you don't need them, at all, ever. The way you avoid globals is by wrapping everything in closures and being intelligent in how you load external javascript files.
Examples of zero global module loaders
Further reading:
I can't imagine why a namespace would be a bad thing. Unless there's some definition of namespace that is specific to JavaScript that I'm not aware of.
I'm currently working on a small library, and everything is enclosed by one top-level object (namespace?). I don't put anything on the window or intrinsic types; if you need something from my library, it's available in the kilo object.
To me, having this 'namespace' is a good practice as it lets me know very quickly if I'm calling a method in my library. There's no need to override the window.alert method which might screw with another library loaded on the page; just use kilo.alert for the customized version (this is a contrived example, but I hope it makes the point).
Personally I think people who say you should never pollute the global scope fail to properly define "polluting". You can see this to some extent in the native Math object, for example. Every other programming language I know has all the math functions as just plain functions, but JS doesn't. However, if you were to take this to an extreme, a simple alert box would be core.dialog.alert instead, for instance.
I like to enclose all of my code in closures, to keep the variables clean. However, my main JS script file defines a bunch of utility functions in the global scope, such as a custom Alert() , or AJAX() , or other widely-used functions. If I'm going to use them often, I don't want to have to bloat the file with namespace calls. And since I define all my variables in closures there's no risk of accidentally overwriting the functions (I might do so in the closure itself, but it had no impact on the global scope).
Overall, namespaces are overrated. Just write your code already and don't cry over every single window property.
上一篇: 总是“使用命名空间标准”？