$26.2 CHOOSING THE RIGHT NAMES 879 More than style standards,what would seem to require justification is the current situation of software development,with its almost total lack of style standards.In no other discipline that demands to be called "engineering"is there such room for such broad personal variations of whim and fancy.To become more professional,software development needs to regulate itself. 26.2 CHOOSING THE RIGHT NAMES The first aspect that we need to regulate is the choice of names.Feature names,in particular,will be strictly controlled for everyone's benefit. General rules What matters most is the names of classes and features which will be used extensively by the authors of classes that rely on yours. For feature and class names,use full words,not abbreviations,unless the abbreviations are widely accepted in the application domain.In a class PART describing parts in an inventory control system,call number,not num,the feature (query)giving the part number.Typing is cheap;software maintenance is expensive.An abbreviation such as usa in a Geographical Information System or copter in a flight control system,having gained an independent status as a word of its own,is of course acceptable.In addition,a few standard abbreviations have gained recognition over the years,such as PART for PARTIAL in class names such as PART COMPARABLE describing objects equipped with a partial order relation. In choosing names,aim for clarity.Do not hesitate to use several words connected by underscores,as in ANNUAL RATE,a class name,or yearly premium,a feature name. Although modern languages do not place any limit on the length of identifiers,and treat all letters as significant,name length should remain reasonable.Here the rule is not the same for classes and for features.Class names are input only occasionally (in class headers,type declarations,inheritance clauses and a few other cases)and should describe an abstraction as completely as possible,so PRODUCT OUANTITY INDEX EVALUATOR may be fine.For features,there is seldom a need for more than two or possibly three underscore-connected words.In particular,do not overqualifiy feature names.If a feature name appears too long,it is usually because it is overqualified: Composite Feature Name rule Do not include in a feature name the name of the underlying data abstraction (which should serve as the class name). The feature giving the part number in class PART should be called just number,not part number.Such over-qualification is a typical beginner's mistake;the resulting names§26.2 CHOOSING THE RIGHT NAMES 879 More than style standards, what would seem to require justification is the current situation of software development, with its almost total lack of style standards. In no other discipline that demands to be called “engineering” is there such room for such broad personal variations of whim and fancy. To become more professional, software development needs to regulate itself. 26.2 CHOOSING THE RIGHT NAMES The first aspect that we need to regulate is the choice of names. Feature names, in particular, will be strictly controlled for everyone’s benefit. General rules What matters most is the names of classes and features which will be used extensively by the authors of classes that rely on yours. For feature and class names, use full words, not abbreviations, unless the abbreviations are widely accepted in the application domain. In a class PART describing parts in an inventory control system, call number, not num, the feature (query) giving the part number. Typing is cheap; software maintenance is expensive. An abbreviation such as usa in a Geographical Information System or copter in a flight control system, having gained an independent status as a word of its own, is of course acceptable. In addition, a few standard abbreviations have gained recognition over the years, such as PART for PARTIAL in class names such as PART_COMPARABLE describing objects equipped with a partial order relation. In choosing names, aim for clarity. Do not hesitate to use several words connected by underscores, as in ANNUAL_RATE, a class name, or yearly_premium, a feature name. Although modern languages do not place any limit on the length of identifiers, and treat all letters as significant, name length should remain reasonable. Here the rule is not the same for classes and for features. Class names are input only occasionally (in class headers, type declarations, inheritance clauses and a few other cases) and should describe an abstraction as completely as possible, so PRODUCT_QUANTITY_INDEX_ EVALUATOR may be fine. For features, there is seldom a need for more than two or possibly three underscore-connected words. In particular, do not overqualify feature names. If a feature name appears too long, it is usually because it is overqualified: The feature giving the part number in class PART should be called just number, not part_number. Such over-qualification is a typical beginner’s mistake; the resulting names Composite Feature Name rule Do not include in a feature name the name of the underlying data abstraction (which should serve as the class name)