Code formating standards?

I don''t know about standards, but I can give you a couple of tips (sorry i''m too lazy to sit and tihnk of more hehe):

1. What you said is preferred by many but not necessary. The reason is that when you list pointers in a row (ie. int *a, *b), if you put the star next to the type it would screw up the second variable. Sometimes people put the star in between the letter and the variable with a space on both side. This is doable too. It''s all up to you.

2. Make your IDE set indents to 3/4 spaces, NOT TABS. tabs just make everything more difficult in the long run, trust me. They are too variable depending on the system. Any industry company should will use the same format.

---
Brent Gunning | My Site

There''re about as many coding standards as there are programmers (maybe more). There are only two rules that are important when it comes to coding standards:

1) Be consistent (but not to the extent that it makes code unreadable, that defeats the purpose)
2) Use the standard used by the rest of the project (even if you strongly disagree with it)

My 2p:

1) Beg/buy/borrow a copy of Code Complete
2) Read it a couple of times


As already mentioned, practically every company, and even every individual has their own code formatting style.

Some common guidelines actually have benefit, most don''t. If you''re setting a standard for a team, don''t make it too fussy about the things that don''t have any benefit apart from what YOU think looks best.


Code Complete will guide you through this issue.

http://search.yahoo.com/bin/search?p=c%2B%2B+coding+standard&ei=UTF-8

The company I work for has a few simple standards: ''tabs'' are 3 spaces, use a type prefix on variable names(mostly hungarian but a few that aren''t), prefix member variables with m_, parameters to functions with p_, globals with g_, braces go on their own lines even with the declaration/conditional/loop, always put braces for contidionals/loops, class names start with C, cammelCase for variable and function names, ALL CAPS for constants, and there are a few ''guidlines'' on the maximum number of lines in a file.

ves: eek - the first link doesnt even mention using _ after g, m and p!!!

There are a couple of well-known standards such as K&R, camelBack, etc, but some programmers don''t like some parts of these standards, so they invent it on their own and mix them.

Extrarius'' company is a good example.
prefixes like m_, p_, g_ come from Hungarian notation.
cammelCase for variables and functions is camelBack notation.
braces go on their own lines come from...somewhere else (K&R standard says braces should go along with the function name etc).

Isn''t it kinda sad that there''s no standard? I mean, some source looks like heck while others are easy to read. Or atlesat it could be a couple of standards to choose from. Hmm.. maybe one should spend some time in coding a codeformatting program... Just specify which files to correct and push a button, out comes clean code. Can''t be THAT hard, can it?

____________________ ____ ___ __ _
Enselic''s Corner - My site. Go test my game Spatra and see if you can beat it onto the Official Spatra Top 10. (source available)
CodeSampler.com - Great site with source for specific tasks in DirectX and OpenGL.

quote:

---

Original post by Enselic
Isn't it kinda sad that there's no standard? I mean, some source looks like heck while others are easy to read.

---

If you pick a standard (almost any standard) and stick with it, your code will look nice. There's two cases where code starts getting messy:

1) Using multiple styles in the same project
2) Never straying from the standard even when the standard makes things worse

quote:

---

Or atlesat it could be a couple of standards to choose from.

---

There are a couple major standards, it's just that people generally don't entirely agree with any one standard.

quote:

---

Hmm.. maybe one should spend some time in coding a codeformatting program... Just specify which files to correct and push a button, out comes clean code. Can't be THAT hard, can it?

---

Like indent? (http://www.gnu.org/software/indent/)

[edited by - Way Walker on July 16, 2003 2:24:13 AM]

quote:

---

Original post by Anonymous Poster
But one can''t avoid that. As soon as you use two APIs, you''ll be using two styles with 90% certanity. And they can be two clearly distinguishable styles indeed; One of the APIs might use error codes while the other one uses exceptions. One of them relies on C style, the other one on OO style, or perhaps makes heavy use of templates. And so on... Sometimes one just can''t avoid ugly code, when it depends on external things.

---

I agree, sometimes things can just plain be ugly. If you really want to see ugly, look into your favorite non-C/non-C++ language with FFI. It probably only goes to C, and it probably fairly ugly.

I don''t have a catch-all solution, but I would look into

1) finding libraries that are relatively closely matched (especially if they closely match your style)

2) segregating the different libraries so you''re only dealing with two different styles at a time (yours and the library''s)

3) keeping the multiple style ugliness contained to as few functions/classes/etc. as possible (a few glue functions, maybe a wrapper or two, etc.)

4) trying to be cute (perhaps you would prefer the term "clever"? It would mean the same thing, and is usually a bad thing in programming) in how I fit the two libraries together, such that it looks nice and things seem to just fall into place.

Like I said, no catch-all, but that''s how I''d start my search for perfection.