Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: Naming Conventions Message-ID: Date: 9 Jan 91 18:54:08 GMT References: <60352@microsoft.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California Lines: 95 In-reply-to: jimad@microsoft.UUCP's message of 8 Jan 91 20:28:25 GMT X-Posting-Software: GNUS 3.12 [ NNTP-based News Reader for GNU Emacs ] >>>>> On 8 Jan 91 20:28:25 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said: Jim> As the library committee begins to propose classes and libraries to Jim> standardize, I wish to mention a subject that will probably provoke howls Jim> of anguish from all involved, namely: Naming Conventions. True, everyone seems to have their own convention -- sometimes influenced by utilities like indent, cref, cfunc, etc. Jim> My suggestion is that [besides being almost impossible to agree on] Jim> naming conventions need to be agreed upon in order to have standarized Jim> software, and that the exact names chosen for standard libraries and Jim> classes are important to their reusability. Knowing the names of objects promotes their reuse. Without some convention, finding an object to reuse in a series of massive libraries is like trying to find the meaning of a word in a dictionary when you don't know how to spell the word. Jim> I believe if the committee did decide that "simple" value semantics Jim> standard classes should be all lower case like built-in types, whereas as Jim> "complicated" standard classes intended to be used with derivation, Jim> polymorphism, etc, start with a capital, then this would be _a_ good Jim> choice, helpful to C++ programmers by clarifying the difference in uses Jim> of these two types of classes. Yet another humble suggestion: No matter what naming convention is chosen, someone (probably a lot of someones) somewhere will not understand the convention and, therefore, have trouble (re)using the library because of the dictionary principle above. This was recognized as unavoidable with dictionaries and, so, thesaurus's and the like came into being (not a perfect solution, but it definitely helps). Therefore, I suggest adopting a thesaurus principle in the naming of objects and, I believe, that the C Preprocessor is the mechanism to implement it. In laying out a C++ library of objects for others to (re)use, each object will be declared somewhere in some include file. Users of the library will include this declaration file and then begin making use of these objects. If the include file has provisions for a C preprocessor "thesaurus", then programs akin to Cref can be developed that can not only produce a list of object declarations, but a cross-referenced thesaurus of possible other names for the objects. For instance: ================ // File - complex.h #ifndef COMPLEX_H #define COMPLEX_H #include "complex.ths" class complex { // ... }; #endif ================ // File - complex.ths #ifndef THESAURUS_OFF #ifndef COMPLEX_THS #define COMPLEX_THS #define Complex complex #define COMPLEX complex #define ThisIsComplex complex // ... #endif #endif ================ With this convention and a proper tool for browsing these definitions, users of the library should be able to find an object regardless of the convention they prefer (assuming the thesaurus has been extended to include their particular convention). This convention also has the potential to allow for an open libraries convention (preventing library vendor lock-in) as it allows a user to use libraries with different naming conventions but similar functionality simply by adjusting the thesaurus. The C preprocessor doesn't go far enough in this scheme because for this scheme to be truly useful, it should allow the renaming of member functions and data elements within the object. The C preprocessor has no way of determining the difference between an add() function that is a member of the complex object and an add() function that is a member of the real object. This may be an area that the standards committee could address. Comments? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"