Re: Practical example of "Is Perl code maintainable"

[Anonymous Monk]

in reply to Practical example of "Is Perl code maintainable"

This is what you'd get out of me:

sub file_mode {
  my ($file_name) = @_;

  if (-f $file_name) {
    my $mode = (stat _)[2];
    return $mode;
  } else {
    return -1;
  }
}

[Anonymous Monk]

Call me wool headed, but none of the samples here look maintainable to me - for one simple reason. Not one of them contains a single comment about what the code is supposed to do or what it is actually doing. Apparently perl does not support the inclusion of comments in code. I know when I'm maintaining existing code, I like to have to act like a language interpreter in my head to determine what a bunch of code is doing - comments are for noobies.

[runrig]

Call me whatever you want to, but the example you've just replied to looks about as close to self-documenting as it gets.

[Your Mother]

I wouldn't call you names but–

1. Of course Perl has comments.
2. Besides taking up space and concentration, comments drift and end up being lies or broken crutches a lot. They should only clarify what the code and the Pod (and the unit tests for that matter) cannot.
3. That the code presented isn't runtime application of composed roles and mixins built dynamically with business logic stored and versioned in the DB, it's a basic file check one perldoc away. It doesn't warrant even a correct comment.