I have worked for software test tool vendors for many years -- still do, in fact. Most companies buying these expensive offerings work in a safety-critical sector, so they are looking to adhere to the kind of standards that earn them the right to sell their wares in the appropriate markets.
Many of these standards are process based. They lay down a development process to be followed for the whole application from beginning to end, and they generally include variations on their demands depending on the application's criticality or components. Examples of these process standards include ISO26262 in the automotive industry, IEC61508 in the process industries, and (perhaps the grandaddy of them all) DO-178 in aerospace.
Then there are coding standards: sets of rules that limit the syntax, constructs, and functions normally available in a high-level language such as C or C++ to avoid those most likely to give rise to error. Historically, most of them have been concerned with safety (the MISRA standards are perhaps the best known), but more recently, standards such as CERT C have applied a similar approach for those more concerned with software security.
Coding style is something different. It is not especially concerned with which parts of the languages are used. It focuses more on what the code looks like when it is completed. What is legible to some is incomprehensible to others, and style preferences can become ingrained over many years and defended with almost religious fervor.
Some even take pride in making their code as illegible as possible. It is hard to imagine a defense for that stance in a commercial environment, but the existence of the International Obfuscated C Code Contest supports the idea that writing illegible code can be an attractive brain teaser for some. (Check out Ian Phillipps' "12 days of Christmas" winner from 1988.)
One of the most notorious variations concerns the positioning of curly brackets. My background from too many years ago was in Pascal, which uses begin and end instructions to define the scope of a block of code. That is probably the reason I much prefer the first of these two programs to the second.
If I find it much easier to work with the former format, why shouldn't I? And why shouldn't my colleague follow her own preferred route? Surely we will all do a better job if we follow the paths we feel most comfortable following.
The standards themselves lay down little in terms of style. DO-178B merely suggests the use of "Source code presentation standards, for example, line length restriction, indentation, and blank line usage" without mentioning the aim of doing so. Just what is required? Where do we stop? How pedantic should we be?
MISRA C:2012 is a little more helpful. It reads:
It is recognized that a consistent style assists programmers in understanding code written by others. However, since style is a matter for individual organizations, MISRA C does not make any recommendations related purely to programming style. It is expected that local style guides will be developed and used as part of the software development process.
In other words, there is nothing wrong with either of the "Hello World" programs. Both layouts are defensible and logical, but each is acceptable only if that style is used throughout a project or an organization. If I don't like the format of the second example, and it takes me a little time to get used to it, that is a small price to pay for the ability for any developer to pick up any code from the project and understand it without having to struggle with an unfamiliar layout.
As long as it exists, then, the detail of programming style doesn't matter at all. It is the consistency of style that is all important.