First of all, I'd like to start by saying that this in no way pertains to perl scripts which are written for one's job, where maintainability is key, and where it is necessary to have people changing your code. This argument does not pertain to coding for oneself, where documentation can help the coder visualize how a script will work, or let the coder add code where code is needed, but instead chooses to focus on code that's out to the public. I will make an argument to myself, and we'll see how it comes out to everyone else ;)
I'm going to argue that it's unnecessary to comment one's code, and if anything bad for the reader. It's obvious that commenting code makes the comprehension of code easier, but is it better to facilitate the reader's comprehension of the code, and in doing so facilitate the skipping over pieces of the code, which are well commented, and he/she has no reason to edit? In my opinion, the purpose of distributing perl code is not only to save the new coder time, but also to educate perl scripters. Commenting code sacrifices the educational purpose of code for maintainability and laziness. This is where an argument sprouts in my mind.
Is it better for the new "bearer of the code" to be able to make small hacks that don't really fit into the grand scheme of the code, or would it be better to force this new bearer to read through the code, and make sure he understands what is really happening? One reason I love code obfuscation is that it shows me whether I really *know* a function, if I don't I'll be forced to go to perldoc, and in some cases even ask for help. Another example of this is the
bugtrack, which was created by Adam Siegel. Although I have been writing basic perl scripts for over two years, my understanding of perl had always been rather basic, and I began my coding career in PHP; however, the bugtrack package forced me to learn a lot about perl, and many functions in perl. The package was not commented at all, and when I say at all I mean *at all*. This forced me to re-examine my knowledge of perl, after all, if I couldn't understand what was going on in this package, I wouldn't be able to modify it. My re-examination of that knowledge has resulted in a great affinity for perl, and its' inherant flexibility and robustness.
It seems strange that packages which are not well documented make me work harder, and perl doc more, in order to understand the inner workings, than packages which are well documented, and should be easy to "hack up"; however the packages which aren't well documented have made me learn much more than any well-documented package could ever do, as perl coders have a tendency to oversimplify their explanations, and not include the flexibility of functions, or how else a function could be used. This forces me to question whether it's necessary or right, for that matter, to document our code in a version that is open for the world. This facilitates people hacking up the code, or making crude hacks to the code, which would not happen if they actually examined the purpose for the code.
Gyan Kapur
gyan.kapur@rhhllp.com