At 3:57 PM +1000 9/26/06, Brian, Geoff wrote:
Hi all,

I have struggled with the recommended variable naming standard for a
while due to its implications on writing clean code.

My conclusion was that when writing code I would probably not use the
name as recommended. I would include a reference to the axis systems but
remove the units. For example: airpathBankAngle    - for the bank angle
relative to the airpath.
                    flightpathBankAngle - for the bank angle relative to
the flightpath.
                    geographicX         - the X position in geographic
                    geodeticY           = the Y position in geodetic
                    velocityBodyEarth_Geographic - the velocity vector
of the aircraft CG (Body) with respect to the Earth, expressed in
Geographic coordinates.

The reasoning behind this is to minimise coding effort by making the
code to be as general as possible, and therefore reusable irrespective
of the computing unit basis (Imperial, metric, etc). Variables would be
scaled to a common computing unit basis using a unit identifier, such as
that stored in "units=" attribute in Aero-ML files before being used.
The unit identifier e.g. fs-1, etc are easily treated as character
strings and thus not an arithmetic operation.

If the purpose of the naming standard is to associate a name with data,
as done in Aero-ML files, it can easily be accommodated by treating it
as a character string. If the purpose is to define the recommended
naming convention for variables within a piece of code, I would suggest
a rethink maybe similar to that above.

My interpretation of the naming standard was to use it to name data
within the Aero_ML files, and therefore, I don't really see the problem
associated with using a "-" within the unit definition, be it in the
name or units tag.

I think I mentioned this already, but if not I think it useful to have a
separator character between unit types (e.g. a '.', '_' or space:
ft.s-1 or ft_s-1, or ft s-1). This would improve readability of the
units associated with a variable and avoid confusion where a symbol may
be both a prefix and a unit definition (e.g. 'd' a as degrees or as a
prefix of deci). It would also simplify to process of parsing a unit
character string within a program that computes unit conversions.

The following also has definitions for axes conventions that may be of
worth considering;
ISO 1151 (version current for each part at 30 June 2004), Flight
Dynamics - Concepts, Quantities
and Symbols, International Organization for Standardization.

Geoff Brian
Aircraft Performance and Flight Dynamics
Defence Science and Technology Organisation

and at 1:09 PM -0400 9/25/06, Hildreth, Bruce wrote:
How about changing the "-" to a "_"?


Would be

I am agreement now with Brian, in contrast with a previous correspondence with Bruce Hildreth.

If all modeling is done in XML, the units are 'meta-data' that is carried in the variable definition as an attribute, and *could* include "ft_s-1" as an encoding method to describe actual units.

This is now my preferred solution. Alternatively, we could adopt both (meta info and underscore).

Carrying the units with the variable name means at least two different variables to track alpha, beta, etc. in SI and English units...

-- Bruce

Reply via email to