Re: Beginners question: Compound types, how-to?

["Randy Brukardt" <randy@rrsoftware.com>]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:4cd27fb2$0$7658$9b4e6d93@newsspool1.arcor-online.net...
> On 11/4/10 6:23 AM, Stephen Leake wrote:
>
> Why is it that the "_type"  camp is so consistently silent
> about giving specific contexts of what are just programming
> examples?

Because most of the time it isn't worth a lot of effort to "find a better 
name". The majority of names in my programs are for local variables that are 
used in very small contexts. Spending 15 minutes to find a good name (and 
that isn't unusual when it comes to naming; ARG discussions on naming often 
go longer than that...) is simply not worth it for temporaries, loop 
parameters and the like. Moreover, mechanically adding a "Temp_" prefix just 
to avoid adding a "_Type" doesn't exactly help anything.

The time when lots of effort in naming is important is when the names will 
have long life and wide visibility, as when designing reusable libraries. We 
in fact did spend quite a bit of time when design Claw in determining the 
naming conventions. These require at least:
   (1) Consistency and predicability -- users need to be able to predict the 
names of entities without referring to the manual or specification (once 
they are familar with the layout). Similarly, programmers of new Claw 
packages need to be able to figure out the names needed more-or-less 
mechanically.
   (2) Works for the use-adverse -- The naming needs to work for the 
use-adverse, so the names have to be reasonably short.
   (3) Works for the use-lovers -- The names needs to work for people using 
lots of use-clauses, so the names of types and objects need to be reasonably 
unique.
   (4) Clients should have maximum flexibility in names of objects and 
parameters -- as these are the most important in terms of readability.

In the end, we adopted "_Type" (as in "Root_Window_Type", "Button_Type", 
etc.); thus parameters are generally "Button : Button_Type". It seemed that 
some such prefix or suffix is needed in order to meet (1); using a fixed 
name like "Object" fails (3); and nothing else would be consistent. 
Subprogram identifiers are kept very short (they don't repeat any type 
information, thus "Create" rather than "Create_Button" -- use named notation 
if you need type information: "Create (Button => ...").

Note that Ada.Containers has similar requirements and ended up using similar 
solutions.

                                  Randy.