0

I often use jslint and tools to verify my code for programming errors, etc...

During the course of my programming I often find that I need a local variable or a local function to do some simple things. So I go to my main single var statement at the top of my local scope and adjust it, sometimes breaking my creative flow. So sometimes instead I declare a single line var in the middle of my code to continue my programming and then move it at the top var statement during refactoring afterwards.

I had an idea today that i want to explore and did not find anything on it on Google or stackoverflow.

My idea is this, just declare a single temp object and use it for whatever the need. Ex: adding some attribute for a new variable or function.

So instead of :

// if I omit the last comma, the next variable will be a global
var variable1 = "Hello World!",  
variable2 = "Testing...";  

(... some code ...)
var variable3 = 42;

I would instead use :

var temp = {};
temp.variable1 = "Hello World!";
temp.variable2 = "Testing...";

(... some code ...)
temp.variable3 = 42;

So I do not risk polluting the global namespace, I declare variable as needed and do not struggle with that var statement since I always know that a variable preceded by "temp." is in the local scope.

Any comment or advice will be appreciated.

Jean-Philippe Martin
  • 861
  • 10
  • 19
  • I dont think there is a real difference, once you keep your scope in mind.. You shouldnt pollute your global namespace once you manage your scope references.. JS is passed around by value as opposed to reference, so I don't see the difference in my head! :( – Pogrindis Jun 12 '15 at 15:15
  • You would be better of [using closures to maintain scope](http://stackoverflow.com/questions/4102659/what-are-the-benefits-of-a-closure-and-when-are-they-typically-used), make your code more readable, prevent pollution of the global scope, etc. – Liam Jun 12 '15 at 15:18
  • Another idea I have is instead of naming my temp object temp I could name it to give an idea of the scope and still know it's a local up the chain. ex: temp_inner, temp_inner_inner. – Jean-Philippe Martin Jun 12 '15 at 15:23
  • Possible duplicate of [I've Heard Global Variables Are Bad, What Alternative Solution Should I Use?](http://stackoverflow.com/questions/2613310/ive-heard-global-variables-are-bad-what-alternative-solution-should-i-use?lq=1) – Liam Jun 12 '15 at 15:27
  • 1
    One issue that jumps out is if this code goes through a minification process. Since these variables are properties of an object they won't be minified. Not necessarily a big deal but it could add a bit of weight if your module/library is a large one. – Jason Cust Jun 12 '15 at 15:57
  • @JasonCust Yeah thought about this... Thanks for pointing this out. ex: Temp.thislongvariablethatidonotwanttoforget will be minified to a.thislongvariablethatidonotwanttoforget – Jean-Philippe Martin Jun 12 '15 at 16:22
  • Dude - use strict, use closures. (Or, use ES6 - modules and the `let` statement.) Declare your variables wherever you want - just be aware of JS hoisting. The "var at the top" is to avoid programmer issues with hoisting;l as long as you're aware of the behavior, you're fine. –  Jun 12 '15 at 19:27
  • Using your tmp global object is shorter than closures generally used for this purpose. It is not necessarily a bad idea, it depends how do you want to use it. – Jan Turoň Jun 12 '15 at 19:49

2 Answers2

1

Ask yourself a question: have you ever seen anyone else doing this? I, personally, haven't. That should give you an indication that there are good reasons not to. Essentially what you're suggesting is "namespacing", isn't new. It is fine in many cases but here - for temporary variables - I'd suggest it highlights a code smell.

You mention pollution of the global namespace but this should rarely be an issue. By breaking your code down into functions, classes or modules, your variables will be enclosed in that scope.

So sometimes instead I declare a single line var in the middle of my code to continue my programming and then move it at the top var statement during refactoring afterwards.

This sounds bad. It sounds like your code blocks are very long, and that is an indication that you should be extracting functions from your code.

I'd also point out that you're also polluting the global namespace with a variable called temp in your example.

Think about common JavaScript codebases; jQuery only has the jQuery or $ variable exposed. Lodash/Underscore only has _. Backbone has "Backbone" and so on. Why is your application special? Just have one exposure point.

Another potential solution to your issue is to use a module system. When compiled, the code will be wrapped in a closure and not exposed to the outside world at all. Making it modular will also result in a tidier application.

Colin Ramsay
  • 16,086
  • 9
  • 52
  • 57
  • 1
    I agree with everything except the first comment ! ^ just because others are not doing it doesnt mean it may not a FANTASTIC idea! ^ – Pogrindis Jun 12 '15 at 15:19
  • Well nobody's doing it does not mean its a bad idea... it's worth exploring I think. – Jean-Philippe Martin Jun 12 '15 at 15:20
  • *You mention pollution of the global namespace but this should rarely be an issue*. [Really?](http://stackoverflow.com/questions/2613310/ive-heard-global-variables-are-bad-what-alternative-solution-should-i-use) – Liam Jun 12 '15 at 15:24
  • 1
    @Liam I think he means you shouldn't be developing into a way to even hit this problem. – Pogrindis Jun 12 '15 at 15:27
  • Well this is basically namespacing, and that's not bad per se; however the description of the code issues and the way it would be used here kind of indicates that it would be an abuse of namespacing. This isn't really a new idea you're just using it in a way I feel is unwise. I rephrased my answer to focus more on namespacing. – Colin Ramsay Jun 12 '15 at 15:37
0

The best way to avoid global scope pollution is to break your code down in small and independent functions and modules.

Your mention having to refactor your code because you have variable declarations in the middle of your code. I personally don't think you need to do that, I actually find code way easier to reason about when variables are declared as close to the place they are used as possible. As long as you are comfortable with the way the scope and hoisting works I don't see a reason why you should put all your declarations at the top of your functions.

Thomas Eschemann
  • 995
  • 7
  • 18
  • Well jshint and the like are a little forgiving on where we should put our var statements but Crockford suggested that a single var should be the best approach. For breaking my code into smaller bits, perfectly agree with that but there is many good reason why sometimes it's not the case : code maintenance, urge to deliver, etc... – Jean-Philippe Martin Jun 12 '15 at 15:35
  • I personally don't like the single var pattern because I feel like it makes refactoring my code harder. With multiple vars I can just cut and past my declarations around whereas with a single var I always have to make sure the commas are right. Sure it may look cleaner but I don't feel like it brings any other benefit than that. – Thomas Eschemann Jun 12 '15 at 15:42
  • "Crockford suggested that a single var should be the best approach" - where exactly did he say that? Do you mean a single var keyword? If so that's totally different to what you are suggesting. Also "code maintenance" is a terrible, terrible reason not to break up your code. You are asking a question about best practise here, remember. – Colin Ramsay Jun 12 '15 at 15:42
  • @ColinRamsay Lol ! Right for code maintenance :-) Ok Creative flow instead :-) – Jean-Philippe Martin Jun 12 '15 at 15:45
  • 1
    Just a note: Crockford's recommendation for a [single var statement](http://javascript.crockford.com/code.html) was originally writen when JS was in the browser only and there was still a concern with heavily optimizing delivery size. Once again, it's only a recommendation and there are plenty of modern style guides that don't recommend the single var statement. A more pertinent reason is to emphasis [variable hoisting](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var) so that newer developers understand explicitly what the engine is doing behind the scenes. – Jason Cust Jun 12 '15 at 15:48