Share Posted February 8, 2013 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 Link to comment Share on other sites More sharing options...
Share Posted February 9, 2013 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? 2 Link to comment Share on other sites More sharing options...
Author Share Posted February 9, 2013 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 Link to comment Share on other sites More sharing options...
Share Posted February 10, 2013 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. 2 Link to comment Share on other sites More sharing options...
Share Posted June 30, 2014 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now