lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> > That really is the most sensible way to go - do it as early as
> > possible using a suitable IDE.
> While smart editors are good, it's also a good idea to be able to catch these kinds of 
> things as warnings during a build imho.

Yes, the same linter engine that provides live feedback in our IDE is run headless as
part of a build for just that reason. 

That said, while we have undeclared globals, unused locals,  and shadow locals, we 
only consider undeclared globals to be worthy of a build break.

Those are almost always a bug, whereas unused locals are (relatively) harmless.

There's one case of shadow locals I'd seriously consider including:

  function foo:bar( self, a, b ) -- <-- linter complains about self being shadowed

  end

I have never seen a case where that wasn't a declaration typo, but other kinds of
shadowing are less unambiguously wrong. I'm very conservative about false
positives when doing analysis.

The other lint hit that we could (but don't) include in the build is this one:

  if not foo == "bar" then

  end

I call it "not equals misuse" lint and it's always a mistake, but rarely happens once 
people are used to the language, so we haven't bothered including it, either.

Dan Tull
Lua Tools Dev
Adobe