Re^2: What is code readability?

[Anonymous Monk]

$fee = determine_maximum_fee();

sub determine_total_fee {

Refactoring error? Is it determine_maximum_fee() or determine_total_fee? And that name that is overly verbose.

  $fee = ($tfee / 100 + $sfee/100 + 0.0000001) * 100

...what in the world is this doing? If I had to guess, I'd say it is a hack to misuse floating point numbers, instead of using something like Math::Currency, although I'd expect to see some calls to int(). And it diddles with global variable $foo.

  $mfee = 200 if ($fee >= 100);

...refers to global variables $mfee and $fee. And $mfee is non-descript. And we should at least have a comment explaining the magic numbers 100 and 200.

  $fee = $mfee if $mfee;

...this is seems like it is probably a horrible hack to avoid warnings about undef.

  return $fee;
}

I'd probably not refactor into a subroutine, instead using a proper data type and something like...

use constant BREAK_POINT => 100;
use constant BONUS_FEE   => 200;

my $total_fee = $tfee+$rfee >= BREAK_POINT ? BONUS_FEE : $tfee+$rfee;

[Herkum]

You do bring up some good points about the code, however the problem is not with the code or its execution but its context. By moving the code into a function it should help declare a context of what is going to happen even if it hides what it is exactly doing.

[Anonymous Monk]

Maybe you should post what you think the real subroutine should look like. I suspect that the code is not being used more than once, there by negating the biggest incentive to turn it into a separate procedure. By the time you rewrite it properly, (by removing references to global variables, passing in parameters, etc.), it'll be longer and harder to understand. I'll go out on a limb here and say all the context you need is provided by an appropriate variable name, like $total_fee, for instance. But there's a chance that we'll just have to agree to disagree.