Good point. And I just noticed that it doesn't properly treat signs either. Still boring and straightforward, if not quite so trivial:

sub commify {
    my ( $sign, $int, $frac ) = ( $_[0] =~ /^([+-]?)(\d*)(.*)/ );
    my $commified = (
        reverse scalar join ',',
        unpack '(A3)*',
        scalar reverse $int
    );
    return $sign . $commified . $frac;
}
[download]

It should behave exactly like the FAQ code, and some shallow testing seems to confirm that.

Makeshifts last the longest.

Sometimes I rewrite a little snip of confusing code, and I fall in love with my new "more elegant" solution. Then after some sleep, I realize that my new solution is just as ugly as the version I replaced, and less battle-tested.

With respect for your discussion and skills, I must admit that to me, this code doesn't look better than (either of) the perlfaq5 examples. It doesn't look worse, but it is not a pearl of truth in the darkness, either. Your code and that code both take a bit of time to get to understand why each statement is justified, and how it deals with edge cases. I don't see an improvement, I just see a difference.

The first time I became a manager, I had to learn how to accept that other people do things in a way that I would not have done them. If it passes the tests, and it's not a risk to maintenance, then I would just have to let it be. I'd have to accept the solution until there was a real need to change it, and there rarely was. If I didn't learn to accept others' solutions, I'd end up coding it all myself. It's a hard hurdle to cross but it's a worthwhile one.

--
[ e d @ h a l l e y . c c ]

I would argue that the initial version, had it been sufficient, would be much easier understood by a novice than the regex solutions. Case in point: I got this function (the initial version) right three and a half times¹ from scratch in a single motion without having memorized the sequence, merely by remembering the mechanics. Given the triviality of the function, that is not a feat by any means, but doing the same with any of the regex-based versions certainly would have been. I consider that anecdotal proof for this approach indeed being simpler than the regex based ones.

Dealing with the extra cases complicated it beyond a significant win though. The extended approach probably does not require much less explanation than regex based ones either. I still consider it easier to grasp, but at this point the difference isn't particularly large.

And while you're right about code that has been sunk into a project in progress, that is not the context for which I advertised this snippet. I am not telling anyone to go back and change all their commify functions to this rendition. But best practices evolved and the Perl documentation too is constantly being revised — as they should be. This was precisely an attempt² at adding another tiny step forward to the current best practices.

Architects and engineers play on different levels under different constraints.

¹ Lack of sleep notwithstanding.

² Oh well.

Makeshifts last the longest.