Prefix Name Function Question

[Immortal Nephi]

I look at several function names. Some programmers prefer to
capitalize first letter of the function name in either class or
struct. Some others prefer not to capitalize on any global functions.
Which preference do programmer choose to name function?

For example

class CRect
{
public:
CRect() {}
~CRect() {}

void CopyRect() {}
void DrawRect() {}
};

// global
void copyRect() {}
void drawRect() {}

 

[Victor Bazarov]

I look at several function names. Some programmers prefer to
capitalize first letter of the function name in either class or
struct. Some others prefer not to capitalize on any global functions.
Which preference do programmer choose to name function?

For example

class CRect
{
public:
CRect() {}
~CRect() {}

void CopyRect() {}
void DrawRect() {}
};

// global
void copyRect() {}
void drawRect() {}

If I may ask, what difference does it actually make? Style is something
you choose and *follow*. The mantra is "whatever style you choose, just
be consistent: use it".

V

 

[Alf P. Steinbach]

* Daniel T.:

daniel_t's three rules of style:

Rule 1: when modifying code that is already written, follow the style of
the existing code. Your changes should be undetectable, style wise.

Rule 2: when working as part of a team of programmers, or in a company,
follow the guidelines of the team or company, except when following this
rule would force you to break rule 1.

Rule 3: use whatever style you want, except when following this rule
would force you to break rules 1 or 2.

If these are Daneel's rules, where's rule 0? <g>


Cheers,

- R. Alf

 

[James Kanze]

If I may ask, what difference does it actually make? Style is
something you choose and *follow*. The mantra is "whatever
style you choose, just be consistent: use it".

Up to a point. Microsoft uses the C prefix for its classes, so
user code should avoid it---with namespaces, there's really no
point in using a prefix at all. And there's some objective
argument in favor of distinguishing type names from other names
(although it's probably not strong enough to justify changing
existing practice, if you already have an existing body of
code). And I'm not sure about the wisdom of distinguishing
between free functions and member functions. (It's a new enough
idea that I'll have to think about it. But in practice, I
rather think that the name itself and the arguments the function
takes should make it clear.)

Beyond that, of course, there are a number of perfectly
reasonable conventions, and which one you choose IS purely a
matter of taste.

 

[Pascal J. Bourguignon]

daniel_t's three rules of style:

Rule 1: when modifying code that is already written, follow the style of
the existing code. Your changes should be undetectable, style wise.

Rulel 1: when modifying code that is already written in a bad style,
follow your style. In time, you will have modified all the code and
it will have been reformated to your correct and better style.