Re: named arguments

[etcshadow]

I've actually adopted the reverse. It's not a question of when to use named arguments, it's a matter of when not to. That is: assume that all subs take named arguments, and you really have to convince me if a particular subroutine should have positional arguments.

When you're managing a very large project that is constantly growing and changing, it's frankly the only way. Where I work we've actually got a whole slew of code conventions that center around making code future-change friendly, and this is the center-piece of them. Among the others are: giving all key-value pairs their own line, giving all array values their own line, and always putting (unnecessary) trailing commas on list and hash declarations. The point being: diffs and merges only affect the lines that actually changed semantically, and highlite what the actual change is.

[drewbie]

It's not a question of when to use named arguments, it's a matter of when not to.

++ on the coding conventions. I have come to the same conclusion. It doesn't take many compile errors to get into the habit of including the trailing comma. :-) Getting highly relevant & informative diffs is a nice gift too.