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