Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Monday January 28, 2008
05:16 AM

Poor mans revision control vs. Stupid mans revision control

[ #35500 ]

I am sick and tired of reading code where large sections are commented out, this mean I have to skip large sets of lines and this disturbs my reading of the code.

An even worse practice is when the entry points are renamed. Like subs are renamed to dostuff2 or dostuffold and dostuff is the one currently used.

The later probably being one of the worst, I have seen some of these in XSL style sheets where the match tag id disabled so it does not correspond with your XML. So the code is not really commented out, it is just never entered, very misleading.

I call this stupid mans revision control.

Comments in code are nice and sometimes you comment out something for debugging or disable a feature, even in production, since this is simply faster, we know it is the right way, but we do it anyway.

The problem with the last practice is that you overwrite everything also these small fixes when you deploy the next release. So I will argue that if you find it necessary to apply such fixes in your production code and you can not propagate the fix back into your SCM you need to work on your setup one way or the other. Your SCM should at all times be the sole place of reference.

Yes, CVS and SVN and all of these might not be the answer to all your problems but if you work around them they are not really put to use and instead they become a poor man's backup tool instead of a poor mans revision control.

I am no SCM superman, but I force myself to use SCMs and learn new stuff all the time, it is uphill sometimes and I make the same mistakes over and over again (me and CVS import will never ever become friends), but I insist on using SCM and getting the tools to work for me instead of having them becoming a tedious part of doing development.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • In the extreme, this is called a developmestuction environment [].

    It is the most horrible habit ever – the most horrible possible habit.

    Dare to delete, people! Does the code need to be there? Really? If it’s not absolutely necessary, why keep it? If you end up needing it, you can always go back through the revision history. (You’re not a dilettante and do have source control, right? Right?) At worst, leave a comment and mention the source control revision in which the deleted code can be

    • I once boasted that I had deleted more code at $JOB than I had written. I'm afraid that isn't quite true -- then or now -- but I like to think that I keep the ratio pretty close to 1.

      I love the feeling of deleting awful old code. It's like, I don't know, throwing away my meds for some horrible disease I've overcome.
  • But I agree, deletion is a privilege we sometimes forget that we have and there is nothing like the feeling of cleaning up code.

    I should schedule some regular refactoring session, just to get that special kick, I have seen several DRY violations in the code base.

    But again, time is not on my side.
    • Yeah, time pressure can make you do horrible things to a codebase. I know all too well.

      As for tough, well… I can’t really put this in few words, because it’s a big issue with many sides. The best I have seen it explained is by MJD in his Program Repair Shop talk at last year’s YAPC::Asia []. I really recommend that; watch it if you can. He makes a string of very good points about repetition, and more generally redundancy, in code.

  • At $former_employer, programmers had the nasty habit of copying and commenting out entire functions, entire classes even, to change a few lines of code. This was in a $language (not perl) that made it easy to do commenting out the first line of an indented block, the whole block was commented. It made it hell to search for anything in the code. I wrote a perl utility to remove all such blocks before I started working on any such file. No one ever missed the code. And it was all in revision control (
    • ...should've said "by commenting out the line before an indented block".
    • It’s odd. For some strange reason, people Don’t Understand Source Control. And they have this inexplicable discomfort about deleting code.

      My impression is that this is a consequence of programming by coincidence, but I don’t know if that’s a sufficient (or even at all correct) explanation.