From: Jaroslav Hajtmar <hajtmar@gyza.cz>
To: ntg-context@ntg.nl
Subject: Re: Lua programming conventions..
Date: Thu, 30 Sep 2010 11:49:00 +0200 [thread overview]
Message-ID: <4CA45D0C.50702@gyza.cz> (raw)
In-Reply-To: <op.vjt99afttpjj8f@lpr>
Thanx Lukas
Thanks for the comprehensive answer - I needed to know.
Codes for own use probably does not make sense to solve, but I started
to write a separate public ConTeXt module with many Lua code, so I want
to meet Lua code conventions.
I also have my habits, but I want to code written as it should be.
Thanx Jarda
Dne 30.9.2010 11:35, Procházka Lukáš Ing. - Pontex s. r. o. napsal(a):
> On Thu, 30 Sep 2010 10:47:42 +0200, Patrick Gundlach
> <patrick@gundla.ch> wrote:
>
>> Hi,
>>
>> besides that what Luigi wrote, I'd recommend the Lua users wiki.
>> Don't take everything there as "perfect" or "the official way", as it
>> is just a users wiki, like our wiki.
>>
>> http://lua-users.org/wiki/
>
> Hello,
>
> I'd say there is no universal naming convention.
>
> For example I found local variables written with upper case
> (http://lua-users.org/wiki/AsciiMenu) ("local DASHES = string.rep('-',
> 80)") - it is not very common in programming to name local variables
> with upper case.
>
> But in this case -
> - it was probably to mark the variable as CONSTANT (as Lua doesn't
> have "const" keyword like C, where uppercase names are generally used
> for macros as constants or enums).
>
> So:
>
> - namespaces (modules) are generally named with lowercase names
> ('mynamespace.') (like in C? 'std::', 'boost::'),
>
> - variables are generally named with lowercase names ('_' may be used
> inside, so we get 'myvar' or 'my_var')
>
> - - constants with uppercase? ("local PFX = '#'"?) May be.
>
> - - global variables? One may prefer prefixing such variables somehow,
> so we get '_my_pfx' (or '_MyPfx' or '_myPfx')? (In C/Cpp, personally I
> use the 'g' prefix and camel notation, so I get 'gMyVar', opposite to
> all other vars with lowercase names like 'my_inner_var'.) But if a
> variable is to be global, it's better to encapsulate it to a
> namespace; thus "mark of globality" in the name gets unnecessary as we
> access the variable like 'mynamespace.var' (it's obvious the variable
> is global for that namespace).
>
> - functions? Naming like 'thisIsMyFunction()' (camel convention) is
> quite often, but one may prefer C-like naming ('this_is_my_function()'
> - so like internal variables?) or "TeX" convention
> ('thisismyfunction()') (natural to standard function, so we don't have
> 'string:g_sub()' or 'string:gSub()' but 'string:gsub()').
>
> I'd say this to a wider discussion. You may get inspired from existing
> code as Patrick wrote, or e.g. to have a look into .lua scripts in ctx
> minimals.
>
> Lukas
>
> ___________________________________________________________________________________
>
> If your question is of interest to others as well, please add an entry
> to the Wiki!
>
> maillist : ntg-context@ntg.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
> archive : http://foundry.supelec.fr/projects/contextrev/
> wiki : http://contextgarden.net
> ___________________________________________________________________________________
>
>
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
prev parent reply other threads:[~2010-09-30 9:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 18:30 Jaroslav Hajtmar
2010-09-29 19:05 ` luigi scarso
2010-09-30 8:47 ` Patrick Gundlach
2010-09-30 9:35 ` Procházka Lukáš Ing. - Pontex s. r. o.
2010-09-30 9:49 ` Jaroslav Hajtmar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CA45D0C.50702@gyza.cz \
--to=hajtmar@gyza.cz \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).