In order to justify my assertion in that thread I have decided to publish my damn fine standards. So here they are.
APC's Damn Fine PL/SQL Coding Standards
- Your code must implement the requirements correctly and completely.
- Your code must have a suite of unit and integration tests (preferably automated) to prove it implements the requirements correctly and completely.
- Your code must implement the requirements as efficiently and peformantly as possible.
Is that it?
These standards have much to recommend them. They are easy to read. They won't need revision whenever there's a new version of PL/SQL. And they focus on what is really important in code: correct functionality. Of course things such as layout and naming of variables are important, I'm not saying they're not. But a PL/SQL procedure can be neatly laid out, rigourously capitalised and thoroughly commented and yet be full of bugs. In my experience, most coding standards tend to document in tedious detail the things which are easy to standardise - use of upper and lower case, line indentation, etc - rather than the things which actually matter.
Also the strictures of codings standards are rarely revised. I still get handed coding standards which say things like "Always use explicit cursors". So either these standards were written ten years ago or the author has not coded any PL/SQL in the last ten years or the author should be shot. Whichever it is, if the standards document contains such canards, why should anybody pay it the slightest attention?
I intend to expand upon some of these points in future posts. If you want a more regular set of PL/SQL Coding Standards then you should check out the redoubtable William Robertson's site. Alternatively, invest in a copy of Oracle PL/SQL Best Practices by Steven Feuerstein (Whom God Preserve). I don't agree with everything that Steven writes but I firmly believe that if every PL/SQL coder in the world followed these guidelines the overall quality of the global PL/SQL codebase would increase by several orders of magnitude.
Update
The troll has now reverted to an anonymous userNNNNNN handle and restored the original text. Obviously even they have got tired of the joke. Or been stricken by conscience.
6 comments:
I like your's better than mine. More simple and more concise.
I need to get to that zen like place you seem to have found with regards to standards...;)
Your standards make no mention of completing the code on time nor on budget. Is that on purpose?
In reality, I have found that managers have preferred decent code be written in X days than clean, efficient, provably correct code be written in X+Y days. (Where X and Y are both positive).
Indeed, I have worked in shops where customers actually pay for the fixes/maintenance, so managers actually get quite grumpy if the code is perfect.
Comments?
Maybe add one more.
4. Code will be reviewed by a colleague/peer to confirm the above.
For quality code, review beats standards anyday.
Especially when they say "Always use explicity cursors"...
Regarding standard no. 2. Aren't they called "users".
Interesting to see what other people think is truly important.
Delivering on time and to budget definitely belongs to the realm of project management. Partly because it applies to any project deliverable not just PL/SQL programs. Partly because it depends on what method the project uses - does it slip time, features or (as your managers might prefer) quality? And partly because these things are negotiable: some bugs can be lived with, others are showstoppers.
Similarly code reviews are usually about policing adherence to the coding standards. As such they are in the realm of QA and so ought to be in the release management procedures.
This is not to say that these things are not helpful. I just don't think they ought to be in coding standards.
Besides, three is a magic number.
Post a Comment