Re: Best Practices -- Naming Convention Question

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi Dave,

I guess I'll go counter to what everyone else is saying.

> I keep bumping into the desire to create classes and properties with the
> same name and the current favored naming conventions aren't
> automatically differentiating them... (both are "Pascal Case" with no
> leading or trailing qualifiers).
>
> For example... I'll be modelling something, e.g. a computer, and I'll
> create some classes:
>
> Monitor, Cpu, Keyboard, Mouse...
>
> And then I'll define a Computer Class...
>
> class Computer
> Monitor _monitor;
> Cpu _cpu;
> Keyboard _keyboard;
>
> and then I get to setting some simple accessors and I'm stuck with the
> inclination to do this:
>
> Monitor Monitor {get ... set...}
> Cpu Cpu {get ... set...}
> Keyboard Keyboard {get ... set ...}
>
> Now this does compile, but I think it makes the code more unreadable,
> and sooner or later I'll have to manually clear up ambiguities with
> extra qualifers or deal with build bugs related to writing Cpu thinking
> property but which the compiler determines is a class and i'll be facing
> especially cryptic build error messages as a result. Or perhaps worse:
> cryptic behaviour if it happens to build successfully.


I, like you, find the syntax
private Monitor _monitor = new Monitor()
Monitor Monitor { get{} set{} )
to be confusing and potentially problematic.

A "Monitor" as both a class and a property of another class is not, in my
opinion, a good clean way of understanding and describing the problem.

First off, if you model your system based on behavior, and not nouns, then
this kind of thing is rare because you do not often compose an object of
other objects that you then expose to outside manipulation (as you are doing
here).

Secondly, I would say that you lose an opportunity to express context when
you create your property names like this. If you have a Monitor object that
is of type "Equipment" and your system is composed of multiple bits of
Equipment, then you are unlikely to expose a "Monitor" property. You are
more likely to expose a property that would return a list of monitors from
the list if items in the system (since a system can validly have zero, one,
two, or more monitors associated with it).

On the other hand, from a naming convention, I would say that the property
name should be composed of an Adjective followed by the Object name in such
a way as to express context. Therefore:

class Computer {
public PrimaryMonitor Monitor { get ... set ... }
public SecondaryMonitor Monitor { get... set ... }
public List<Monitor> GetMonitors()
{ ... }
}


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages