CamelCase versus wide_names (Prothon)
Joe Mason
joe at notcharles.ca
Fri Apr 16 00:25:16 EDT 2004
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
> 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.)
Joe
More information about the Python-list
mailing list