[TIMOB-9368] Code Processor: Implement Accidental Global Variable Declaration Code Processor plugin.
| GitHub Issue | n/a |
|---|---|
| Type | New Feature |
| Priority | Low |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2016-08-24T20:12:36.000+0000 |
| Affected Version/s | Release 3.0.0 |
| Fix Version/s | n/a |
| Components | Code Processor |
| Labels | n/a |
| Reporter | Bryan Hughes |
| Assignee | Chris Barber |
| Created | 2012-06-04T12:32:19.000+0000 |
| Updated | 2017-03-20T17:24:15.000+0000 |
Description
It is easy to accidentally create global variables that can have difficult to diagnose consequences. For example:
var x,
y;
z;
creates a global variable 'z'. This plugin should throw a warning whenever a global variable is created without referencing the global object. In other words, this is a best practice enforcer plugin.
I use strict mode.
Not all browsers support strict mode (I'm looking at you IE), and most devs don't use strict mode (unfortunately).
Yeah, I agree, not all browsers support it. But, IMO, it is valuable development tool no matter that fact (if global variables aren't created in browser that does support strict mode by using strict mode, they won't be accidentally created in the browser that does not support strict mode :) ). In my opinion, documenting usage of strict mode could be useful because it can be used right away (v8 and JSC supports it, so it can be used on Android and iOS also).
I'm definitely not arguing against the use of strict mode...in fact I strongly encourage it. I just think there is room to do a lot more. I feel that whatever we have should a) be caught at compile time not run time, b) be opt-out, and c) always available regardless of runtime. The problem with relying on run-time tools is that the code must be run in order to see the error. If this error is in some seldom used corner case (think unexpected error handling), the error may not be caught for months and will be noticed by some user, not the developer. Moving this error handling to compile time is so much cleaner.
I doubt that you will be able to catch all errors at compile time due to dynamic nature of the language (no offense meant, just reason talking). :) Global variable declaration is just one trivial case. "this" and its potential to create global variables is much more challenging (note that "this" value can be different every time and its value is determined at call-time). There are more cases that are very challenging to cover with static analysis. Because of that, my opinion is that it is better to use existing tools (strict mode, JSLint, JSHint, whatever ... and maybe modify them if they don't fit perfectly to Titanium), than to develop own tools, which can be, very challenging task. I would prefer official testing tools instead. :)
Fortunately for us, I'm not doing static analysis :) I'm doing a partial dynamic analysis, so knowing what the this pointer is won't be a problem. WRT "Because of that, my opinion is that it is better to use existing tools (strict mode, JSLint, JSHint, whatever ... and maybe modify them if they don't fit perfectly to Titanium), than to develop own tools, which can be, very challenging task. I would prefer official testing tools instead." We have already done a careful analysis of these options and rejected them for various reason. Work has already begun on these tools, and have been scheduled into development. The tools will be optional, so if you don't want to use them, then by all means use JSLint or whatever you prefer instead.
OK, thanks. :)
Code processor is dead.
Closing ticket as code processor is no longer supported.