Re: Code Maintainability

[kyle]

Thanks for your meditation. You've given me some food for thought.

I like statement modifiers for short statements.

upchuck() if ! $healthy;

For a much longer statement, I find the modifier gets lost, and it gets harder to understand what's going on.

Exception::Of::Doom->throw( error => 'Detailed error messages are impo
+rtant, especially when this error happens' ) if $oops;

I think there are plenty of times—perhaps even most times—that I'd rather read "if not" rather than "unless". I've seen programmers use "unless" almost universally for error conditions, and that seems like a pretty good convention, but even then I think it depends somewhat on what's in the condition.

upchuck() unless $healthy;  # doesn't sound right
error() unless happiness_ensues();   # better?

The other thing about statement modifiers is they make it harder to add stuff to the condition.

if ( ! $healthy ) {
    upchuck();
    die;
}

If it were written as three lines to begin with, I wouldn't have to go through so much trouble to add the one extra action.

Sometimes "maintainability" is about "editability" rather than "readability". Yes, statement modifiers allow you to get more on the screen, and it may flow more naturally before your eyes. Now insert some debugging statements. When it barfs on line 123, is that the stuff in the condition, or in the condition's result?

I don't always write "one thing per line", but I see its advantages.

As an aside, this looks clumsy to me:

print STDERR join("\n", @lines), "\n";

I've sometimes written that as:

print STDERR map { "$_\n" } @lines;

[TGI]

I like statement modifiers at the end for simple things like an early return, or throwing an exception. To handle longer lines I use indention:

die 'Detailed error messages are important, especially when this error
+ happens'
    if $oops;

But with the long exception you showed I might do:

Exception::Of::Doom->throw( 
    error => 'Detailed error messages are important, especially when t
+his error happens', 
) if $oops;

I often hear that switching the order is difficult and that it is a good reason not to use the trailing conditional. In practice, I haven't found that switching the conditional around to be that onerous. A good text editor makes it easy. If switching was so hard you would see more of this:

do {
    turn_green();
    throw_up();
    die "Ach, food poisoning";
) if $ptomaine;

[Porculus]

The other thing about statement modifiers is they make it harder to add stuff to the condition. (...)

If it were written as three lines to begin with, I wouldn't have to go through so much trouble to add the one extra action.

Sometimes "maintainability" is about "editability" rather than "readability".

Editability is about using a decent editor. For example, in Emacs you can convert between block "if" and statement-modifier "if" with a single command. If your editor can't do that, then I would argue it's your editor's problem...

As an aside, this looks clumsy to me:

print STDERR join("\n", @lines), "\n";

I've sometimes written that as:

print STDERR map { "$_\n" } @lines;

I wouldn't use either form; they both get too far away from mpeever's ideal, which I share, of code that reads like English.

If you want to print a bunch of lines to STDERR, I personally believe it's best to say "I want to print a bunch of lines", not "I want to build a string by joining a bunch of lines with newline characters, and then print that" or "I want to map a bunch of lines to a new array where they're terminated with newline characters, and then print that". In other words, I'd write:

print STDERR "$_\n" for @lines;

or, better still,

say STDERR $_ for @lines;

if you're lucky enough to have an up-to-date Perl, which of course many of us don't, in the workplace.

[mpeever]

In other words, I'd write:

print STDERR "$_\n" for @lines;

I think you're right: that's the clear winner. It's much less cryptic, and doesn't seem to offer any real downsides.

[JadeNB]

Wouldn't

{
local $, = "\n";
say STDERR @lines;
}

be clearer still?