in reply to Documenting Methods/Subs

I think this is largely down to personal preference, but that whoever's going to be reading the code has a very large influence on the decision.

I'm in the habit in the shop I work at of not commenting subs, unless they're very long and it's not obvious from the name or the routine itself what they're doing. Having said that, though, at my Uni it's expected that all subs are commented in depth, and I therefore do commment them there.

It's normally a fairly safe assumption (in my mind) that someone working at the same place you do, with a grasp of what's going on with the system and what the script as a whole should do can figure out what a specific sub is doing (especially if it's well-named).

I guess it depends on the people you work for (or are coding for, in the case of Uni) too .. and on their coding standards (or lack of) .. how much of a personal choice you get then is very much controlled by that.

Just a few quick thoughts ..
-- Foxcub

Replies are listed 'Best First'.
Re: Re: Documenting Methods/Subs
by krujos (Curate) on Jan 10, 2003 at 17:31 UTC
    One of the things to remember, epically about the work place is that it costs other people time ( and the company money ) to have to go through a sub that is not commented. Just to figure out if it does what you want. When many people work on a project, epically a complex one that is potentially days of man-hours wasted because the original developer didn't feel it was important (or just plain didn’t think about it) to comment his sub. This can also lead to other things like many subs doing the same task (because other people didn't want to figure out the code) etc... As ridiculous as this sounds, I have run into it several times at my current job.
    Sorry one of my pet peeves is not commenting code other people will be using.
    Josh