[swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching
swift-evolution at haravikk.me
Fri Jan 29 06:47:40 CST 2016
> On 29 Jan 2016, at 12:25, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> Shadowing is a required evil in the world of name clashing, but in this if var concept it is a really bad habit.
Is it though? I mean, I can understand clashes occurring when you use the same local variable/parameter name as you do for a property, but this is easily solved by always using self. in front of usage of the actual property.
Other than that, in my experience at least, a lot of clashes come from poor variable naming; while I understand the appeal of short names for loop indices, it’s not as if we need them a lot thanks to the wealth of options available for accessing sequences so it’s not really a huge burden to use someIndex or whatever as a name. Besides which descriptive variable names are a huge benefit to maintenance in general. At lot the examples are let x = x, to which my first thought is “pick two actual names that tell me something"
Personally I’d prefer to see shadowing of local variables eliminated entirely, as there should be no excuse for running out of names within the scope of a single function, because well designed function implementations shouldn’t be so long (or use so many variables) as to make that a possibility. The only shadowing I’m fine with is parameters over properties, but that’s only because everyone should (in my opinion) be using self. for properties all the time anyway (even when there’s no current naming conflict).
More information about the swift-evolution