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 coordinates. geodeticY = the Y position in geodetic coordinates. velocityBodyEarth_Geographic - the velocity vector of the aircraft CG (Body) with respect to the Earth, expressed in Geographic coordinates. Etc. 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. Finally, 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. Regards 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 "_"? So s_bodyXVelocity_fs-1 Would be s_bodyXVelocity_fs_1
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
