Re: scope, design patterns?

[David Manura <dm.lua@...>]

On Mon, Dec 27, 2010 at 10:46 AM, Patrick Mc(avery
<spell_gooder_now@spellingbeewinnars.org> wrote:
> My newest project will probably be under 1K lines of code and would work
> with a poorly designed layout but I want to improve my habits. I do
> understand PIL/modules/upvalues quite well now but I am wondering if there
> are different strategies for managing much larger projects. I understand
> that lightroom is over 100k lines of Lua and there are other large
> applications too. Are there numerous design patterns out there to keep
> people from clobbering variables and organizing this much code? Do people
> usually just divide their code up into many modules?
>
> Would a book on Javascript design patterns help with Lua?

Besides design patterns, you might look into code maintainability.  Do
a search on "maintainable code" for general pointers.  Data privacy is
just one aspect of code maintainability.  A book dedicated to code
maintainability or one of the style guides, particularly one with
scripting languages in mind, may be more helpful.  Some pointers were
also started in http://lua-users.org/wiki/LuaStyleGuide .  In the case
of Lua, I find these helpful in writing maintainable code:

  (1) Consistently and clearly name variables.  Include some limited
amount of Hungarian notation if helpful --
http://en.wikipedia.org/wiki/Hungarian_notation .
  (2) Minimize scope of variables, data dependencies, and complexity.
Make the code easy to analyze.
  (3) Write test suites.  Note: this may be even more important with
dynamic languages like Lua.

If you can, have someone critique your code.

> clobbering variables

Locals make that easy to avoid.  Also, use a text editor that
highlights locals and globals differently to avoid typos.  The
`module` function (deprecated in 5.2-alpha) does some questionable
things with globals, and some avoid it.

> and organizing this much code? Do people
> usually just divide their code up into many modules?

Typically, but there's numerous ways to divide the code into N
modules.  One general rule perhaps is that if you plot the
dependencies between the N modules in the form of a graph, the number
of edges should be kept low.  Having every module depend on every
other module (N^2 edges) would be indicative of poor modularization.