This just sounds like the basic skill required for properly documenting any code but slightly extended. The comments should explain the What and Why. You can read the code for the "How".
My rule of thumb is that if you remove all of the code, you should be able to create a functional flowchart from the comments that remain.
In fact, that's how I start most of my code. I'll write the comment to explain to myself what I'm trying to do before I write the code. Yep... there are times when you have to change the comments because you changed your mind. If you're prone to it, stop using that silly excuse as a reason to avoid comments. Just do it. It's a part of the job.
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.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)