JSLint: How to flag code as being wrong - javascript

I would like to is flag some piece of code to come back to later. The code is seriously violating our design and I want to ensure that I see it every time I run JSHint until I fix it.
Just as an example suppose that to get something else working I change this code:
addTwoNumbers: function(numberOne, numberTwo){
return numberOne+numberTwo;
}
To this:
addTwoNumbers: function(numberOne, numberTwo){
return 11;
}
JSLint has no problems with these changes, but clearly they will cause me some trouble later. What would like to do is something like this:
addTwoNumbers: function(numberOne, numberTwo){
/* jslint fail */
return 11;
}
This way when I run JSLint before committing I will see that I have done something I probably shouldn't.
Alternately, if I am planning on committing the code (bad idea) and coming back to it in a couple weeks, I want to be warned frequently by JSHint.
I know that I can use the "Unexpected TODO comment" but my team (me included) uses TODO very liberally. Another method would be preferred.
More info on: Unexpected TODO comment

this is a coding style and not a language fault, and recently JSHint has taken the decision to not implement coding style options in the linter.
I'm not sure of the state of development, but it may be/become possible to write extensions to JSHint to enforce one's own coding style.
Though, what you're asking is done since programming and editors exist:
addTwoNumbers: function(numberOne, numberTwo){
return 11; // TODO bad implementation, change it!
}
and have your editor highlight the comment in yellow and red, add a /!\ in the line number column, and have it list it along with the warnings of your linter!
But that's not JSHint's job, or even a linter's job to check that kind of things!

I am leaving this here partly as a note to myself and partly for anyone else who has this issue.
If you are using grunt to invoke jslint, you can also use grunt-todo. This allows you to define tags in your project and then it will list the tags on build/grunt. It has some built in tags by default and you can add your own. I think you should even be able to configure your release build to fail if there are specific tags in the code base.

Related

How to catch typos errors in VIM for EmberJS (Javascript)

I am starting to learn EmberJS/JS/VIM . I was going through the official ToDoMVC guide for EmberJS, and I ran into typos errors that was really really hard to detect with the "eyes" and the browser really didn't help in this case at all. So, can you please suggest me what tools or techniques that can be used to detect these types of typos errors?
For example:
### todo_controller should've been todos_controller
<script src="js/todo_controller.js"></script>
### catching the end of { } closed scoping
### typo within a model js "property"
inflection: function() {
var remaining = this.get('remaining');
return remaining === 1 ? 'todo' : 'todos';
}.proprety('remaining')
EDIT;
Yes, I did search before posting here. The first was this website, and the comments here basically suggest DreamWeaver Frustration with Typos.
I searched SO itself (through google), and there was Is there a way to catch typos. I did find out there is something called LINT, but it dealt with coffeescript.
I did find out ember.vim as you pointed out before, but as you see the README in the github profile, i believe it strictly wants you to follow the layout as prescribed. It may be a good thing in future, but right now, I wanted to just stick with what the official ToDoMVC way. I am just beginning to get a hang of hjkl, so I do not think I can makes changes to it to fit my way. Also, second point, is the layout format it supports is Ember-AppKit which has been deprecated. SO I am having doubts if I should follow the layout pattern itself.
And all of them didn't particularly address what I am asking. In the todo_controller typo above, the browser didn't throw any sort of errors. I am using FF/Firebug, and on the Console, it only showed the message about Ember loading, and no errors at all. It took me a while to see that typo. The second one did throw errors, but typos are a hard thing to discover in VIM. The third one, took a bit of time, and there were others. These don't throw errors at all. I am used to PHP, and while there is no direct showing of errors as in Android, I am finding Javascript typo hunting to be very hard.
it took me like 3 looks before I saw your typo.
Set your browser to pause on exceptions (sometimes pause on Caught Exceptions). It's been one of the quickest ways I've found to track down a weird bug. In this case I'm sure you were getting Uncaught TypeError: undefined is not a function....
Don't take this the wrong way, but did you try to search before asking? There has been, for quite a while now, a plugin for Vim that has syntax highlighting improvements.
https://github.com/dsawardekar/ember.vim
Beyond that plugin, you could try writing your own solution. I haven't tried, but I doubt there is anything out there that will pick up spelling errors for Ember...
I use JSLint for SublimeText 3, which lints as you code so you get a live update of any potential bugs. Kinda nice. Here's something similar for Vim: https://github.com/hallettj/jslint.vim
As #kingpin2k suggests, you should really learn how to use your browser tools. The big three are just jam-packed full with development and debug tools. 9 times out of 10 it gives you the line and column of the error, and you can set breakpoints within the code to watch it execute in-context. And, that is really just the tip of the iceberg in terms of how detailed you can get with debugging in-browser.

Where can I find a list of JSHint numeric error codes?

