Hauke Duden wrote:
> 
> Helmut Leitner wrote:
> > I think we should also consider:
> >    I_XxxxxYyyyy   T_XxxxxxxYyyyy  (for readability)
> 
> Hmmm. For me this is not more readable at all. It looks like the beginning of a constant.
> 
> >    InterfaceXxxxxYyyy   TemplateXxxxYyyyy  (Appreviations are evil)
> 
> Not if you have to use them all the time! There's a reason why 'for' is called 'for' and not 'LoopWithAutomaticInitializationAndConditionCheckAndIncrementation'.
> 
> Abbreviations are only evil if they cannot be easily understood. I.e. for many variable names abbreviations are a bad thing if strangers are trying to understand the code [I often refer to this as the wheel-of-fortune style of programming - for some people, vowels seem to cost money ;)].
> 
> However, if there is an accepted convention for the I and T prefixes then everyone using D will instantly understand them.

This has very much to do with habits.

It's about a clear separation of semantic units (words).

A clear separation is
   - a change lower to upper
   - a separator character like "_"

These are not clearly separable (you need insider knowledge):
   fopen
   strrchr
   ShowHTML
   IPrt
   IBMClass (interface "BMClass" ?)

These are clearly separable (even if one isn't used to it):
   file_open
   OpenFile
   OPEN_FILE
   InterfacePrintable
   I_Printable
   toString

Personally I prefer slight abbreviations, but the trend is against it.

IMHO it would be better for the development of D not to abbreviate. "No abbreviations" would mean "no discussions about abbreviations". This would free energy for more impotant things.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:
> This has very much to do with habits.
> 
> It's about a clear separation of semantic units (words).
> 
> A clear separation is
>    - a change lower to upper
>    - a separator character like "_"
> 
> These are not clearly separable (you need insider knowledge):
>    fopen
>    strrchr
>    ShowHTML     IPrt
>    IBMClass (interface "BMClass" ?)
> 
> These are clearly separable (even if one isn't used to it):
>    file_open
>    OpenFile
>    OPEN_FILE
>    InterfacePrintable
>    I_Printable
>    toString 
> 
> Personally I prefer slight abbreviations, but the trend is against it.
> 
> IMHO it would be better for the development of D not to abbreviate.
> "No abbreviations" would mean "no discussions about abbreviations".
> This would free energy for more impotant things.

Heh. So would the rule "always use abbreviations" (which I'm definitely NOT advocating!).  That doesn't make it a good rule.

I also prefer OpenFile to fopen. However, I definitely think that prefixing every interface name with "Interface" instead of "I" is too verbose.

The fact that abbreviations are problematic does not mean that names should be long. The key is to make the names as short as possible and keep them intuitive and understandable at the same time.

"toString" is a good example. It is immediately clear what it means if you see obj.toString, even though the name is short. However, if you get right down to it, toString doesn't really describe what the method does. Is something strung together? Is the parameter (which is really a formatting argument) converted to a string? What kind of string is produced?

"convertThisObjectToCharacterString" would be more exact. However, every programmer knows that a "string" is a character string if nothing says otherwise. Every programmer also knows methods work on their own objects by default. So the short name is understandable and long enough.

The thing is to have good "defaults" that can be used in names. Having a consistent naming convention for a language goes a long way to establish such defaults and thus allows shorter names. If the "I" prefix is standard then the default exists and there is no need to describe the meaning of it further in every single interface you create.

Hauke

Hauke Duden wrote:
> The thing is to have good "defaults" that can be used in names. Having a consistent naming convention for a language goes a long way to establish such defaults and thus allows shorter names. If the "I" prefix is standard then the default exists and there is no need to describe the meaning of it further in every single interface you create.

What is IOFile

  - an input-output-file
  - an interface to OFile

???

Using a "I_" or "Interface" prefix it would be clear.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"J Anderson" <anderson@badmama.com.au.REMOVE> wrote in message news:bkkfta$f1q$1@digitaldaemon.com...
  Sean L. Palmer wrote:

I don't really care what style the library is written in... I just don't like to have to switch styles when I am dealing with different libraries. If you're using 3 libraries you have to mix 3 different styles, plus your own style.  That's a lot to remember.

Sean


  I'd also like it if the _ was optional, although I know that's never going to happen.
Could happen!  That's a good idea.

Please trim your quotes down.  Several pages for a one-liner with no indication of where the quotes were and where your reply might be was a bit frustrating.

Sean

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3F6F1A8E.4550CCA5@hls.via.at...
> Personally I prefer slight abbreviations, but the trend is against it.
>
> IMHO it would be better for the development of D not to abbreviate. "No abbreviations" would mean "no discussions about abbreviations". This would free energy for more impotant things.

Heh... forget abbreviations, just choose shorter words!!  ;)

Sean

Helmut Leitner wrote:
> What is IOFile
> 
>   - an input-output-file
>   - an interface to OFile 

Aaah. Good one ;). This problem never occurred in my programs because every kind of class construct has a prefix (normal classes have a C).

So IOFile would be an interface to an OFile.

> Using a "I_" or "Interface" prefix it would be clear. 

True. But as I said earlier, for me it looks too much like a constant. I also don't like having to type underscores. Maybe it is just the way I type (kind of 8 1/2 finger freestyle), but for underscores I need to move my hands more than I like to do. It may also have something to do with the german keyboard layout, I don't know.

I realize that this is entirely subjective, though. Still, I found conventions that I am quite happy with and that do not use underscores at all.

These are:

CClass
IInterface
TTemplate

someMethod()
someVariable

m_MyMember

SomeConstant



Works pretty well for me.

Hauke

> What is IOFile
>
>   - an input-output-file
>   - an interface to OFile

Then, what's OFile? We say "no abreviations" remember? :)

On Mon, 22 Sep 2003 23:01:37 +0200, Helmut Leitner <helmut.leitner@chello.at> wrote:

>
>
>Hauke Duden wrote:
>> The thing is to have good "defaults" that can be used in names. Having a consistent naming convention for a language goes a long way to establish such defaults and thus allows shorter names. If the "I" prefix is standard then the default exists and there is no need to describe the meaning of it further in every single interface you create.
>
>What is IOFile
>
>  - an input-output-file
>  - an interface to OFile
>
>???
>
>Using a "I_" or "Interface" prefix it would be clear.

Ideally, I think it should be an IoFile. Just like I have an
XmlDocumentFactory, not an XMLDocumentFactory.
So, an IOFile should be an interface to an OFile. But what the hell is
an OFile?

 An interface to an IoFile should be an IIoFile. Just like a template
for a Thingy should be a TThingy.

--Benji