RE: Lua LOC count bragging

[Dan Tull <dtull@...>]

> > On Mon, Dec 31, 2012 at 9:07 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
> > How large is the Lua codebase that you manage? (Across all relevant projects.)
> (Alexander Gladysh self reply)
> We have about 500 KLOC of Lua code now across all projects (not all
> actively developed, though), and...

Without getting too specific, I'll say that Lightroom alone is larger than that (though I included the unit test code in the counts and just used wc -l to find them and not something smarter that only counts "active" lines, so our numbers may not be apples to apples).

There's also several other apps of varying sizes (less than Lightroom, but not small, either) at Adobe following in Lightroom's Lua footsteps.

> Well, using strict coding guidelines, mandatory code review, mandatory
> auto-tests, some discipline, and project/developer rotation I guess.
Agreed. These are definitely all valuable practices to encourage.

Having worked on Lightroom for several (6) years and now on our shared Lua IDE based on some of the same core libraries as Lightroom there the most important practices are (in no particular order): continuous integration, automated unit tests wherever practical, a healthy measure of discipline mixed with aggressive application of the KISS principle, careful naming (especially avoiding ambiguous names), and modularization at large and small scales.

While Lightroom is quite large these days, it's broken into subsystems with constrained (albeit not strictly enforced) dependencies. Even without a compiler to enforce signatures, it's very important to define sensible API boundaries between components and use them to compartmentalize complexity. It's far easier to deal with a couple dozen subsystems (with reasonable inter-dependencies) of a few thousand lines than one 25K ball of mud.

Coming from a Java background, I expected a dynamic language codebase of this scale to be much harder to manage than it was/is in practice. There are challenges, to be sure, but not the disaster scenario that strong type system proponents would lead one to expect.

> > Maybe 2013 can be a 'Year of Static Analysis'. Thinking of looking at
> > whole-program static analysis,  using doc comments.  Even if a tool is
> > only 70% good, that's a lot better than 0%
> 
> Would be a nice thing to have. I still need to try lua-inspect on real data...

While we've had a single file linter for many years which helps to spot misuse of the global namespace, unused variables and functions, shadowed locals, and certain other problematic code patterns. I have recently achieved useful results (smarter auto-completion and automatic navigation to definitions of functions) based on whole codebase analysis, but I'm only starting to seriously explore more advanced static analysis for validation/spotting bugs.

Our linter is very conservative because false positives encourage people to ignore or hack around warnings and Lua's dynamicity makes it achieve that level of certainty when doing analysis beyond a very local level without making a lot of assumptions.

Conveniently, I have many hundreds of thousands of lines of code in somewhat varying styles to use as a corpus for testing various heuristics. :o)

Dan Tull
Lua Tools Dev.
Adobe

http://twitter.com/dantull