Re: C/C++ layering in PFile

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>With context I mean that classes are types while locals are variables. And
>>types occur only in 2 places within a function - in a variable declaration
>>(mixing up the type and variable while reading a declaration is, well, very
>>stupid) and template instantiation (here it's completely clear until
>>template parameters come into play - and we don't have these).
>>
>Well, its not a matter of being ABLE to read the code. Its a matter of how
>much consciousness is nessecary to do that.

Right. And I find it easier to look at the context (the human brain is very
good at pattern recognition) than to parse the symbol name.

>>>startSmallButallElseCapped.
>>
>>That generates some real weirdos:

>>fileType
>>
>What's wrong?

Well, perhaps it's not so weird for native english speakers, but here in
germany nouns always start with a capital letter. So when I see that
capitalization is used I expect that either (1) only the first letter is
capitalized (if the word's a noun) or (2) nouns in the symbol start with a
cap while the other parts don't or (3) *all* parts in a symbol consistently
start with a cap.

>>file     /* is that startSmall or all_small ? */
>>
>startSmall. See below.

I prefer to have it simpler: if there's a capital letter in it, it's a
local, otherwise it's a member.

>>URL      /* or more correct uRL ? */
>>
>That's bad nomatter what. It looks like a preprocessor symbol. Perhaps it
>should be url.

Anyone defining a preprocessor symbol that (1) is only three letters long
and (2) is a common abbreviation deserves to be beaten really hard.

>I think the reason that this is perfect for me is that all the different
>quirks of my personal coding convention supports each other, so as to make
>something that is greater than the sum of its parts. When taking apart and
>mixed with other conventions, it's not that great.

>Also, my convention is also based on putting as much information into the
>variable name, as long as it is without drawbacks, suchs as the prefixes
>"m_" and "p". They make it unnessecary to use your memory, you just have to
>look at the screen, which you are doing anyway, so its faster. Its easier
>for me, anyway... :)

Well, it isn't for me. Some reasons:

(1) Your convention is more complicated. Some examples from your code:
m_pMemPos        (member pointer variable - prefix "m_p", then StartWithCap)
m_capacityGrowth (member variable - prefix "m_", then startSmall)
size             (local variable - either startSmall or all_small)
capacityGrowth   (local variable - startSmall)

That's quite some variation in capitalization.
BTW: You also use ALL_CAPS for template types...

(2) Personal benefit
I do not want to tie me to any specific coding style and naming scheme,
because I *will* (and already do) have to be able to understand foreign
code written with a great variety of styles. When reading code as I do it
now - by looking at the patterns, at the context etc I don't have problems
with all these styles. If I'm used to having things encoded in variable
names on the other hand, I'll have a hard time.

(3) If I read code strongly taking the context into account (see previous
point) things encoded in symbol names don't benefit me - in fact they tend
to distract me, because my eyes are drawn to that funny construct at the
start of the symbol while I just want to get the "core" symbol name.

(4) Politics
As said some time ago, we want to attract other developers to this project.
And the more complicated, the stricter the coding standard is (especially
regarding coding style) the more likely it is that some of these people
will be put off because of it.


Anyway, I don't care what symbol naming scheme you use in your code's
internals. But don't expect me to follow it in my code.


	Christian
-- 

Drive A: not responding...Formatting C: instead