<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>func attachmentForImage(image: UIImage) throws -&gt; Attachment {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>func attachmentForData(data: NSData) -&gt; Attachment {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>func attachmentForFileURL(url: NSURL) throws -&gt; Attachment {<br class=""><br class="">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.)<br class=""></blockquote><br class="">If such convention were to be adopted, we could throw away our favorite grep tools.<br class=""><br class="">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:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>attachmentFor(image: …, extraParam: …)<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>attachmentFor(<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-converted-space">&nbsp;</span>&nbsp;&nbsp;&nbsp;image: …,<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-converted-space">&nbsp;</span>&nbsp;&nbsp;&nbsp;extraParam: …)<br class=""><br class=""><br class="">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.<br class=""><br class="">Whereas if the function were named attachmentForImage(_:extraParam:), I could look for "attachmentForImage", and get much more precise search results.<br class=""><br class="">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.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I admit that it’s hard to leave coding habits, and I have slightly over-reacted above.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I can’t wait for Xcode to bring better Swift code navigation tools, that would make lower the usefulness of text searching.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Gwendal</span></div></blockquote></div><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>attachmentFor(image: …,</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                                </span>extraParam: ….)</div><div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class=""><div class="">— Radek</div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></div></body></html>