We are developing embedded software for an automotive product in ANSI-C in a large team. Yesterday, in our regular code review, we had a general discussion about the style of our code. We have a coding guide line (roughly 30 pages), which mainly ensures certain required practices and besides that treats hungarian notation, level of indentation, newline strategy for code blocks etc.The discussion yesterday was about, whether there should be more detailed guide lines for how the code is formatted. Example declarations:int int1,    int2 = 0;short short1;long_type_name_defined var1;const * type var2;type const* var3;One colleague had the opinion, that there should be a clear guideline of how to consistently align the variables (e.g.: spaces up to longest regular type), whether or not there should be spaces between * and type / qualifier, where the qualifier is located, whether or not to use the , operator etc. Things which could be somehow declared as a matter of personal taste.Pro: increased readabilitybetter to understand for externals (who are new to the code or typically not dealing with it)Con: because it is somehow a matter of personal taste, what increases readability for one person, could decrease it for another (?)might be hard to clearly definestyle rule set would be enlarged a lota lot of work to always follow a large rule setThe main question is somehow: Does it really help to have a very specific rule set? We could not find a clear consensus about that. A style guide should increase the readability/maintainability of code, so there will be some optimum between size of the rule set and beauty of the code (?).I would like to get your opinions about where this optimum is.
What is a reasonable level of detail for a style guide?
c;coding style
Does it really help to have a very specific rule set?No. Quite frankly, no. Or, to put it more constructively - take a look at any source code off github or sourceforge, can you read tit? If the answer is yes then you've just demonstrated that a single style is not important for readability. What does help readability is readable code, which may sound daft, but is often very simple to describe without extensive rules - judicious use of whitespace, indenting and blank lines make code readable. Cramming everything together to use as few keystrokes as possible is the antitheses of readable.What I have found is that extensive style guides simply don't get followed. 30 pages is nuts - you have to spend more time figuring out if you're following the guide than learning the code! And then so does everyone who reviews code, and even then people will just miss parts. (though it can be satisfying when the most ardent advocate of the extensive style guide gets his own code wrong)The best guide I've ever seen simply said make sure your code looks the same as the code you're working on. That's easy to follow, and its obvious where you get things wrong- they stand out as being different. It doesn't matter what the original style used was, as long as its consistent. Now, for 'externals': style guides don't help here. Who cares how many spaces you put in front of a variable declaration? Such trivialities do not matter. What does help though is layout - if declarations are always put at the top of a function or class, then your newbies will know where to look to find the variables. If the file naming convention has some rules, then they will easily be able to find the UI code as it'll always be in a file called customerUI.c (say). Little things like that matter far more than any amount of style. You could say structure is what the standards enforce, style just needs to be of a minimum standard