Re: named arguments

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.

------------
:Wq
Not an editor command: Wq
[download]

Comment on Re: named arguments Download Code

Replies are listed 'Best First'.
Re^2: named arguments by drewbie (Chaplain) on Nov 22, 2004 at 21:19 UTC
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.	[reply]