← Back to team overview

kicad-developers team mailing list archive

Re: 3d viewer updates

 

Le 24/03/2015 10:43, Mário Luzeiro a écrit :
> Hi Jean-Pierre,
> 
>> and
>>     unsigned char*  m_pixels;
>> should be:
>>     unsigned char*  m_Pixels;
> 
> I am a little confused about this. 
> I was checking with the coding style policy and this look different because there are no example case for m_* use.
> 
> I checked in the source files and I can see in public mixed m_Upcase and m_lowercase.
> 
> Could you please clarify this and other related policies on variable naming? ... or what is the most used trend now in kicad? 
> Maybe the policy document miss some updates regarding this m_* uses?
> 
> Thank you,
> Regards,
> Mario Luzeiro
> 

"m_" can be see only as a prefix to mark a member variable.
Using m_ as prefix for variables member of classes is not mandatory.
It is just a matter of personal preferences. I am using this prefix to
avoid confusing private members and local variables.

The coding style policy say only the private variables (and functions)
members starts by lowercase and public by uppercase.

if you use m_ as prefix, if "pixels" is a a private member, name
it:
m_pixels
If it is a public member name it:
m_Pixels
if you do not use m_ as prefix:
pixels is a private member
Pixels is a public member.

>From my point of view, if you do not use a prefix, a variable named
"pixels" can be a private member or a local variable.
This is confusing (for me, because updating a member variable is not the
same thing as updating an obscure local variable), and usually I am
using the m_ prefix notation for members (this is a personal choice).

Here and there in the code, you can find some public members/functions
names starting by a lowercase and some private members names starting by
a uppercase. It should not happen, but:
- Some code was written before the coding style policy was published.
- Sometimes, a public (or private) variable (or function) is changed to
a private (or public) one and (due to my laziness or thee laziness of
the author) the name of the variable and therefore the full code is not
always modified.


-- 
Jean-Pierre CHARRAS


References