thisIsAMemberFunctionName vs this_is_a_member_function_name

[John Dill]

But if you use a different class library, you might want to change

your style to fit in with that (eg MFC prefixes every class with 'C',
goodness knows why).

Well, how else would you know that it is a class? I think it came
in through the hungarian notation that microsoft has supported so I
surmise that C=class?

 

[Allan W]

(e-mail address removed) (jbruno4000) wrote

This conversation has truly exausted itself!

Yes, it was doomed from the start. It isn't quite a troll, but the
topic is one that's guaranteed to generate more heat than light;
not unlike a message asking what's the best computer language, or
why we don't all boycott Microsoft.

For the record: in my opinion, there are some issues where it's much
more important to have SOME standard, than anything that standard could
possibly say. When you're working with a group of programmers, you
should use the same indentation style, the same tab stops (or else only
use spaces), the same naming conventions, and so on. If your personal
code stands out in some way (other than comments with your name on it),
you're making maintenance much more difficult than it needs to be.

That means doing things even if you think they're stupid. If everyone
else uses "m_" in front of all member variables, you should do it too
even if you don't think it clarifies anything. On the other hand, if
nobody else does it you should refrain as well. If you really think
that everyone ought to be using "m_" in front of member variables,
propose it at a team meeting -- be prepared to explain why it's worth
fixing every line of code already written. (Or bring it up at the
beginning of the next project, before any code is written.)

The one exception to this philosophy is comments. AFAIK, nobody has ever
received negative feedback on their code because the comments were too
clear. My personal rule of thumb is to put a comment on almost EVERY
line of code, explaining why it's there (and assuming that all readers
already understand WHAT it does, so there's no point explaining it:
totProc += 17; // Add 17 to totProc
That comment does nothing useful, but
totProc += 17; // Update running count of orders processed
does, though you should now explain why 17 is the right value.)

 

[kanze]

John Dill schrieb:

A similar naming-convention dilemma exists, if you are going to
specialize template classes of std componets or if you want to provide
a namespace swap function, which could by used by std::algorithems
(provided that some yet unresolved swap issues **are** solved)

Yes and no. swap, vector, string and map fit in with both schemes. And
who uses anything else.

Seriously, I sort of like having the library use a different convention.
That way, the reader knows to look in the standard, and not in my code,
for the documentation. Of course, the leading std:: should be a
sufficient give away.

In practice, the projects I've worked on have all used the second
convention for the project names, and having the standard library names
use a different convention doesn't seem to have ever bothered anyone.

 

[Gavin Deane]

Well, how else would you know that it is a class? I think it came
in through the hungarian notation that microsoft has supported so I
surmise that C=class?

<reposting as similar previous message seems to have got lost>

I thought it was a name conflict thing. If I am using the MFC library
I can use names like Bitmap, Button, View in my code if I want to
because the library only uses names like CBitmap, CButton, CView. I
believe Borland does a similar thing with its GUI development library,
starting all the class names with 'T', and wxWindows uses 'wx'.
Namespaces would be better, but I don't know whether namespaces were
available when these libraries started life.

This all falls down if you decide that starting class names with 'C'
is a really good idea because that's what Microsoft does.

GJD

 

[Rolf Magnus]

(e-mail address removed) (John Dill) wrote in message


<reposting as similar previous message seems to have got lost>

I thought it was a name conflict thing. If I am using the MFC library
I can use names like Bitmap, Button, View in my code if I want to
because the library only uses names like CBitmap, CButton, CView.
I believe Borland does a similar thing with its GUI development
library, starting all the class names with 'T', and wxWindows uses
'wx'.
Namespaces would be better, but I don't know whether namespaces were
available when these libraries started life.

That may be the reason why they are not used. But what does the C in
Microsoft's classes stand for?

This all falls down if you decide that starting class names with 'C'
is a really good idea because that's what Microsoft does.

I thought that Microsoft recommends to do that.

 

[Allan W]

But what does the C in
Microsoft's classes stand for?

"Class", afaict.

I thought that Microsoft recommends to do that.

They do. That doesn't mean it's good advice.
(Name clashes and all that.)