I'm not sure that you're interested but, for me, check lists are uber important when writing code. I'll take a requirements document, draw a process chart of what needs to be done, and the first bit of code that I write are actually in the form of comments in the code as to what needs to be done and why. Not only is it a check list, but it's automatic documentation in the code.
My general rule of thumb is that if you remove all code from something (stored procedure, view, function, whatever), the comments that remain should allow you to rebuild the process flowchart with little other knowledge of the system.
Of course, comments like "Update the Customer table" are stupid and absolutely worthless because it's missing the "WHY". "Give each qualified customer the current bargain discount on their next purchase" (for example) would be a much better comment because it very simply states why that particular section of code exists and in generic enough terms so the comment doesn't need to be maintained for minor code changes.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems