[Bf-python] Naming conventions - part I

[Willian Padovani Germano]

Hi,

As I said, I'd like to propose / discuss a few conventions, some
actually important.  This is the start:

Trivial:

1) On irc we already discussed about the main prefix: to follow the rest
of Blender, as Michel pointed, it'll be BPY_ .  This will only be done
in the final step to substitute bpython.

** Substitute EXPP_ for BPY_ before final integration.

2) We've used the prefix M_ for the module functions and C_ for our new
Blender Types type and methods.  I used that back when I started to make
a clear distinction between module and type implementations in a single
file.  M_ for module, obviously, and C_ for python "C"lass.  This is not
good, it looks like some lib naming convention, like SDL_, etc. Class
isn't even a C concept.

What about BPy: BPyCamera, BPyObject, etc.?  For readability, of course,
we use BPy_Camera, BPy_Object.

** Substitute C_ for BPy_ , ok?

For the M_ one, I have no good suggestion.  Bpython used CameraModule
instead of M_Camera.  BPyM_ or BPyMod_ looks (to me) polluted, not
immediately distinguishable from BPy_ (though BPY_ is not that different
either, but still acceptable).  Leave it as M_ ?

3) In a module file we have:

Module functions: M_Object_Get()
PyType methods - specific:   Object_getData()
PyType methods - default:    ObjectDealloc
public functions: M_ObjectCreatePyObject(), M_Object_Init()

For readability and to keep them different from each other kind, I
propose:

- M_Object_Get() (or whatever we use instead of M_)

- Object_getData() - no change

- Object_dealloc() - so these stay connected to the PyMethods right
above and not the public C functions below:

- Object_CreatePyObject(), Object_Init() -- because M_ would be only for
Python module functions like M_Object_Get().

It's better to have a convention and clearly separate these 4 groups
that occur inside each module file.  No need to follow the one I put
above, it's open for discussion.

--
Willian, wgermano at ig.com.br