in reply to Re^6: Programming *is* much more than "just writing code".
in thread Programming *is* much more than "just writing code".

I've been thinking about those comments overnight, and I don't have any particular objection to them. Certainly not the second one anyway. I think that one could easily fall under the auspices of my statement from the OP

Cool. It could eaisly be that I've gotten an exaggerated impression of how sparse you think comments need to be -- and by the way, I agree that it's certainly possible to have a surplus of comments that just become inane (most would agree that every line is too many, for example). Unlike what some people here are saying, though, I find that problem to be tremendously rare. Far more common is the "it was hard to write, it should be hard to understand" attitude.

That said, context is everything, and your snippet in isolation of the code (and further commenting) around it, makes it hard to decide if these are really warrented or not.

I think we're wandering afield, but the context is, of course, href-based objects, in this case using a seperation of instantiation from initialization. I'm playing with a simple "new" routine (inherited from Class::Base) which calls an "init" sub. I've used a version of init (generated by template) that looks something like this:

sub init { my $self = shift; my $args = shift; unlock_keys( %{ $self } ); # $self->SUPER::init( $args ); # uncomment if this is a child class # define new attributes my $attributes = { ### fill-in name/value pairs of attributes here # name => $args->{ name }, attribute => $args->{ attribute }, objectdata => $args->{ objectdata } || 23, parameter => $args->{ parameter } || 'bupkes', }; # add attributes to object my @fields = (keys %{ $attributes }); @{ $self }{ @fields } = @{ $attributes }{ @fields }; # hash slice lock_keys( %{ $self } ); return $self; }

Note: some of the comments there are intended to be deleted as the code goes from template form toward production use.

In general, the reason I think we're wandering afield is that I make no claims that these constructs are the best way of doing things. The question at hand is that if you are going to do something like this (e.g. use a mildly obscure feature such as a hash slice) is there something heinous about labeling it as such in a comment.

Replies are listed 'Best First'.
Re^8: Programming *is* much more than "just writing code".
by BrowserUk (Patriarch) on May 14, 2007 at 09:50 UTC
    The question at hand is that if you are going to do something like this (e.g. use a mildly obscure feature such as a hash slice) is there something heinous about labeling it as such in a comment.

    No. But now we have come full circle. I set out in the OP to refute the idea that "... programmers who do not extensively comment their code are lazy, or bad, or otherwise detrimental to the world of programmer-kind.".

    Ie. to refute the idea that not commenting the use of those features that an original programmer thinks that some of those that follow him might consider mildy obscure, is heinous.

    The purpose of the node was to point out that commenting is a double edged sword, with definite costs and ethereal benefits.

    So, I think that we are almost agreeing here. We just seem to be at opposite ends of the middle ground between those that appear to consider code incomplete unless it is possible to get a pretty complete idea of what the code is doing from reading the comments alone; and those that think that comments have no value at all. Though I must admit that a) I've never seen anyone who actually vermently advocated the latter position; b) I'm much closer to that end than you are to the other it seems.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      The purpose of the node was to point out that commenting is a double edged sword, with definite costs and ethereal benefits.
      The benefits are only as ethereal as any attempt at communication, and the programmer that doesn't understand that the source code is an attempt at communicating with human beings (as well as with a compiler), has some problems as a programmer.

      And I think you continue to exaggerate the costs. I don't think I've ever been confused by an out-of-date comment for any length of time... as I've said before, the fact that the comment is out-of-date can itself be an interesting hint about what's been going on.

      On the other hand, I've definitely been confused by devotees of "self-documenting" code: that's a philosophy that has a definite cost if you ask me.