We find style guides concerned with whitespace and capitalization merely a distraction not worth spending much time on, other than as suggestions. Almost anything that can be applied automatically with a simple filtering program is generally not worth more than that.
The most important thing to do is to ensure the code is standard-conforming and as clean of unused variables and dead code as possible, and not numerically sensitive. The compilers (this varies widely) can be your best asset here. Non-standard usage should only be accepted if explicitly reviewed as neccessary; code should contain a certain amount of comments; user and developer documentation and test cases (hopefully verified with a coverage tool as being thorough) are important. Some type of indentation, a measure of how descriptive variable names are (but do not discourage use of short names in complex mathematical expressions, so if names appear in long lines allow for them to be short); and reducing the use of deprecated features are all important.
Deciding whether to indent one or four characters or keep to an 80-column width for source code; and whether you have a space between end and if wastes programmers time and just irritates people.
If it really bothers someone, buy something like SPAG. Utilities like that allow you to specify almost all the formatting options but also allow for refactoring older code, a much more valuable pursuit for those dealing with legacy software.
Descriptive coding can be good but becomes horrible to read when done religiously with complex formulas. Some people believe their code is so readable it does not need comments. They are wrong. Comments including references should be required. It is trivial to remove comments; most editors can be set to make them invisible or fold them. It is very hard to automate adding them.
As an aside, one of our recruiters told me he brings this topic up and if someone is avid about rigid stylistic standards that do not affect performance he considers it a major negative. If they talk about readability, reproducibility, verification, … then he considers it a plus. If they do not believe they should have to pass any criteria or have their code reviewed at all, a big negative.
So as with most things, it is a balancing act. Provide guidelines but policing non-functional ones
is not particularly productive, and there is no single answer anyway. If I want my code viewable on a phone display on some web forum it should probably be terse and narrow and use minimal indentation. If I want someone to use long descriptive variable names I should then expect long code lines.
My personal tastes are to always indent, but more than three characters reduces readability; to always have a closing name on an end statement; and that putting a space in between endif and elseif is ugly. I work with someone that thinks endif and elseif are horrors that the compiler should reject, capitalizes standard keywords and indents eight characters. We get along great because we learned long ago though a lot of experience that it does not matter, and is no more important that what your favorite flavor of ice-cream or color is.
Have your developers develop with every compiler warning flag you have; tests should include running with high optimization and justifying if incorrect results are produced; train them on how to generate test cases and the perils of floating point computation. As part of the review process have them provide everything someone else needs to build the code; … throw in styling suggestions but do not make it into a Holy War.