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

[Gwendal Roué]

> Le 11 févr. 2016 à 15:06, Radosław Pietruszewski <radexpl at gmail.com> a écrit :
> 
>>>> 
>>>> 	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.

Sure. But when the tools are lagging, we end with a plain and simple regression. So I’ll follow you for the sole reason that Swift is still experimental, and that we don’t have to expect a environment that matches the one we used to have until Swift 3.x or Swift 4.

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

Sometimes, one need to find *all* invocations of a method. It maybe is not common. But we’re not always able to write a perfect test suite that makes refactoring an always successful trial and error process. Sometimes we have to think hard, and look at code thoroughly. In this context, a poor signal/noise ratio does not help when you look for something in your code. Searchability is important. If will suffer with the new conventions.

But it’s only a tooling problem.

Gwendal

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