Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ Programming Style

Reply
Thread Tools

C++ Programming Style

 
 
crea
Guest
Posts: n/a
 
      03-30-2011
Is this a good c++ style guidance:
http://geosoft.no/development/cppstyle.html

I am trying to change my style to be constant.


 
Reply With Quote
 
 
 
 
peter koch
Guest
Posts: n/a
 
      03-30-2011
On 30 Mar., 09:50, "crea" <(E-Mail Removed)> wrote:
> Is this a good c++ style guidance:http://geosoft.no/development/cppstyle.html
>
> I am trying to change my style to be constant.


It can not be recommended. A short glimpse reveals several errors -
the first one being, that constant identifiers should be all uppercase
(eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
come from Java?

/Peter
 
Reply With Quote
 
 
 
 
crea
Guest
Posts: n/a
 
      03-30-2011

"peter koch" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 30 Mar., 09:50, "crea" <(E-Mail Removed)> wrote:
>> Is this a good c++ style
>> guidance:http://geosoft.no/development/cppstyle.html
>>
>> I am trying to change my style to be constant.

>
> It can not be recommended. A short glimpse reveals several errors -
> the first one being, that constant identifiers should be all uppercase
> (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
> come from Java?


I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
normally. And I think many libraries use that style as well? also #defines.
Like when I used Nokias TETRA class. YOu dont think its usual?


 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      03-30-2011
On Mar 30, 10:41*am, "crea" <(E-Mail Removed)> wrote:
> "peter koch" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> > On 30 Mar., 09:50, "crea" <(E-Mail Removed)> wrote:
> >> Is this a good c++ style
> >> guidance:http://geosoft.no/development/cppstyle.html

>
> >> I am trying to change my style to be constant.

>
> > It can not be recommended. A short glimpse reveals several errors -
> > the first one being, that constant identifiers should be all uppercase
> > (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
> > come from Java?

>
> I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
> normally. And I think many libraries use that style as well? also #defines.
> Like when I used Nokias TETRA class. YOu dont think its usual?


No, the use of uppercase is reserved for macros.

Furthermore "#defines", as you call them should not
be used to define constants. For this you have the
keyword "const". If libraries use this style, they must
be quite dated (or perhaps they are not c++ libraries).

Kind regards,

Werner



 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      03-30-2011
On 30 Mar., 10:41, "crea" <(E-Mail Removed)> wrote:
> "peter koch" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> > On 30 Mar., 09:50, "crea" <(E-Mail Removed)> wrote:
> >> Is this a good c++ style
> >> guidance:http://geosoft.no/development/cppstyle.html

>
> >> I am trying to change my style to be constant.

>
> > It can not be recommended. A short glimpse reveals several errors -
> > the first one being, that constant identifiers should be all uppercase
> > (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
> > come from Java?

(should be const int above).
>
> I actually personally like that MONTHS_PR_YEAR . I ve been doing that myself
> normally. And I think many libraries use that style as well? also #defines.
> Like when I used Nokias TETRA class. YOu dont think its usual?


The consensus is to use all-uppercase for defines and nothing else. I
don't know Nokias TETRA class and a quick google did not help, but the
libraries that I am familiar with do not use the constants must be all-
upper mentioned in you link.

/Peter

/Peter
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      03-30-2011
On Mar 30, 9:50*am, "crea" <(E-Mail Removed)> wrote:
> Is this a good c++ style guidance:http://geosoft.no/development/cppstyle.html
>
> I am trying to change my style to be constant.


I like it. But then again, I like all conventions. To me, what's far
important than the convention itself is that code sticks to it.

Nitpicks: I prefer NULL over 0 for pointers (it sticks out like a sore
thumb); I don't mind shortening command to cmd or initialize to init;
exceptions are generally caught by __const__ reference (point 81).

Goran.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      03-30-2011
On Wed, 2011-03-30, peter koch wrote:
> On 30 Mar., 09:50, "crea" <(E-Mail Removed)> wrote:
>> Is this a good c++ style guidance:http://geosoft.no/development/cppstyle.html
>>
>> I am trying to change my style to be constant.

>
> It can not be recommended. A short glimpse reveals several errors -
> the first one being, that constant identifiers should be all uppercase
> (eg. int MONTHS_PR_YEAR = 12). This is plain wrong - did the author
> come from Java?


I don't think you can call it "wrong". Their rationale is wrong, though:

"Common practice in the C++ development community."

Personally I do it that way too, but I'm aware that most people on
c.l.c++ don't (and you can end up in a flamewar by arguing for it.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
osmium
Guest
Posts: n/a
 
      03-30-2011

"crea" <(E-Mail Removed)> wrote in message
news:hhBkp.816$(E-Mail Removed)2...
> Is this a good c++ style guidance:
> http://geosoft.no/development/cppstyle.html
>
> I am trying to change my style to be [consistent].


I just skimmed it and I like it, about 100 style guidelines. If one is going
to wait for a perfect style book, one is going to wait forever.


 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      03-30-2011
On 3/30/2011 12:50 AM, crea wrote:
> Is this a good c++ style guidance:
> http://geosoft.no/development/cppstyle.html
>
> I am trying to change my style to be constant.
>
>


There are many common C++ practices in the "community". Camel case is
far from the most popular. In fact, using it can get you into trouble
if you're coding on windows systems.(1,2,6,etc...)

The all-caps constants thing has been beat to death already.

Requiring single letter template parameter names is just plain ****ing
stupid. REALLY ****ing stupid. (

Requiring variables to be named exactly the same as their type is also
really ****ing dumb. (12)

Although regarding the example I'd probably agree, the reasoning behind
15 is only true because they're already being dumbasses via 12.


Getters and setters are smelly. That this group has an actual naming
convention for them is dubious. Requiring get/set as prefixes is just
silly, especially since C++ does overloading.(17)

Using i,j,k,etc.. for iterator value names is a questionable practice.
Many people do in fact do it, because it's just easy and fairly well
recognized, but its a lazy practice and should certainly not be
recommended/required by a team style guide. Quite frankly, if you find
yourself using more than just 'i' then you need REAL names for your
iteration variables. (25)

Everything about #33 is insane.

I totally disagree with the examples in #39. COMMA FIRST!

function( param1
, param2
, param3 )

If you're going to split, do it. Don't mix and match; it's much harder
to read.

The exception to #46 should not be allowed.

#47 should certainly be followed and should go without saying.
Unfortunately on some teams it does not.

#57 is dumb. If you have to scroll down to reach the while in a
do-while then other, more important practices are not being followed
(keep things short by factoring into smaller functions).

#60 is just silly.

All in all this is a terrible style guide. There are some good bits in
it but too many bad bits and the entire thing is more about formatting
than about real, important issues. For example, a good style guide
would say something like:

"Always assign new pointers to RAII objects immediately and on a single
line by themselves. Example:

std::auto_ptr<x_type> x(new x_type);
std::auto_ptr<y_type> y(new y_type);
function(x,y);

// NOT function(std::auto_ptr<x_type>(new x_type), ...);"

Things like this actually effect the *functionality and correctness* of
code (works around unknowable order of parameter execution in this
case), which any good style guide should have as its main focus. This
guide of yours doesn't even have a single item like this in it.

This entire guide that you're linking to violates item 0 of "C++ Coding
Standards" by Sutter & Alexandrescu (a GOOD style guide): Don't Sweat
the Small Stuff. Almost 100 items of mostly crap because they're too
worried about whitespace. The entire thing could be summed up in one
rule: "Make your ****ing code make ****ing sense to human ****ing beings!"

--
http://crazycpp.wordpress.com
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      03-30-2011
On Wed, 2011-03-30, Noah Roberts wrote:
> On 3/30/2011 12:50 AM, crea wrote:
>> Is this a good c++ style guidance:
>> http://geosoft.no/development/cppstyle.html
>>
>> I am trying to change my style to be constant.


....

> I totally disagree with the examples in #39. COMMA FIRST!
>
> function( param1
> , param2
> , param3 )


Are you serious? Even if you use that style yourself, surely you know
almost noone else does?

....
> All in all this is a terrible style guide. There are some good bits in
> it but too many bad bits and the entire thing is more about formatting
> than about real, important issues.


Let me put it this way: there are too many weird things in there; if
the OP starts following it he'll write code which looks weird. I think
most people here agree that many of the things the guide calls "common
practice" aren't common.

(And in a sibling page about using GNU make to build Java code, they
show a shell script written in /bin/csh. Those guys *are* weird.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DataGrid header style inconsistent with sortable column style cedoucette@alum.rpi.edu ASP .Net 0 10-14-2005 12:13 AM
All style tags after the first 30 style tags on an HTML page are not applied in Internet Explorer Rob Nicholson ASP .Net 3 05-28-2005 03:11 PM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM
Javascript Style Switcher that remebers current site style in use Hardeep Rakhra HTML 8 01-15-2004 08:00 PM
Style sheets, include one style within another (not inheritance) foldface@yahoo.co.uk HTML 1 11-24-2003 01:37 PM



Advertisments