I have (in my personal projects) the conventions to use camelCase for private member functions, and CamelCase for public ones. At one point in the past, I actually used CamelCase to indicate "void" functions and camelCase to indicate "functions that return something".
The key is consistency within the project, however, rather than some random "I felt like doing it this way today, and tomorrow I will do it differently".
On a professional level I have worked in all sorts of environments - camel-case, no camel-case, underscore to separate parts of names, no underscore, prefix to indicate types or belonging, etc. That's what you get from 20 years of working in programmer/software engineering type jobs... :-)
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Well played. I see you pulling some fancy moderator style topic shifting. Which is peculiarly administrative for a non-moderator.
I like camel-case for the most part. Though as you and others have mentioned really the project is what should drive the convention you use, not what you think looks best. Afterall, camel-case does not seem too visually appealing when the rest of the project uses underscore separation.
On my current project (not mine...), I'm forced to use CamelCase for functions, and underscores for variable names :\. Kinda sucks bad.
For example (including a horrid brace style, tabs of 2 & ifs crammed on 1 line);
matsp, does it not annoy you when you have to work with "odd" styles?Code:int FooBarIsCool(int * something_passed_in) { if(!something_passed_in) return 0; *something_passed_in = 20; return *something_passed_in; }
I like tabs of two... But man the if statement issue is a little nasty... Why is that preferred? Or is it just required for one the iff statements have only one line following the condition?
Just for if statements with one line... but it is horrid. I prefer tabs of 3, but meh. I have no idea why it was preferred, the project was started a few years ago when the creator had (less than he does now) knowledge of C. But he says there is too much code to change, which is 90% true .
It's not uncommon to see:
And a lot of "odd" casts. Including casting NULL to other things, eg:Code:int x; (void)FooBarIsCool(&x);
Code:FooBarIsCool((int *) NULL);
Find and replace can do some amazing things.......... I mean wow... In my brutally honest opinion is is significantly less work to have find and replace change all the "if(condition == true) whatever;" than it would be to write code all crazy to begin with. But whatever, sometimes you have to bite the bullet and just bend over in the name of a pay check.
Well, yes, but if you are that bothered by it, it's probably best to remain a hobby programmer (or run your own company, but that's much harder than not being a professional programmer). Unfortunatlely if you want to make money in a longer term, you have to please your employer.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.