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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2a687662f09731bb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc07.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Anonymous Coward Subject: Re: Ada Quality and Style book discussion ("_Type" suffix) References: Message-Id: User-Agent: slrn/0.9.7.4 (Linux) Date: Thu, 17 Nov 2005 04:23:36 GMT NNTP-Posting-Host: 141.149.78.234 X-Complaints-To: abuse@verizon.net X-Trace: trnddc07 1132201416 141.149.78.234 (Wed, 16 Nov 2005 23:23:36 EST) NNTP-Posting-Date: Wed, 16 Nov 2005 23:23:36 EST Xref: g2news1.google.com comp.lang.ada:6438 Date: 2005-11-17T04:23:36+00:00 List-Id: In article , Simon Wright wrote: > >> I also object to the guides comment advising against "Day_Type". >> It's a very good practice to suffix types with "_Type", "_Record", >> or "_Array", so it's clear from the identifier what it refers to, >> and also so you don't hijack a good variable name. In the above >> case, "Day" can no longer be used to name an object. > > This is one of the more contentious style arguments. If you work on > my project, I will insist that you _don't_ stick these useless > suffices on. Suffixes are *very* useful, as I will illustrate. It's no coincidence that well named, direct, concise type names very often match (verbatim) good names for objects (including enums), in the absense of a type suffix. For example: package Name_Collisions is type Day is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday); type Meters is new Float; type Feet is new Float; --Oops, can't use these enums, since they were hijacked for --numerical specs. -- type Length is (Feet, Meters, Miles); --Oops, can't use these names either, since "day" was hijacked. -- type Timestamp_Component is (Month, Day, Year, Hour, Minute); type Speed is new Float; --No can do. "speed" hijacked by type definition. -- Speed : Speed; end Name_Collisions; I've worked on a project that prohibited use of "_Type", and name collisions like above were a regular irritation, forcing users to constantly workaround the problem by prefixing "A_" to objects that needed no specific nomenclature. Needless to say, the code was quite ugly, because folks had to attach more junk to the identifier, and worse, there was no uniform pattern. Some people would do the "A_", others would resort to "_Object", and the more disciplined users would simply replace "_Type" with "_Kind" :] The other projects I've worked did not ban or impose "_Type". And in those situations, programmers naturally adopted the "_Type" convention, simply because it mitigates name collisions while simultaneously enhancing readability and style uniformity. The "_Type" convention is customary from what I've seen.. folks with different backgrounds naturally use it as if they were trained to. So the Ada Quality and Style book should be updated to pass on the good customs to beginners. > And I'm not sure that Day is a good variable name; It depends on the situation. Sometimes you might clearly want a "Day" object, and more english only serves to confuse or detract from the operations. And in other cases more distinction may be in order. > if it's not worth giving it a name which indicates its use, what's > wrong with plain D? That's too cryptic.. it's a C coding hacker style that has no place in Ada. I can't think of any cases where it would make good sense to strip away its identity like that.