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

[Gwendal Roué]

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.

Gwendal