Validation Error using eclipse and Jslint

[Ctmanic]

Hi, Love Greensock, been using it for years in AS.

 

I am using the JS lib now and it's fantastic as well. I am working for a company that is looking to future proof all their code, and they have a massive framework. Loads of animations in javascript.

 

The issue is that when using Eclipse and Jslint for error checking the JS, there is a handful of errors that show up realting to Tweenmax.min.js. And they will not use any library that has any errors showing up. (Future proofing).

 

So, could someone look into these errors? I would love to be able to use Greensock on this project.

 

 

Error: '_gsDefine' was used before it was defined.    in    TweenMax.min.js    line 15   

 

Error: Expected ';' and instead saw ','.    in   TweenMax.min.js    line 15

 

Error: Expected a conditional expression and instead saw an assignment.    in   TweenMax.min.js    line 15

 

Error: Expected an identifier and instead saw ','.    in    TweenMax.min.js    line 15

 

Error: Stopping.  (84% scanned).    in   TweenMax.min.js    line 15

 

Syntax error on token ",", ~ expected after this token    in    TweenMax.min.js    line 16

Syntax error on token "}", ; expected    in    TweenMax.min.js    line 16

Syntax error on token "}", ; expected    in    TweenMax.min.js    line 16

Syntax error on token "break", ; expected after this token   in    TweenMax.min.js    line 15

Syntax error on token "break", ; expected after this token    in    TweenMax.min.js    line 17

Syntax error on token(s), misplaced construct(s)    in    TweenMax.min.js    line 16

Syntax error, insert "Arguments" to complete MemberExpression   in   TweenMax.min.js    line 17   

 

 

Cheers,

-c

 

 

 

[GreenSock]

I totally understand why you'd want to have things validate through something like JSLint, but keep in mind that tools like that just look at common mistakes but not necessarily invalid code. There are a LOT of speed optimizations in the engine and JSLint complains about some of them even though there completely valid. For example:

 

//slower, but valid in JSLint:
if (condition1 && condition2 && condition3) {

}

//faster, but JSLint complains:
if (condition1) if (condition2) if (condition3) {

}
 

Another example is this:

 

//check a condition and then assign and check that the value is not null or 0:
if (condition1 && (myVariable = someOtherValue)) {

}
 

JSLint will complain about the assignment in there because it assumes I meant to type == or === instead of = but that isn't true. Sure, it's a common mistake people make (forgetting a =) but in this case it's absolutely intentional because I don't want to waste CPU cycles assigning the variable or checking its validity if the first condition isn't true.

 

So we have a choice to make: either we prioritize JSLint compliance and write slower code or we prioritize raw performance and tight file size and let JSLint complain. In a tweening engine, maximum performance is absolutely essential, so I definitely think it's better not to write slower code just so JSLint doesn't complain, especially because the code is perfectly valid. See what I mean? 

 

The errors you mentioned are virtually impossible to decipher because they're on the minified file - can you provide details about the uncompressed (non-minified) version of the file(s)? That way, the line numbers make much more sense and we don't have to worry about "errors" that the minifier introduced. I know for sure that the minification process spits out code that JSLint doesn't like (but again, it's perfectly valid).

 

Again, I totally understand why your boss would be pushing for zero JSLint complaints in the code. Let's just walk through the complaints and assess if they're truly errors or not and keep our focus on performance too. Sound fair? 

[Ctmanic]

Wow! Thank you for the fast and thorough reply. Absolutely sounds fair enough. The reason I sent through the minified version is there were many fewer errors in it according to Jslint. And yes, everything you said makes good sense. I will be sending everything you say here to the engineering team and hopefully they will see the light.

 

So here are all the JSlint "errors" spitting out in the console:

 

 

 

Error: '_changePause' was used before it was defined.    in    TweenMax.js    line 430    id    11340

Error: '_changePause' was used before it was defined.   in    TweenMax.js    line 434    id    11341

Error: '_gsDefine' was used before it was defined.    in    TweenMax.js    line 23    id    11311

Error: '_paramProps' was used before it was defined.    in    TweenMax.js    line 549    id    11345

Error: Don't make functions within a loop.    in    TweenMax.js    line 301    id    11333

Error: Empty block.    in    TweenMax.js    line 672    id    11352

Error: Expected '!==' and instead saw '!='.    in    TweenMax.js    line 63    id    11312

Error: Expected '!==' and instead saw '!='.    in    TweenMax.js    line 375    id    11336

Error: Expected '!==' and instead saw '!='.    in    TweenMax.js    line 608    id    11348

Error: Expected '!==' and instead saw '!='.    in   TweenMax.js    line 757    id    11356

Error: Expected '!==' and instead saw '!='.    in   TweenMax.js    line 777    id    11358

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 125    id    11315

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 155    id    11317

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 159    id    11318

Error: Expected '{' and instead saw 'if'.    in   TweenMax.js    line 206    id    11320

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 206    id    11321

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 217    id    11322

