[openbeos] Re: Coding Guidelines
- From: "Jonas Sundstrom" <kirilla@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 12 May 2002 21:56:50 CEST (+0200)
Marcus Overhagen wrote:
[snip]
> I think we should use a identifyer prefix that is reserved for the
> implementor of libraries.
>
> http://homepages.tu-darmstadt.de/~st002279/os2/Standards.html
>
> http://www.lysator.liu.se/c/rat/d1.html (excerpt from the C89
> standard draft)
> |4.1.2.1 Reserved identifiers
> |
> | Also reserved for the implementor are all external identifiers
> beginning with an underscore,
> | and all other identifiers beginning with an underscore followed by
> a capital letter or an
> | underscore. This gives a space of names for writing the numerous
> behind-the-scenes
> | non-external macros and functions a library needs to do its job
> properly.
> | With these exceptions, the Standard assures the programmer that all
> other identifiers are
> | available, with no fear of unexpected collisions when moving
> programs from one implementation
> | to another.
>
> I'm not sure which one is really save. Is a class variable an
> "external identifier"? Then we
> may be able to use "_f", "_m" or any other prefix that starts with an
> underscore.
> If it isn't, we may need to use "__f", "__m", or "_M", "_F", or
> anything else starting
> with either two underscores, or one underscore and a capital letter.
>
> I really think we need to be careful here. No Identifiers (this also
> includes global variables,
> as well as non static pricvate functions, or entire classes" used
> internally should have a normal
> name, but must start with "_" or must be put into a namespace, if
> possible.
>
> As media kit programmer, I know that the media kit also has many
> potential name collisions,
> but I will correct them as soon as we have a determined a standard
> for them.
>
> The OpenTracker "f" should not be our standard, as it collides with
> the C standard.
> We need to change the coding guidelines!
> Personally, I would prefer using "_f" or "_m", but I'm not sure if
> they are the right choice.
I think the cases you mention are very different:
1. internal library stuff
2. exposed library stuff
3. member variables of (sub)classes, in app-space
Different problems/needs, different solutions.
1 - the lib devs need to keep internal/external pieces separated
2 - avoid clashes between lib / app stuff (app vs. lib dev)
3 - app dev needs separation between globals, constant,
member and local variables.
Is there a good tradeoffs between these different needs?
Is there a standard with the "big picture"?
/Jonas Sundström. ~ www.kirilla.com ~ www.kioki.com
Other related posts:
