1

I'm hoping someone who's given this some thought can help me understand. Most style-checking tools seem to distinguish between warnings and errors.

To me, the point of a lint error is that a style issue ought to be fixed.

In the cases where the tool isn't smart enough to see that an exception can be made, many tools have a syntax for ignoring/acknowledging the errors. This makes sense too.

What cases are left where a warning might be of any use?

closed as too broad by gnat, durron597, Matthew Flynn, Bart van Ingen Schenau, GlenH7 Oct 15 '15 at 18:20

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • It's looking like I shouldn't have used "lint" to mean style-checker. The responses below quite correctly point out that many static code analysis tools are designed to catch potential flaws, not style. – user1446 Oct 14 '15 at 11:38
3

Lint is not just about style-checking.

Many Lint tools do static code analysis. As such, they can detect errors in your code that would otherwise go undetected. That means you can screen your program for bugs before you run it.

The first Lint program was for the C language; it detected things like divide by zero, variables being used before they are set, and calculations likely to overflow. As the language standard improved and compilers got better at detecting and reporting errors, the Lint program gradually became less important. Today there's a Lint program for Javascript that Douglas Crockford wrote, which is still important because Javascript is still a young language.

Anyway, the point is that most of the coding style issues are more than likely warnings and not errors, because they are not going to cause your program to break. Things that will cause your program to break are classified as errors, not warnings.

2

Lint errors mean something is broken, or will break at runtime. Guaranteed null pointer errors, divide by zero errors, etc. Stuff like this that is legal syntactically, but is nonsensical:

int x = 5 / 0;
int y = *((int *) 0);

Warnings should mean "this is risky, but not guaranteed to cause a runtime error or exception." Example:

bool x = true;
while (x = true) { // Oops! Should be "==" or just omit the test
  ...
}

Implicit conversions in C++ also come to mind, as does mixing signed and unsigned variables in a single expression. They can cause some very hard to track down bugs, but Lint or a good compiler can point them out as warnings. Not errors, because the programmer might actually mean it and it is not an error that will crash your program.

  • What you say makes sense. Can you please also address whether it makes sense to have both warnings and errors for points of style? – user1446 Oct 14 '15 at 11:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.