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

[Radosław Pietruszewski]

>>> 	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


Right. I’m not compelled by this argument, because it’s a tooling problem. I don’t believe language design lives in vacuum, outside of what the tools allow. Notice how the guidelines argue for the removal of type information repeated in the name — the information is already there and in situations when the context isn’t enough, it’s easy to view this information.

Besides — this seems like an edge case anyway. I very rarely see invocations long enough to be compelled to split it into multiple lines, and even if I would, I’d do it like this:

	attachmentFor(image: …,
				extraParam: ….)

And you can always search for /attachmentFor\(\s*image:/m in the (imho very rare) circumstance when you have a method family like that AND you want to search for just one of them AND there’s so many you can’t just look through the search results for `attachmentFor` AND you follow a convention where the first parameter label wouldn’t be in the same line as the method name.

— Radek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/513d4cb2/attachment.html>