If you feed your JavaScript through JSLint then there is a likelihood that it will give you a list of warnings about the way you have written some of your code. This is likely to be the case even if the script you feed through is one that you have already tested and know works.
This validation tool isn't just validating that you don't have any syntax errors in your code, it is also checking your code quality and identifying those things in your code that have the potential to cause errors and which therefore should be avoided - basically the validator tells you when you have used bad JavaScript.
The first thing to check if you get lots of warnings being reported by the validator is that you have checked the "Assume a Browser" checkbox. JavaScript can be run in a number of different places and the objects that are predefined for you when you run your script in a browser (such as the window object) do not necessarily exist in the other environments in which JavaScript can be run. This particular checkbox in the options is the one you need to check so as to tell it that your script is running in a browser and therefore all of the references in your code to those objects that browsers predefine for you should not produce warning messages to tell you that you forgot to define them. These particular warnings are for when you are intending that the script run somewhere other than a browser so as to point out to you that you are referencing things that only exist when JavaScript runs in a browser.
Most if not all of the other warnings that you can get from the validator (as distinct from actual errors where the code is not going to work at all) can be removed if you check all of the ckeckboxes in the second column of the options - all of the options that start with the word Tolerate. If you do that then you are effectively telling the validator to tolerate sloppy coding. I suggest that you only do this if you are validating a really old script that you are just making minor modifications to where you don't have time to rewrite the script to meet more modern JavaScript coding standards.
As a minimum, I recommend that whatever messages that you get when you validate your code with just the "Assume a browser" checkbox checked are ones that you should fix. All of the things that the validator can be set to tolerate if you check the boxes in the second column are things that you should be avoiding using in your modern unobtrusive JavaScript. By actually rewriting your code to get rid of these warning messages you will be improving your JavaScript code (and your own skills in writing JavaScript). Of course if you are relatively new to JavaScript then you may not know how to rewrite the code in order to get rid of the particular construct that the validator has labelled as "bad". The solution in that case is to post the section of code that the validator doesn't like to a JavaScript forum to ask those with more experience of JavaScript how to rewrite it to make it better. That is perhaps one of the best ways that almost anyone can improve their JavaScript coding skills.
Any warnings that are there even if you have all the tolerate checkboxes checked are errors just waiting to happen and must be fixed since even if the script currently works the constructs that these warnings are telling you about will almost certainly cause confusion when the script needs amending in the future.
Once you get the validator reporting no errors or warnings with just the "Assume a browser" checkbox checked then you know that you have reasonable quality JavaScript code (whether it does what it is supposed to or not is another matter and something the validator can't check). There may still be ways of improving further on the way your JavaScript is written so if you are comfortable that all of the JavaScript you are writing can pass this level of validation without warnings and you want to improve your JavaScript coding skills further then it is time to take the next step and press "The Good Parts" button before validating. Doing this applies even stricter rules in the validation by producing warning messages about other parts of JavaScript that you ought to avoid using.
Those warnings that get generated if you use "The Good Parts" button include additional JavaScript constructs where either a better alternative exists or where the construct is extremely inefficient and ought to be avoided. This list includes such things as making sure that all of the local variables that a function uses are defined in a single statement at the start of the function, using the identically equal operators (after converting data types if necessary) rather than the simple comparison that doesn't check type (and where if you accidentally leave of an = you get an assignment instead), not using any of the bitwise operators (which unlike most other languages where they are about the most efficient way to do certain things are the least efficient way of doing it in JavaScript), and avoiding the use of tests in regular expressions that can compromise security.
If you have these options turned on then you may decide that you will ignore for the moment some of the warnings that the validator produces in this instance. Provided that your script doesn't produce any warnings when these checkboxes are not checked you know that your code is to a reasonable standard and it is really up to you how much effort you want to put into getting your code to the even higher standard that these options can help you to achieve.
Where all of these warnings become of greater importance is where the script doesn't do what it is supposed to be doing. Where this happens any warnings may be related to the problem and fixing those warnings may be all that is needed to get rid of the error. At the very least in that instance, fixing the warnings eliminates one possible cause of the error and so you can move on to look for the cause elsewhere.
One last thing to consider if there are any warnings that you decide not to fix is to add comments to your script next to those particular statements stating that the particular statement has been deliberately coded that way and doesn't need fixing.