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.
Related
So, the core of my problem is that I might not know what the thing I want is called. I think it's called "metadata", but Google doesn't turn up anything.
Anyway when you type a function's name in WebStorm (though I can not imagine this being unique to it) it will sometimes display a tooltip, telling you what the function does and what parameters it takes- this really cuts down the time needed to look stuff up. So, I want to bundle those with the functions I write. How do I do that, or at least what is it properly called?
There isn't one term for it, unfortunately. Microsoft's term is "IntelliSense." Various other terms are listed in this answer on programmers.stackexchange.com:
Auto Code Completion
Code Completion
Code Hinting
Code Assist
I believe the term they use at JetBrains (the people behind WebStorm and IntelliJ and such) is "Code Completion," based on the WebStorm help.
More about WebStorm code completion on their blog. It looks like they'll work from the source code, using JSDoc if they find it.
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.
I made a function called test() in javascript file.Placed a simple alert into it.
In html file, called the method on click of a button. But,it was not being invoked.
Problem was in the 11th function, nowhere related to mine !!!! But, how can a person making his first javascript function suppose to find that out ???
I am looking for best ways to debug javascript.
You can debug javascript using many modern browsers. See this question for details on how to debug in Google Chrome:
How do you launch the JavaScript debugger in Google Chrome?
Furthermore, you shouldn't use alert() for debugging as this can give different results to a production version due to alert() causing a pause in the script.
It is best practice to use console.log() and view the output in the browsers Console.
You can also put debugger in your javascript code to force a breakpoint. However I prefer not to use this as forgetting to remove this before deployment will cause your script to pause, which can be quite embarrassing!
You should use the debug console provided by the browser.
Chrome has it inbuilt, press CTRL + SHIFT + j. In Firefox, install Firebug plugin.
In your code, add alert() to show flow and get values of variables.
Also, use console.log() which will only output to the debug console.
Depending on your browser choice there are debugging options - I tend to use Firefox, so Firebug in my case. There is a question that list options for other browsers - What is console.log and how do I use it?
Unless the project you're working on has already adopted a mechanism for debugging, console.log() tends to be a simple and useful option when tracking down a problem.
Whilst debugging you could take the approach to log out a line when entering a function, like so:
var myFunc = function(el) {
console.log('Inside myFunc');
// Existing code
};
This will enable you to see which functions have been called and give you a rough idea of the order of execution.
You can also use console.log() to show the contents of variables - console.log(el);
Be mindful to remove/disable console.log() calls once you're done as it will likely cause some issues in production.
To answer your question within question,
how can a person making his first javascript function suppose to find that out ???
Well, when something is wrong in JavaScript, for example, you made a syntax error - the script will stop working from there. However, this won't stop HTML from rendering on, so it might look as if everything is correct (especially if your JS is not changing the look of the page) but all the functionality of JS will be dead.
That's why we use the debug tools (listed in the other answers here) to see what's wrong, and in cases like this, it's very easy to notice which function has errors and is causing the whole script to break. This would probably have save a few minutes to your seniors as well.
The best approach would be to test frequently so that whenever you run into errors, you can fix them right away.
I am a chronic user of Firebug, and I frequently need to log various stuff so that I can see what I am doing. The console.log function is a lot to type. Even if I assign it to a single letter variable like q = console.log, I have to do it every time I fire up Firebug. Is there any way to do it such that q always refer to console.log (unless, of course, I override it in my session)?
To answer your question, the functionality doesn't currently exist, however I have found the firebug developers to be very responsive in the past. Why don't you put in a feature request on their forum, or better yet, code it up yourself, and ask them to add it?
Depending on your IDE, simply setup a code snippet (I use Flash Develop, so Tools -> Code Snippets).
I believe this to be a better way than setting up redirect scripts and what not, because it stops the Firebug namespace from being polluted, and makes it easier/more consistent to debug if your debugging breaks down.
The screenshot shows me using Flash Develop, hitting Ctrl+B, then hit enter. The pipe (|) in the snippet indicates where the cursor will be placed to start typing after inserting the snippet.
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.