I'm using JSHint for Visual Studio. It's not uncommon for JSHint to issue a warning about an issue that I know it safe to ignore. I have been putting // ignore jslint on the relevant line, but I see that we can also ignore specific error codes. From the 1.0.0 rc1 release notes:
This version adds a unique numeric code to every warning and error
message produced by JSHint. That means that you can now ignore any
warning produced by JSHint even when there is no corresponding option
for it. You can do that using the special minus (-) operator. For
example, here’s how you ignore all messages about trailing decimal
points (W047):
/*jshint -W047 */
Seems cool, but try as I might, I cannot find a list of all the error codes. Visual Studio's warning list doesn't provide you with the numeric error code, just the error text.
Surely this list is out there somewhere, right? I've literally spent an hour Googling for this. But no success so far.
The best place to look for things like that is the source (which is available on GitHub). The file you're looking for is messages.js (versions: current release (2.9.5, 2017-06-22), master branch, 2.1.4 (source for the code below)):
var warnings = {
W001: "'hasOwnProperty' is a really bad name.",
W002: "Value of '{a}' may be overwritten in IE 8 and earlier.",
W003: "'{a}' was used before it was defined.",
W004: "'{a}' is already defined.",
// ...
};
Not So Final Edit: Looks like a new site has been stood up that covers all the previous functionality: http://linterrors.com/js
I would recommend: http://jslinterrors.com/
This isn't a side-by-side list of all the errors, but it has each error (broken out by JSLint, JSHint, and ESLint) which include the specific error code per item.
For just JSHint, you can scope the view: http://jslinterrors.com/?linter=jshint
Final Edit: Looks like the site has gone under and is up for sale.
Edit: The codes can be found at the bottom of each section, if it relates to a fatal syntax the code cannot be suppressed.
Edit 2: Looks like they've added ESLint as well.

Syntax errors in hard to reach JS environments

I'm making an Opera Extension. It includes a background script which fails very silently. It runs in a unique environment, so I can't take it just anywhere to check if it works (it needs predefined variables). Is there a way to debug scripts without running them. That is, checking if the syntax is correct. I want something like JSLint, that instead of telling me how my code is bad tells me where the syntax errors are.
If you only want a quick search for SyntaxErrors, you could drop the code into Closure Compiler, and just choose the "Whitespace Only" option.
It'll notify you of invalid code without any code styling analysis to clutter things up.
http://closure-compiler.appspot.com/home
If you choose the "Pretty Print" option, it'll also give you a well indented result in case the original code needed some cleanup.

JavaScript: Possible uses for #debug directive?

Where I work, all our JavaScript is run through a compiler before it's deployed for production release. One of the things this JavaScript compiler does (beside do things like minify), is look for lines of code that appear like this, and strip them out of the release versions of our JavaScript:
//#debug
alert("this line of code will not make it into the release build")
//#/debug
I haven't look around much but I have yet to see this //#debug directive used in any of our JavaScript.
What is it's possible usefulness? I fail to see why this could ever be a good idea and think #debug directives (whether in a language like C# or JavaScript) are generally a sign of bad programming.
Was that just a waste of time adding the functionality for //#debug or what?
If you were using a big JavaScript library like YUI that has a logger in it, it could only log debug messages when in debug mode, for performance.
Since it is a proprietary solution, we can only guess the reasons. A lot of browsers provide a console object to log various types of messages such as debug, error, etc.
You could write a custom console object is always disabled in production mode. However, the log statements will still be present, but just in a disabled state.
By having the source go though a compiler such as yours, these statements can be stripped out which will reduce the byte size of the final output.
Think of it as being equivalent to something like this:
// in a header somewhere...
// debug is off by default unless turned on at compile time
#ifndef DEBUG
#define DEBUG 0
#endif
// in your code...
var response = getSomeData({foo:1, bar:2});
#if DEBUG
console.log(response);
#endif
doStuffWith(response);
This kind of thing is perfectly acceptable in compiled languages, so why not in (preprocessed) javascript?
I think it was useful (perhaps extremely useful) back a few years, and was probably the easiest way for a majority of developers to know what was going on in their JavaScript. That was because IDE's and other tools either weren't mature enough or as widespread in their use.
I work primarily in the Microsoft stack (so I am not as familiar with other environments), but with tools like VS2008/VS2010, Fiddler and IE8's (ugh! - years behind FF) dev tools and FF tools like firebug/hammerhead/yslow/etc., peppering alerts in your JavaScript isn't really necessary anymore for debugging. (There's probably a few instances where it's useful - but not nearly as much now.) Able to step through JavaScript, inspect requests/responses, and modify on the fly really makes debugging alert statements almost obsolete.
So, the //#debug was useful - probably not so much now.
I've used following self-made stuf:
// Uncomment to enable debug messages
// var debug = true;
function ShowDebugMessage(message) {
if (debug) {
alert(message);
}
}
So when you've declared variable debug which is set to true - all ShowDebugMessage() calls would call alert() as well. So just use it in a code and forget about in place conditions like ifdef or manual commenting of the debug output lines.
For custom projects without any specific overridden console.
I would recommend using: https://github.com/sunnykgupta/jsLogger , it is authored by me.
Features:
It safely overrides the console.log. Takes care if the console is not available (oh yes, you need to factor that too.)
Stores all logs (even if they are suppressed) for later retrieval.
Handles major console functions like log, warn, error, info.
Is open for modifications and will be updated whenever new suggestions come up.

Is Annotation in Javascript? If not, how to switch between debug/productive modes in declarative way?

This is but a curious question. I cannot find any useful links from Google so it might be better to ask the gurus here.
The point is: is there a way to make "annotation" in javascript source code so that all code snippets for testing purpose can be 'filtered out' when project is deployed from test field into the real environment?
I know in Java, C# or some other languages, you can assign an annotation just above the function name, such as :
// it is good to remove the annoying warning messages
#SuppressWarnings("unchecked")
public class Tester extends TestingPackage
{
...
}
Basically I've got a lot of testing code that prints out something into FireBug console.
I don't wanna manually "comment out" them because the guy that is going to maintain the code might not be aware of all the testing functions, so he/she might just miss one function and the whole thing can be brought down to its knees.
One other thing, we might use a minimizer to "shrink" the source code into "human unreadable" code and boost up performance (just like jQuery.min), so trying to match testing section out of the mess is not possible for plain human eyes in the future.
Any suggestion is much appreciated.
You can overwrite the Firebug console functions so they do nothing:
console.log = function() { };
You could perhaps include this into your code in your build process.

Categories