[swift-evolution] When to use argument labels, part DEUX

[Gwendal Roué]

> Le 11 févr. 2016 à 13:02, Gwendal Roué <gwendal.roue at gmail.com> a écrit :
> 
> Hello,
> 
>> Le 11 févr. 2016 à 12:34, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> PS. If someone wanted to do the same thing and review methods in their project, here’s the quick&dirty Ruby script for this: https://gist.github.com/radex/b425c73afde84d88e4ca 
> 
> Thanks, it’s much useful.
> 
>> 
>> 	func attachmentForImage(image: UIImage) throws -> Attachment {
>> 	func attachmentForData(data: NSData) -> Attachment {
>> 	func attachmentForFileURL(url: NSURL) throws -> Attachment {
>> 
>> This should be `attachmentFor(image:)`, `attachmentFor(data:)`, and `attachmentFor(fileURL:)`. This seems like a win, since related methods for different data types are grouped more tightly together. (I could also — like you suggested about not optimizing for method families — make an enum, but it would be overkill since it’s not API for public consumption. I should mark those as private.)
> 
> If such convention were to be adopted, we could throw away our favorite grep tools.
> 
> Functions with many parameters are often more legible when their invocation is split across several lines. And generally speaking, a developer can liberally call a function on a single line, or on several lines:
> 
> 	attachmentFor(image: …, extraParam: …)
> 	attachmentFor(
> 	    image: …,
> 	    extraParam: …)
> 
> 
> OK so now if I want to look for all invocations of attachmentFor(image:extraParam:) in my code, I have to look for "attachmentFor", and get all the unrelated results attachmentFor(data:…), attachmentFor(fileURL:…), etc.
> 
> Whereas if the function were named attachmentForImage(_:extraParam:), I could look for "attachmentForImage", and get much more precise search results.
> 
> So… I’m happy people discuss how nice `attachmentFor(image:)` looks, and my opinion on how nice or ugly it looks is not my point. My point is that I want my tools to help me doing my job.

I admit that it’s hard to leave coding habits, and I have slightly over-reacted above.

I can’t wait for Xcode to bring better Swift code navigation tools, that would make lower the usefulness of text searching.

Gwendal