lua-users home
lua-l archive

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


On Mon, Mar 28, 2011 at 4:16 PM, Gaspard Bucher <gaspard@teti.ch> wrote:
> Hi list !
> For a long time, I have been able to stick with the conventions inherited
> from ruby: PascalCase for classes, under_score for all the rest.
> Now that I am working with Qt, I have a problem: all Qt methods are camel
> case. After some time, my Lua code starts to look really weird:
> instance:setHue(def.hue or 0.2)
> instance:set_inlets(def.inlets)
> setHue is a method used in a QWidget, set_inlets is used in a sub-class from
> QWidget.
> At this point, I have 3 options:
> 1. rename Qt methods to use under_score (I subclass and rewrite methods
> anyway).
> 2. use camel case in the context of Qt and Qt sub-classes (but this means we
> will see setInlet for NodeView and set_inlet for Node which could be
> confusing).
> 3. use camel case everywhere (more work but doable on the long run).
> What is your advice ? Is there any "native" style for Lua ?

As others said, the Lua standard libraries use all-lowercase, no
separator names, such as package.seeall.

High-profile modules that have been out there for a long time, such as
LuaSocket and LuaFileSystem, tend to follow this, but the occasional
underscore_separated names creep in (lfs.lock_dir, url.parse_path).

In LuaRocks I use all-lowercase underscore_separated names, and try to
keep names reasonably short. Mixes nicely with the standard libraries
and most third-party modules I've ever worked with.

When working with foreign bindings, I tend to respect the original
code's casing. For instance, for Java methods bound through LuaJava I
use javaMethodNames as usual. Yes, the style gets messier but over the
years I found the visual distinction between native Lua functions and
bound Java methods to be beneficial. At times, this encourages
wrapping the function in more Lua-like functions. It's also handy to
see clearly what's actually Java when hunting for odd behaviors caused
by abstraction leaks.

-- Hisham