From the Infospheres coding standard for Java http://www.infospheres.caltech.edu/resources/code_standards/java_standard.html
Code standards aren't just about obsession, they are about productivity, professionalism, and presentation. This code standard for Java is adhered to
by the Infospheres Group at Caltech so that our resulting product is more readable, maintainable, robust, testable, and professional.
Many people helped with the evolution of this code standard. These practices were not created in a vacuum. They are tried and true rules that have been used in producing both research and commercial systems by teams of dozens of programmers. While not all the rules are applicable to every developer or all systems, a general adherence to the rules and a belief in software engineering practices often results in happier and healthier developers and systems.
Also consider the following:
After reading Infospheres coding standard, I have lost some of my strong belief in coding standards. ;-) How long time have they spent producing that gigantic document?
Personally, I think TheElementsOfJavaStyle? is pretty much all one needs. I think DougLea's example standards are also good. Infosperes has really gone to an extreme, more of an extreme than I could support. As far as I can tell, it seems to have grown over a long time, so like anything, has picked up a lot of legacy. But this is just a guess, maybe it just looks like it is old.
I wouldn't give up on having ideas just because someone had a bad one. Similarly with coding standards. It seems that the infosphere standard is there in support of lots of people writing code for submission to some kind of publication or library. As such one does need to do more, perhaps, but it's definitely overkill for me. The remarks on wanting 50% comment volume seemed rather retro
, especially since they apparently automate the metric. Weigh the comments - nope, not enough, sorry. But still, the objective, communication, is a good one. And many of the means - perhaps each of the means - helps on that. They just went a bit overboard.
At my company the CodingStandard just consists of the URL to JavaSoft's CodingStandard (http://java.sun.com/docs/codeconv/) and a few additional notes about how to break lines.
With Sun's Code Conventions and the documents about writing documentation comments and API specifications, I don't see much of a need for spending more time on reinventing the wheel and coming up with your own coding standard... OliverKamps
We went overboard mainly because we have folks within the group that do formal specification and tool-building to support such. Meaning, nearly every tag and design rule specified in this standard is supported by a tool (called JPP) that checks for conformance, generates documentation, and generates test code a la DesignByContract
If you do not have support for tools that do such, then most (but not all!) of the standard is overkill, though some have found it useful. E.g. I was asked by the documentation team inside of Ja
vaSoft if they could adopt/modify our standards several years ago - only about a year after that did they come out with their code standard, mentioned above, which does not
include any specification features, which we consider a huge loss. -- JosephKiniry
There is probably a difference between CodingStandard
Practices. I think the document referred covered each of these areas in a single document.