Re^3: Commify numbers, the boring and straightforward way

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 ]

Comment on Re^3: Commify numbers, the boring and straightforward way

Replies are listed 'Best First'.
Re^4: Commify numbers, the boring and straightforward way by Aristotle (Chancellor) on Mar 02, 2005 at 17:14 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^4: Commify numbers, the boring and straightforward way
by Aristotle (Chancellor) on Mar 02, 2005 at 17:14 UTC

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.

[reply]