21–30 of 33 posts
I love seeing internal documents like this that are used at reputable companies. They're both educational and a fun glimpse into how high-performing teams operate.
http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-Rev-1-Final...
I see the brace goes on the next line, as it should: if(condition) { expression... } instead of the obfuscated form: if(condition) { expression... }
Looking at their example code.... I find there is a lot of problems, duplicated code, large function with many many obvious simpler functions inlined causing lots of local variable pollution. MISRA is another standard that's popular and I've seen a bunch of code developed using this standard. But the problem with style guides, they have lots of points that are very agreeable, but it is all undone if you don't have cl…
There's a difference between style guides, like this, and standards, like MISRA. Style is concerned with the appearance of the code, and is largely subjective. Many languages, like Common Lisp and Java, have got this nailed: the same style is used everywhere. In the C world, there are endless arguments about levels of indentation, the position of braces, etc. Standards ensure that good, safe, coding practices are fol…
https://www.usenix.org/conference/hotdep12/workshop-program/...
He presents a compelling case for why you should use automated tools to check compliance against coding standards (the standards don't do you any good otherwise).
As far as style goes, pipe your code through indent if you have hangups about formatting. That way you can spend your time on issues that are known to be correlated with risk.
Earlier quoted context omitted.
There's a difference between style guides, like this, and standards, like MISRA. Style is concerned with the appearance of the code, and is largely subjective. Many languages, like Common Lisp and Java, have got this nailed: the same style is used everywhere. In the C world, there are endless arguments about levels of indentation, the position of braces, etc. Standards ensure that good, safe, coding practices are fol…
> Style is concerned with the appearance of the code, and is largely subjective. Many languages, like Common Lisp and Java, have got this nailed: the same style is used everywhere. In the C world, there are endless arguments about levels of indentation, the position of braces, etc. I'm struggling with where to first disagree with this. Some style guides deal only with code appearance, but they can also include things…
It actually makes me think that there should be a standardized way for including indentation hints. CL's &body in macros is not nearly enough for any kind of complicated DSLs.
That's minor aesthetics anyway. There are always some degrees of freedom in it, but Lisp has historically much less of those than C-like languages.
*average=*total/*count; /* compute the average */
^ begin comment end comment^
--
As an aside, I'd be interested to see their NodeJS Style Guide too. Any pointers?
How strictly do people writing code have to adhere to styling guides (not just in NASA, but everywhere else too)? I get that coding standards are a good thing and plain-simply following these will produce "readable" and (possibly) maintainable code, but will that make the code any _better/efficient_ ? Though this does catch some "gotchas" in C, like the if-if-else and the #define trap, I wonder if the Code Review inv…
I'm a little disturbed that this doesn't make any mention of when C is even appropriate. I know if I were an astronaut, I'd be concerned about the code running on the vehicle I was on.
Most high-reliability software is still written in C or other languages in the algol family. For the highest level of assurances, often the binary code must be mapped back to the source code (to reduce the chances of a compiler bug introducing errors), and doing so in languages that are higher-level than C becomes problematic. If someone were to formally verify the correctness of a particular higher-level language im…
How strictly do people writing code have to adhere to styling guides (not just in NASA, but everywhere else too)? I get that coding standards are a good thing and plain-simply following these will produce "readable" and (possibly) maintainable code, but will that make the code any _better/efficient_ ? Though this does catch some "gotchas" in C, like the if-if-else and the #define trap, I wonder if the Code Review inv…
It's certainly not efficient reading a patch with a +1000/-999 diffstat, hunting for a one line fix. I've had this repeatedly and it's painful. Anyone that noted the existing style wouldn't have let this happen.
Earlier quoted context omitted.
Tabs really only works easily when everyone's using the same editor settings. Otherwise, it quickly devolves into a mess. Spaces really only works easily when everyone uses an editor that can convert presses of the tab key into some number of space characters. The only solution that works easily in all cases is to flatly refuse to collaborate with others.
> Spaces really only works easily when everyone uses an editor that can convert presses of the tab key into some number of space characters. Could you show me an editor that doesn't do that?