class properties in c++

David Demland plug-devel@lists.PLUG.phoenix.az.us
Wed Jun 13 15:06:02 2001


I understand that for the mediocre engineer names mean nothing. But to take
care of every aspect of you job is what separates the mediocre from the
great. Just like I tell some of the teaches I work with, if we are sloppy in
our words, and names, we are sloppy in our work. After all if the words, and
names, are just slung around, how will any one doing maintenance on the code
know what the intent was? After all this is the problem in maintenance,
knowing what was indented so that the fix, or change, may be applied
properly.

After all as any Object Oriented engineer knows, there are many things from
structural engineering that do not fit the goal of OOE (Object Oriented
Engineering). By the way, with many schools still teaching structural
techniques, are you that certain that everyone knows what we are talking
about?

I would like to say that I am not trying to put any one down. As a manager,
and a teacher, I always try to improve everyone I work with, or teach. Maybe
I live in a dream world, but I live to see the day when the general public
finds that software is reliable, dependable, and so useful they look forward
to using it. I can not stand hearing all the jokes about software, and
software developers, producing crap, But after all the general public has
developed the attitude "hey this is not Burger King you can not have it your
way" and is this the right way to treat them? I can not see how anyone can
be happy working in an industry that has the reputation for being a
necessary evil we have to live with.

All I am trying to do is to show that by taking care of what we do, and
being the best at it, we can produce great software every time and the
consumer wins when this happens.

Thank You,

David Demland
Qa/Process Manager
CADTEL Systems, Inc.
11201 N. Tatum Ste. 200
Phoenix, AZ 85028
(602) 648-6054
Fax: (602) 953-4833
ddemland@cadtel.com

-----Original Message-----
From: plug-devel-admin@lists.PLUG.phoenix.az.us
[mailto:plug-devel-admin@lists.PLUG.phoenix.az.us]On Behalf Of Rob
Wehrli
Sent: Thursday, June 14, 2001 4:45 PM
To: plug-devel@lists.PLUG.phoenix.az.us
Subject: Re: class properties in c++


> First of all it is not a function, it is a method. A function is part of

Anyone "retentive" enough to bicker over whether to call an operation a
"function" or a "method," ...well, who cares as long as we all know what
we're talking about.  Next we'll be arguing over whether its an attribute,
member variable or a property.  My answer to the function versus method
versus operation argument is, hey, all the parameters/argument/signature
elements get tossed on the stack at some point, so who gives a crap what
they are called!  ...or, as one of my strong assembly programmer friends
likes to say; it don't mean $hit until its assembly anyway...

> structural programming where a method is part of object oriented. This is
> because functions live in libraries and methods live in objects. Second,

So a library of C++ classes have methods or functions?  Your argument
appears as weak as your explanation.  I'd recommend not picking apart
others' terminology for at least the simple reason that it doesn't matter
that much as long as everyone knows what you're talking about.  Why would so
many others call them an operation if method was the "correct" name?
...hell, I say function nearly synonymously.  I think that you may be
dwelling on a point that has little bearing to anything other than a
purposeful discussion on which is correct: method, function or operation?
An "object" can not exist without an instantiation.  Since most are
instantiated from some non-volatile storage of "libraries" somewhere in
their lives, what lines between function and method gets crossed and when
becomes rather hazy in my humble opinion.  I'm sure that there are people
out there who are fully prepared to duel this very issue to the death simply
to win some microscopic point of order, but do the rest of us have time and
energy for it?  ...and does it do more harm than good?

> naming is for your internal coding standards to dictate. But in many shops
I
> have been around we use a get and set prefix. More and more shops are
using
> proper case for this. For example:
>
> GetMyValue();
> SetYourValue();

Get and Set are commonplace accessor (getters) and mutator (setters)
prefixes; and they are made even more common by Java's thorough use of them.
As long as you convey your point clearly *and* you standardize in your
group, it is up to you to create anything you want if you're ready to live
with it for a long enough time :)

>
> In "Code Complete" by Steve McConnell there is a great chapter on how and
> why to name variables in the proper case. It is worth while to understand
> what studies have shown before you go down a path.

Whatever we do, let's not start thinking that correcting spelling and
grammar is worthwhile!  We might end up with people who know that pretty
does not mean very!  At the very least, we wouldn't want to dwell so much on
it that we lose sight of why we're here....

>
> That's my two cents.
>
> Thank You,

Code Complete is a good piece of work.  I thought that I heard that it had
been updated...can anyone confirm or deny it?

>
> David Demland
> Qa/Process Manager
> CADTEL Systems, Inc.
> 11201 N. Tatum Ste. 200
> Phoenix, AZ 85028
> (602) 648-6054
> Fax: (602) 953-4833
> ddemland@cadtel.com
>
> -----Original Message-----
> From: plug-devel-admin@lists.PLUG.phoenix.az.us
> [mailto:plug-devel-admin@lists.PLUG.phoenix.az.us]On Behalf Of Lucas
> Vogel
> Sent: Thursday, June 14, 2001 2:23 PM
> To: Plug-Devel (E-mail)
> Subject: class properties in c++
>
>
> If you are adding properties to a class, what is the common function
format
> in doing so? Do you use a get_/put_ prefix? What is the common practice?
>
> Thanks

Take a look at the original message...see how simply is just seeks
knowledge?  Let's all work together to make others feel that it is OK to ask
questions here without having to be shot down in flames over a bit of
symantecs, while trying to keep ourselves attuned to the possibility that
ours may be shortsightedness rather than uberness.

Take Care.

Rob!

_______________________________________________
PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel