CamelCase versus wide_names (Prothon)

[Carl Banks]

Joe Mason <joe at notcharles.ca> wrote in message news:<slrnc7uo0d.ajs.joe at gate.notcharles.ca>...
> In article <1XIfc.246$GN6.122 at fe2.columbus.rr.com>, Carl Banks wrote:
> > but avoid the wide names when they're uber-ugly and unreadable in
> > operator-laden code like this:
> > 
> >     pitch_rate_coefficient = pitch_rate*mean_aerodynamic_chord/total_airspeed
> 
> Spaces are a much better way to fix this than camelCase.
> 
>   pitch_rate_coefficient = pitch_rate * mean_aerodynamic_chord /
>                            total_airspeed

Well, when you get into more complicated examples, with lots of
operators and parentheses, the spaces don't help much either.  Also, I
like to use spaces to give a visual clue about nesting level, so I
don't used them in the most nested operations.

But if it makes you feel better, I don't actually use camel case
there, either.  I just string the words together with no underscores
and all lower case.  The OP had ruled that one out, though.


> > It would not surprise me if the people who prefer wide names tend to
> > be applications-type programmers, whereas those who prefer camel case
> > naming tend to be numerical-type programmers.
> 
> I'm somewhat surprised numerical-type programmers don't just use 
> ubershort variable names.  Using _ for subscript:
> 
>   P_r_c = P_r * ADC_m / A_t
> 
> (I'm not advocating this style, but seems like direct translations from
> math or engineering algorithms would encourage it.)

I do advocate retaining the nomenclature of the domain you're
programming in, as long as the names are of local variables or
structure attributes.  However, the OP's question was about neither
local variables nor domain-specific naming, so I didn't bother with
this possibility.


-- 
CARL BANKS