Talk:C++ Programming/Programming Languages/C++/Code/Style Conventions

25x80 related to 0 means success
There should be some clarification on how these two rules are related:

"This recommended practice relates also to the 0 means success convention for functions, that we will cover on the Functions Section of this book."

I suspect the original author was implying that short functions generally encourage having only one exit point, but this relationship is not very clear from the text itself (and furthermore, "0 means success" and "one exit point" seem like notably different rules to me). If someone wants to revise the text to clarify this relationship, please do so; otherwise, I'm tempted to remove it to avoid confusion.

--Autumnfields (talk) 11:13, 30 November 2010 (UTC)

Links to Style Guides
I've edited the introduction with links to style guides, and the got the following reply: Max 22:45, 25 September 2005 (UTC)

if in place of adding references to other pages (your last edits on Conventions (Source Code Style)), we created a section on Code Style pages in the external the references and point to it ? PS: Some of them are of C and Java ?!?

Ok, I guess you're right, the links should not go here, but in the reference section. However, the most comon styles should still be named here.

As for they are in C and Java: Yes, unfortunately they are for C and Java, but they are still the most widely used. (at least K&R, GNU and Java). Do you know of any equivalents in c++? --Max 22:45, 25 September 2005 (UTC)

Bjarne Stroustrup's C++ Style and Technique FAQ http://www.research.att.com/~bs/bs_faq2.html

The C++ Style Sweet Spot A Conversation with Bjarne Stroustrup, Part I by Bill Venners http://www.artima.com/intv/goldilocks.html

KDE Binary Compatibility Issues With C++ http://developer.kde.org/documentation/other/binarycompatibility.html

C++ portability guide version 0.8 originally by David Williams, 27 March 1998 http://www.mozilla.org/hacking/portable-cpp.html

Programming in C++, Rules and Recommendations FN/Mats Henricson and Erik Nyquist Copyright © 1990-1992 by Ellemtel Telecommunication Systems Laboratories http://www.chris-lott.org/resources/cstyle/Ellemtel-rules-mm.html

Wildfire C++ Programming Style With Rationale by Keith Gabryelski http://www.chris-lott.org/resources/cstyle/Wildfire-C++Style.html

Musings on Good C++ Style (Technology) By GoingWare Fri May 10th, 2002 at 03:08:38 AM EST http://www.kuro5hin.org/story/2002/5/9/205040/3918

there are more I have one that is very good but it's in PDF and I can't remember were I've put my copy or were did I get it... most can be mined without infringing copyright by simply changing the wording and simplifying, see the talk page on how to avoid abusing (and the limits of) copyrights, other we can contact the authors and get a license to use them I have done so as time allowed on some of the works I've added references, I've kept the emails so to have proof if any problem arises. see also my urls on my page (del.icio.us) btw if you also have a url page I would like to "monitor" it :) --Panic

Just looked at these links. They are all nice, but most of them go into a different direction. When I talk about coding style (especially to beginners), it I mean indentation, naming, comments, things like that (just as are on the page). Stroustrup recommends K&R style (and so do I :) ).

Here's an idea: We mention coding styles, give the list in the reference section, and during the explanation, recommend to use K&R style (maybe as a note: We will recoomend K&R, and then another note: We recommend using 2 chars as indentation), but emphasize that persistence is the most important key. --Max 20:37, 26 September 2005 (UTC)


 * I would instead call that "formatting" which is only a minor piece of style. (To me, style implies more questions like: how are things communicated, what gets communicated, what doesn't get communicated?) I go with mostly K&R, except I put the "else {" on its own line instead of sharing it with the "then"s close curly (as in "} else {") --MShonle 20:46, 26 September 2005 (UTC)

We should agree that we will never agree about the content of this section we should just say what can be done and leave it to the users interpretation, focusing in, as Max said on the persistence and common agreement,(ie:I could comment code in Mandarin if I would be the only reader), I don't think we should try to sell our tastes or interpretation today that is pointless there are code beautifiers out there, it's like debating the use of tabs or spaces, just pointless, spaces should be used as most of today editors will convert them easily to tabs, another point is the divergence with the use of single char vars names (i,z etc) they can lead to var shadowing and in "running code" (not optimized) can be very hard to find the problem.--Panic 22:55, 26 September 2005 (UTC)

C style comments
I wanted to change this coloring is awful:

int function /* This is a comment /* {              return 0; }             and this is the same comment */ so this isn't in the comment, and will give an error*/ The "isn't" starts a red line for some reason, is this a wiki issue? 203.214.123.244 (talk) 13:21, 19 January 2010 (UTC)


 * I've opened some time ago a similar bug report also on the code highlight filter that Wikibooks use (at sourceforge) IIRC this was not the same bug you have detected now. Go to Reading room/Technical Assistance and ask where to place the bug report (I can't remember the project's name). Thanks for detecting and reporting it. --Panic (talk) 02:10, 20 January 2010 (UTC)
 * So when I stumbled upon this page 8 years later this problem still hasn't been resolved yet?--140.180.246.217 (discuss) 20:52, 1 June 2018 (UTC)
 * I believe so but I haven't contributed or edited any code for more than a year now. A greater problem is that source code in Wikibooks is very prone to vandalism or introduction of errors, as only a small subset of editors may understand the content and even a smaller one would be inclined to check each edit. I proposed sometime ago a source code protection for only register editors with the review flag but I guess no one cared about to address the issue also. --Panic (discuss • contribs) 05:31, 2 June 2018 (UTC)