<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 class=""><blockquote type="cite" class="">To do a complete evaluation also need to think about<br class="">what applying the guidelines will do to your own code.</blockquote><br class=""></div><div class="">You’re right! I extracted the list of method definitions from my app and looked through it.</div><div class=""><br class=""></div><div class="">The overwhelming majority of my methods either take no arguments, or start with a verb and make a phrase where the first parameter doesn’t require a label (rule B1).</div><div class=""><br class=""></div><div class="">Some methods I noticed (I don’t know if this is useful for you, but if it is then here you go):</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private func setHandoffState(hash hash: String, fallbackURL: String, title: String? = nil, searchable: Bool) {</div><div class=""><br class=""></div>This seems OK to me, but I’m not entirely sure if the guidelines suggest I _should_ put a preposition there, i.e.<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>setHandoffStateFor(hash: a, fallbackURL: b, …)</div><div class=""><br class=""></div><div class="">I don’t think I should — I don’t see how “for” adds to clarity here, but I want to make sure if I interpret the proposed guidelines right.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func actionForCommand(command: UIKeyCommand) -> String? {</div><div class=""><br class=""></div><div class="">This should become “actionFor(command: c)” — which isn’t an obvious win, but I certainly don’t mind it.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private func createAttribute(tag: SecItemAttr, _ data: NSString?) -> SecKeychainAttribute? {</div><div class=""><br class=""></div><div class="">Forgive my barbaric removal of external labels. It should be `createAttribute(tag: t, data: d)`. Alternatively, it could be `attributeFor(tag: t, data: d)` — I could go either way.</div><div class=""><br class=""></div><div class="">(adding to my thoughts on the later proposal of moving preposition inside parens, the symmetry in param labels would likely be broken here, because it doesn’t seem necessary to add “for”/“with” when I go with “createAttribute”, but for the noun-only version it would have to be “attribute(forTag: t, data: d)”.)</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func attachmentForImage(image: UIImage) throws -> Attachment {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func attachmentForData(data: NSData) -> Attachment {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func attachmentForFileURL(url: NSURL) throws -> Attachment {</div></div><div class=""><br class=""></div><div 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.)</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private func messageCell(label label: String) -> MessageCell {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private func cellForTask(task: Task, enabled: Bool = true) -> TaskCell {</div></div><div class=""><br class=""></div><div class="">Hm, those are inconsistent. I could go with `cellFor(message:)` and `cellFor(task:)`, which would be consistent with the guidelines. OTOH, since they return different types, I liked that they had different names… `taskCellFor(task:)` is redundant. Perhaps `taskCellFor(_:)` and `messageCellFor(_:)`.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func generate(fill: Double, text: String) -> CLKComplicationTemplate {</div><div class=""><br class=""></div><div class="">`templateFor(fill:, text:)`</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func update(from old: TaskCommentRowModel?, to new: TaskCommentRowModel) {</div><div class=""><br class=""></div><div class="">That’s the, IMO rare, circumstance where the preposition *does* make sense to go inside the parens.</div><div class=""><br class=""></div><div class="">* * *</div><div class=""><br class=""></div><div class="">I mentioned this in some other post before, but I also found a bunch of methods where the first parameter should be labeled, but isn’t, because without an easy shortcut like the old #param, I was just too lazy to do The Right Thing.</div><div class=""><br class=""></div><div class="">PS. If someone wanted to do the same thing and review methods in their project, here’s the quick&dirty Ruby script for this: <a href="https://gist.github.com/radex/b425c73afde84d88e4ca" class="">https://gist.github.com/radex/b425c73afde84d88e4ca</a> </div><div class=""><br class=""></div><div class="">HTH,</div><div class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 08 Feb 2016, at 21:55, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Mon Feb 08 2016, Radosław Pietruszewski <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Dave,<br class=""><br class="">First of all, thank you for enduring our nitpicks and complaints and<br class="">continuing to explore the subject :) I think we’re all better off for<br class="">it, and getting closer to the solution with each iteration.<br class=""><br class="">You asked:<br class=""><br class=""><blockquote type="cite" class="">1. I'm not expecting these guidelines to make everybody optimally happy,<br class=""> all the time, but they shouldn't be harmful. Are there any cases for<br class=""> which they produce results you couldn't live with?<br class=""></blockquote><br class="">And I think, by this standard, the guidelines you proposed seem to be<br class="">a success. Looking through Doug’s diffs, I see a lot of method names<br class="">that I don’t *love*, but I couldn’t find something I would hate.<br class=""></blockquote><br class="">That's great news! Keep in mind, though, that Doug's results are just<br class="">the result of trying to approximate application of the guidelines by<br class="">using heuristics. To do a complete evaluation also need to think about<br class="">what applying the guidelines will do to your own code.<br class=""><br class="">Thanks,<br class=""><br class="">-- <br class="">-Dave<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>