From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2078dddcdcd8d83 X-Google-Attributes: gid103376,public From: dsmith@clark.net (Doug Smith) Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/11 Message-ID: #1/1 X-Deja-AN: 240968868 References: <5kjvcv$evt@news.cis.nctu.edu.tw> <5kn8ko$jcc@top.mitre.org> <1997May7.201035.2439@nosc.mil> <33727EEA.2092@sprintmail.com> <5kuf1j$17vi@uni.library.ucla.edu> <3373666A.31DFF4F5@spam.innocon.com> Organization: Clark Internet Services, Inc. Newsgroups: comp.lang.ada Date: 1997-05-11T00:00:00+00:00 List-Id: In article <3373666A.31DFF4F5@spam.innocon.com>, Jeff Carter wrote: [snip] > Now, allow me to indoctrinate you into the one true religion. Like you, > I want to preserve the meaningful name (List, Queue, What_Ever) for use > by objects and parameters. Unlike you, I insist that suffixes add at > least some information. So I want my suffix to indicate what kind of > type we're dealing with, as well as differentiating the type name. I use > many; here are a few: > > Numeric types: _Value, _Count, _Range > Enumeration types: _Id, _Name > Array types: _Set, _List > Record types: _Group, _Data, _Info > Task types: _Agent, _Controller > Private types: _Handle > > I'm also creative in my use of parameter names, using Into, Before, > After, From, To, and so on to avoid as much of this as I can: > > procedure Insert (Into : in out String; Before : in Positive; Value : in > String); > procedure Append (Onto : in out List_Handle; After : in Position; Item : > in Element); [snip] > -- > Jeff Carter PGP:1024/440FBE21 Several years ago, I found an excellent article on user interface design in Smithsonian magazine (no that is not a typo!) Two of the three principles were: 1) Make usage obvious, and 2) Use conventions. Other posters have applied these principles, but I like Jeff's usage of the suffix much better. Let me go a little further. We have not addressed the semantics issue very well. I think Jeff's reference to private type handles alludes to object semantics. If a naming convention grows out of certain common semantics, then usage will be more obvious. For example, I might expect certain operations and associated semantics with any type which has the _Set suffix. By convention, I would expect the union and intersection operations and the the default value of Null, etc. This naming convention may apply also to package names, as Booch used in his reusable components (although I found the architecture cumbersome). Then, as Jeff suggests, the suffix can distinguish between types, especially related types used in the same package such as _Info and _Handle. In fact, I have seen and used the suffix alone: Object, Class, or Handle. It is unlikely we will agree on any community-wide convention, but at least each reusable library should have some "foolish" consistency. Now to argue the other side, when there are no conventions which describe a type's semantics, then don't use a suffix: use a descriptive, general name.