Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • > Comments aren't there to explain the mechanics,
    > but to document the state of mind.

    Agreed. However, not all folks use comments in that manner.

    If your code implements a diagonal proof at one point, Paul would probably be unopposed to a comment referencing what such a thing is (assuming that the expected maintainers of the code would not already know). In a mathematics department, the comment is probably uneccessary. If you found cause to use a diagonal proof in your flowchart layout generation code at a securities exchange firm, then the comment would probably be very appropriate.

    > So why is he elevating them to the top of the list
    > of things to demonize in source code?

    I think Paul is talking about comments that are there to explain code which is not self-explanatory... code that needs to be explained because the author had these huge subroutines with opaque variable names and the latest tricks they picked up on the golf mailing list.

    Those authors use comments as an excuse to write opaque code. "As long as I have enough comments, I can implement this in any fashion I see fit. The maintianer can always follow my comments." If those authors were forced to maintian their own code without any comments, then they would likely start writting better code in the first place.

    > And how does Perl get to be the whipping boy?

    Because Perl always gets to be the whipping boy when the subject matter is opaque code. No, it's not fair.

    -matt