Error: Expected '{' and instead saw 'if'.   in    TweenMax.js    line 220    id    11323

Error: Expected '{' and instead saw 'if'.    in   TweenMax.js    line 220    id    11324

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 220    id    11325

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 234    id    11326

Error: Expected '{' and instead saw 'if'.   in    TweenMax.js    line 237    id    11327

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 237    id    11328

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 237    id    11329

Error: Expected '{' and instead saw 'if'.    in   TweenMax.js    line 240    id    11330

Error: Expected '{' and instead saw 'if'.    in   TweenMax.js    line 247    id    11331

Error: Expected '{' and instead saw 'if'.    in   TweenMax.js    line 704    id    11353

Error: Expected '{' and instead saw 'if'.    in    TweenMax.js    line 704    id    11354

Error: Expected '{' and instead saw 'if'.    in   TweenMax.js    line 704    id    11355

Error: Expected '===' and instead saw '=='.    in    TweenMax.js    line 369    id    11334

Error: Expected '===' and instead saw '=='.    in   TweenMax.js    line 372    id    11335

Error: Expected '===' and instead saw '=='.    in    TweenMax.js    line 392    id    11338

Error: Expected '===' and instead saw '=='.   in    TweenMax.js    line 617    id    11349

Error: Expected '===' and instead saw '=='.    in   TweenMax.js    line 643    id    11350

Error: Expected '===' and instead saw '=='.    in    TweenMax.js    line 648    id    11351

Error: Expected '===' and instead saw '=='.    in    TweenMax.js    line 774    id    11357

Error: Expected '===' and instead saw '=='.   in   TweenMax.js    line 780    id    11359

Error: Expected a conditional expression and instead saw an assignment.   in    TweenMax.js    line 16    id    11310

Error: Expected a conditional expression and instead saw an assignment.   in    TweenMax.js    line 381    id    11337

Error: Expected a conditional expression and instead saw an assignment.    in    TweenMax.js    line 450    id    11342

Error: Expected a conditional expression and instead saw an assignment.    in    TweenMax.js    line 552    id    11346

[GreenSock]

Yep, every single one of those "errors" was intentional and they're not invalid JavaScript. 

 

The "used before it was defined" stuff just has to do with the placement of a few variable declarations - I grouped them in logical order in the code rather than technical order of occurrence. This makes the code more readable and also in some cases it would be impossible (or extremely cumbersome) to declare them in the order JSLint is requesting. However, I'm 100% positive that they'd NEVER be referenced out of order during runtime. 

 

The "don't make functions in a loop" is a general precaution, and I certainly could create a wrapper function that hushes JSLint, but it would bump up file size slightly and it would slow down execution performance because it's an extra function call each time through the loop. 

 

The "empty block" complaint has to do with an important piece of code in the add() method where it is extremely common for that first condition to be true, thus I put it at the top to avoid the other conditions from even being evaluated. It's perfectly valid and it's a performance optimization, but I can wrap it a bit differently that won't slow down execution and it'll only be a few extra characters, so I'll do that in 1.8.3. 

 

The "Expected '!==' and instead saw '!='" are all bogus too - checking != is very useful for knowing if a value is a number of different things, like null or undefined. Or if it's false or 0. 

 

//longer
if (value !== null && value !== undefined) 

//shorter, but same result
if (value != null)

//longer
if (value !== false && value !== 0 && value !== "") 

//shorter, but same result
if (value != false)
 

The same explanation goes for the "expected ===, saw ==" messages.

 

As for "Expected '{' and instead saw 'if'", that's another performance optimization I explained earlier:

 

//slower
if (condition1 && condition2 && condition3) 

//faster
if (condition1) if (condition2) if (condition3) 
 

The "Expected a conditional expression and instead saw an assignment." is the optimization I explained earlier as well where we delay evaluating an assignment and checking that its result isn't null/0 until we MUST. Like:

 

if (condition1 && condition2 && (myVariable = getSomething()) && myVariable != 3) 
 

Notice that the getSomething() function won't run unless the first 2 conditions are met. That can save precious CPU cycles. 

 

Does that clear things up? I can assure you that we're very committed to ensuring that the platform runs well and is error-free. 

 

Remember, JSLint is just trying to provide some rough guidelines to help people avoid writing bad code.

 

I hope that helps. Let us know if you find anything else. 

[LewisOne]

I have to say that the whole using Lint thing can be annoying.  It is amazingly helpful for many common errors and troubleshooting, however, it does not like jQuery, GreenSock, or any other of our tools.  Most of the time I get a ton of LintErrors and it seems to work perfect.

 

Is there another tool to check to see if you are missing stupid things or to proof work to clean it up like lint does???  A tool like this would be helpful.   Right now I use Brackets.io or DreamWeaver but they don't necessarily let you know where the mistake is because most of the time it will give you an error at your last bracket telling you that something is missing where lint tells you which line.  Weird.