Thanks for all the replies. Glad to see that there is ageement

They say the devil is in the detail, now here is the situation with all the information. I have been commenting as most have been saying - example taken from production server:-

/*

Stuart 27/6/2012

This proc should update the employee table with any changes,

add any starters and flag the leavers

*/

Anything that I have had to look at more than once, I will put a "reminder" comment

-- only looking for "live" job codes

However, I have been told that this level of commenting does not provide enough information "for someone with my skill level" (direct quote from person tasking me with this project) to understand the code. I have been told that the following is the standard that I should be commenting as this (this is genuine production code):-

/*

/****** Declare the variables******/

DECLARE @Param1 VARCHAR(20), -- this holds the employees reference number

@Param2 INT -- this holds the employees department

@Param3 smalldatetime -- this will be the run time of the import

-- held against the record

/****** Remove any old entries from the staging table ready to import all

the current values******/

truncate table P_WBS_Actual_Key

*/

Someone with "my skill level" would know that the keyword declare leads to some variable being declared, the first comment is therefore redundant. Equally I would give the parameters meaningful names avoiding the need for the comment next to them. I would also like to think that the Truncate table statement should be self explanatory to any one who is let loose on a production SQL server. We have therefore less useful commenting in the version that is preferred :w00t:.

OK - rant over. It just grates with me having to conform to a pointless standard - the raison d'etre of the stored proc can be ignored and yet all comments are "good".