in reply to knowing your audience
in thread Programming *is* much more than "just writing code".

You may be someone who can read code better if it has no comments: don't assume everyone is like that.

The point is, that comments lie; code cannot.

(Would you like some help writing a comment-stripper script?)

No. I have an editor macro that handles that just fine thanks :)

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: knowing your audience
by Rhandom (Curate) on May 09, 2007 at 14:51 UTC
    No. The point is, that comments CAN lie. But they usually don't.

    By the same token code CAN lie -- either through complexity resulting in misinterpretation, or by function names that don't do what they say (such as a routine named die_with_errors that actually only warns). But code usually doesn't lie.

    BrowserUK:
    The first thing I do in most every piece of other peoples code I pick up is to throw away the comments (in a copy!). The second is to manually reformat the code to my personal preferences. The third is to 'fix' any obvious verbosities, by recoding them to use (my preferred) idiomatic constructs and discard any extraneous (used once intermediary) variables.

    You're a contractor aren't you. You've broken the hippocratic oath of programming - you know - the one that says "First do no harm." At the places I work, which have been with teams of 5 to 20 perl programmers of various abilities and coding styles, that sort of attitude doesn't fly. At the very least it inflicts your choice of programming style on everybody else - even if your choice of programming style is the best. At slightly worse level it removes comments that other programmers may have been using for visual cues - even if you don't use them. Getting worse it kills CVS annotation which is actually a valuable thing to have when tracking changes. And potentially the worst is that you have refactored all of the code that was probably working just fine - now rather than testing just the broken bug, you have to test for all of the other errors that you may have introduced. Good thing you have a test suite, but sometimes you don't.

    Patient: Blurp! (breathe) (wake)
    Doctor: Oh - good morning glad to see you're waking up.
    Doctor: How do you feel?
    Patient: gack!
    Doctor: Well, you're good to go now. We took care of your appendix.
    Doctor: Oh and while we were in we lipo-suctioned your abdomen, removed your gall bladder, performed a bypass, refactored your nose, placed skin grafts over your tattoes, and shrunk your stomach.
    Patient: But it was just my appendix.
    Doctor: Don't worry. I figure you're 30 pounds lighter. Your much more refactored and simple now.
    Patient: But it was just my appendix. (gasp)
    Doctor: Oh - and we removed one of your kidneys.
    Nurse: Doctor - he only had one kidney.
    Patient: (die)


    my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]

      Did you see

      (in a copy!).
      ?

      Because everything you are trying to say and imply is voided by that.

      I modify a copy. This is my way of becoming thoroughly familiar with the code I am going to work on.

      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.
[reply]
        Yes I did. You never clarified if you replaced the original with your copy.

        All of your refactoring and changes void the fixing of the bug in the copy. There is no guarantee that your changes before you even begin working on the bug, don't affect the bug. If you are only using the modified copy to figure out what the original is doing, then you may still be off because there is no guarantee that you refactored the original correctly.

        If you are not replacing the original with your modified copy - once you are done with your modified copy, you then have to go through the same exercise on the original because your patches won't apply cleanly.

        Either way you have doubled the work that you need to do. In which time you could have instead read the comments and decided if they matched the code.

        Should you discard your modified original - you have wasted your employer's time (unless you are the employer). You may now be smarter about the code and have reached a certain nirvana, but you have expended effort on discarded code.

        If you don't discard your modified original, then my points still stand.

        What you choose to do with your coding practices is entirely up to you. If you feel implied guilt or feel maligned when people post nodes saying "one should comment one's code" and you don't, the issue lies with you. If you are comfortable in your practices that is wonderful -- I am happy for you -- no really, I am. You are under no obligations to anyone who posts or anything posted by other people (I apologize for saying earlier that you are obligated to - thinking about it you really don't have any enforced obligations to anybody - but that is a topic for future nodes). But comments against common practices, that haven't worked for you but do work for many other people, are bound to be ill received -- even when you are right.

        my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]

In Section Meditations