If it's alright, I was wondering if some of you could share with me the policy on the conding standards of the company you guys work for. Example would be...
1. Use typedef for all data types
2. Use the following block style[code]void foo() {
... }
3. Capitalize the first letter of a function
4. No Hungarian notation
5. And so forth...
I've read the general coding standards
but I'm far more interested in hearing from all the working professionals here,
so that in the future when I get a job, I'd be better prepared.
My company doesn't have a single monolithic set of coding standards, but there are guidelines within some specific projects.
Personally when I'm working with existing code I just follow the extant style, and when I'm writing my own I impose my preferred style. Really not a fan of your #2 incidentally.
IMPO, Braces should be on their own line 99.5% of the time. The other 0.5% it may be acceptable to put the entire "construct" on one line:
Code:
void foo() { return 1; }
This is typical when there are many of the same time sequentially in the file...
TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!) 2008, 2009 In theory, there is no difference between theory and paractice; in practice there is.
* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first
The most important thing is: Think through every function you add to an interface completely. If knowing how to use it requires any understanding of the internal implementation, you're doing it wrong.
This is one I find very interesting. Consider how many class names there are and the FLA's (First Letter Acronyms) and other abbreviations regulrly clash.
For example what your use you for variables of the following types:
I would find svspidData and svspdiData to be very confusing to refer to the last two types...
TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!) 2008, 2009 In theory, there is no difference between theory and paractice; in practice there is.
* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first
For example what your use you for variables of the following types:
I think that it depends on which variant of Hungarian notation is used. Joel Spolsky points out in Making Wrong Code Look Wrong that Simonyi's original Hungarian notation concept was concerned with the semantics of the variables, not their types as declared in the program. I tend to be more sympathetic towards this "Apps Hungarian", although I still do not understand why such an encoding is really necessary when spelling out the word would be easier to read for those uninitiated to the abbreviations.
C + C++ Compiler: MinGW port of GCC
Build + Version Control System: SCons + Bazaar
I know in some cases its forced on us if you program in MFC or win32 but even then I'd only use it the absolute minimum you can get away with.
Get Microsoft Visual C++ Express here or CodeBlocks here.
Get STLFilt here to radically improve error messages when using the STL.
Get these two can't live without C++ libraries, BOOST here and Loki here.
Check your code with the Comeau Compiler and FlexeLint for standards compliance and some subtle errors.
Always use [code] code tags [/code] to make code legible and preserve indentation.
Do not ask for help writing destructive software such as viruses, gamehacks, keyloggers and the suchlike.
I think that it depends on which variant of Hungarian notation is used. Joel Spolsky points out in Making Wrong Code Look Wrong that Simonyi's original Hungarian notation concept was concerned with the semantics of the variables, not their types as declared in the program. I tend to be more sympathetic towards this "Apps Hungarian", although I still do not understand why such an encoding is really necessary when spelling out the word would be easier to read for those uninitiated to the abbreviations.
Even semantic usage gets a bit complex to say the least...
I find that the vast majority of the time simply hacing the class name in ProperCase a local variable with the exact same name in camelCase is sufficient.
For "Collection" classes, I tent to end with the Collection Type (CarList, StateMap, etc) variables can then simple be plural)
(psuedo code)
Code:
CarList cars;
foreach (Car car in cars)
{
}
TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!) 2008, 2009 In theory, there is no difference between theory and paractice; in practice there is.
* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first
IMPO, Braces should be on their own line 99.5% of the time.
Originally Posted by GCDEF
Code:
void foo()
{
//code
}
So you also write
Code:
if (a==b)
{
foo();
}
else
{
bar();
}
?
And you find that easy to read?
More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity. --W.A.Wulf
Premature optimization is the root of all evil --Donald E. Knuth
I used to use hungarian notation a bit. It is flexible. I like the idea of including scope into variable names to avoid confusion between locals and members. Globals should be within a namespace at the very least which helps to clarify when using the '::' operator to indicate where the variable is located. It gets a bit ridiculous when you try to include type info into the variable name.
Bookmarks