-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recommendation on delegate methods naming convention? #175
Comments
This makes more sense to me
I also think it depends on what this method is doing and in what context it defined. |
Well, this is your typical delegate method, it belongs to the NamePickerViewControllerDelegate, and it notifies the delegate that the user picked a name. I like your version, I will start using it. I think this would be a nice addition to the style guide (I haven't seen it in the current version but noticed a massive PR pending). |
Here's my take: (1) This guide frequently defers to Apple's guidance. For examples, see (2) Apple frequently puts the name of the delegating (i.e.
(3) Thereby, if we specify anything (I'm on the fence about whether we should or not), I think we should follow said examples. Thereby, I'd go with this signature:
|
Right. I think this is going to look like this for Swift 3, since the first parameter will no longer be handled specially like in Swift 2.2. func namePickerView(_ namePickerView: NamePickerView, didSelectName name: String) Doing the same thing that table view source is a good naming strategy. |
Understood. Thanks for the clarification. @JRG-Developer As far as I can tell the Swift API Design Guidelines they refer to do not explicitly talk about delegate method naming. I think they are basically saying "follow Apple's lead", which I think is not a bad approach. Consistency has its benefits. |
Thank you everybody for your input. I think we can close this issue as "follow Apple's lead". |
I think a delegate naming guideline should come out of this even if it is along the lines of "follow Apple's lead." |
#181 addresses this issue |
Thanks for your help on this @fabienwarniez ... if you want to add yourself to the list of contributors feel free to send a PR. |
* Chained method recommendations. * Change style for empty arrays and dictionary initialization. * remove spurrious 'the' * add golden path * Remove c-style for loops (kodecocodes#155) * Fixes kodecocodes#138 -- don't use c-style loops * Fix spacing. Fixes kodecocodes#138 * Move protocol conformance to a section called Code Organization (kodecocodes#149) * rules for abbreviations (kodecocodes#150) * recommendation to not include parenthesis (kodecocodes#151) * recommendation to not include parenthesis * add parens to TOC * names for protocols (kodecocodes#152) * function versus method (kodecocodes#153) * recommendation on when to use free function vs method * remove extra space * elide class name from selector when possible (kodecocodes#156) * add recommendation to omit class name from selectors when possible * remove escaped octothorpes * Guide -> Guidelines * whitespace * Lazy init recommendation (kodecocodes#157) * lazy initialization example * add some notes * add access control info kodecocodes#97 (kodecocodes#158) * switch dynamic and lazy kodecocodes#97 * fix typo * space * formatting fix * for -> while * fix missing brace * add Ray Fix to Credits * fixed description from Joshua Greene (kodecocodes#161) * add recommendation on generic type parameter names Fixes kodecocodes#159 (kodecocodes#160) * add discussion of static. fixes kodecocodes#131 (kodecocodes#163) * add discussion of static. fixes kodecocodes#131 * clarify global functions * Colon space (kodecocodes#164) * spaces and colons * exceptions, examples of bad colon spacing * remove errant * * fixes kodecocodes#162 (kodecocodes#166) * discuss lifetime issues (kodecocodes#167) * add recommendation about final (kodecocodes#169) * navigation fix * clarification to type names * fix capitalization, spelling * fix incorrect white space (via Sam Davies) * Add self as maintainer. (via Ray Wenderlich) * more spacing * Add clarification to access control order * addressing issue kodecocodes#137 * addressing kodecocodes#173 about type constants and global constants * tighten selector text; abbreviate context as it is more noise than understanding kodecocodes#137 * remove extra space after periods * use term type properties more consistantly kodecocodes#173 * code escape static let kodecocodes#173 * fix navigation kodecocodes#173 * type properties -> variable type properties kodecocodes#173 * Fixes kodecocodes#174: update enumerations to API Design Guidelines * Make generic type examples compile for Swift 3 and conform to naming guidelines. * Reformat guard spacing. Add lets to make compile for Swift 3. * Remove reference to M_PI with Double.pi. Remove pi example for root2. * Update closures for Swift 3. * PascalCase naming fix (kodecocodes#208) Sorry for the long delay on this. * Added colons space exceptions (kodecocodes#202) * Added Style Guide License section (kodecocodes#216) * Implementation of kodecocodes#223 (kodecocodes#225) * Added "No trailing whitespaces" rule From Linux Kernel Conventions https://www.kernel.org/doc/Documentation/CodingStyle: "Do not leave trailing whitespace at the ends of lines." Discussion on Stack Overflow - http://programmers.stackexchange.com/questions/121555/why-is-trailing-whitespace-a-big-deal. * added Vadim Eisenberg as a contributor https://github.com/vadimeisenbergibm * fixed position of Vadim Eisenberg to be in alphabetic order after Collin Eberhard and before Ray Fix * remove referece to ++ and --. implementation of kodecocodes#222 * add a contributing guide * revamp the section on naming to reference API design guidelines kodecocodes#218 * remove section on naming protocols and enums in deference tof API design guidelines * remove dead navigation * revised rules for names in prose kodecocodes#219 * formatting gliches kodecocodes#219 * add white space rules * add note about parenthesis kodecocodes#193 * fix typo * add delegate advice kodecocodes#175 (via @fabienwarniez) * Type inferred context kodecocodes#230 * fix TOC * update goals * update goals kodecocodes#231 * Split credits and license into separate files * fix spacing in project settings screenshot kodecocodes#197 * add requirements on organization and bundle identifier kodecocodes#198 * remove fluff and add more keypoints to the API guidelines summary * make unused code examples compile for swift 3 * Update spacing for closure example kodecocodes#189. * follow API design guidelines for items.mergeSorted() * spellos * grammar * remove section on struct initializers kodecocodes#234 * update control loops to swift 3 * clarify text * add link to raywenderlich.com * shuffle image around * Update access control kodecocodes#235 * adding a let as required by the Swift 3 compiler (kodecocodes#236) * Added contributor (kodecocodes#238) * Alphabetize credits. * Wrap rule. Wording slightly modified. kodecocodes#233 * fix Circle sample code kodecocodes#239 * typo * Improve wording of the newline character sentence (kodecocodes#253) - Add the word “single” to make it a bit more clear that there should not be multiple blank lines at the end of a file - “new line character” -> “newline character” - “end of file” -> “end of each file” * Fix indentation and formatting of trailing closure syntax example (kodecocodes#248) - Fix indentation to use 2 spaces - Remove the line break before the “animations” parameter in the “Not Preferred” example so that its formatting is consistent with the code in the “Preferred” example. While this style is still technically not preferred, this section is about whether or not to use trailing closure syntax. This way it is also easier for the reader to see at a glance what the difference is without having to mentally account for the line break. * Remove extra space after “let e” in example (kodecocodes#247) * Fix indentation to use 2 spaces instead of 3 (kodecocodes#246) * Add a single space after commas (kodecocodes#245) * Minor typo fixes (kodecocodes#242) * Fix style for else statement (kodecocodes#244) Even though the else statement being on a new line is technically “Not Preferred” the styling for the else statement is not what is being demonstrated, and so it should not differ between the “Preferred” and “Not Preferred” examples. * Add missing word (kodecocodes#243) "rather than an instance" -> "rather than on an instance" * remove obsolete semicolon exception issue kodecocodes#251 * fix typo kodecocodes#249 * strive to make your code compile without errors * clarify use of self and remove non-working example kodecocodes#241 * put self in code fence * Issue kodecocodes#240 (generic example) (kodecocodes#255) * Use `swap` for single uppercase letter generic parameter example (kodecocodes#240) * Add Jessy Catterwaul to the credits * Fixes kodecocodes#252. Don’t include the () when using the shortest form of method call. * Use softer language for marking classes final. * The new update branch is called update. * add an Updated for Swift 3 subtitle
I understand it is good practice to pass
self
to all delegate method calls, like UIKit does with UITableView for example.What is your recommendation for naming them?
Examples:
or maybe
or maybe simply
The text was updated successfully, but these errors were encountered: