Skip to content
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

Closed
fabienwarniez opened this issue May 1, 2016 · 9 comments
Closed

Recommendation on delegate methods naming convention? #175

fabienwarniez opened this issue May 1, 2016 · 9 comments

Comments

@fabienwarniez
Copy link

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:

func didSelectName(forNamePicker: NamePickerViewController, name: String)

or maybe

func didSelectNameForNamePicker(namePicker: NamePickerViewController, name: String)

or maybe simply

func didSelectName(namePicker: NamePickerViewController, name: String)
@mbeaty
Copy link

mbeaty commented May 1, 2016

This makes more sense to me

func didSelectName(name: String, forNamePicker namePicker: NamePickerViewController)

I also think it depends on what this method is doing and in what context it defined.

@fabienwarniez
Copy link
Author

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

@JRG-Developer
Copy link
Member

JRG-Developer commented May 2, 2016

Here's my take:

(1) This guide frequently defers to Apple's guidance. For examples, see Naming and Protocol Naming sections, both of which refer to Following Apple's API Design Guidelines.

(2) Apple frequently puts the name of the delegating (i.e. self) object first. UITableViewDataSource and UITableViewDelegate show many examples of this:

optional public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell

optional public func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath)

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

func namePickerView(namePickerView: NamePickerView, didSelectName name: String)

@rayfix
Copy link
Contributor

rayfix commented May 3, 2016

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.

@mbeaty
Copy link

mbeaty commented May 3, 2016

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.

@fabienwarniez
Copy link
Author

Thank you everybody for your input. I think we can close this issue as "follow Apple's lead".

@rayfix
Copy link
Contributor

rayfix commented May 4, 2016

I think a delegate naming guideline should come out of this even if it is along the lines of "follow Apple's lead."

@rayfix rayfix reopened this May 4, 2016
fabienwarniez added a commit to fabienwarniez/swift-style-guide that referenced this issue May 6, 2016
fabienwarniez added a commit to fabienwarniez/swift-style-guide that referenced this issue May 6, 2016
fabienwarniez added a commit to fabienwarniez/swift-style-guide that referenced this issue May 6, 2016
@fabienwarniez
Copy link
Author

fabienwarniez commented May 12, 2016

#181 addresses this issue

@rayfix
Copy link
Contributor

rayfix commented Nov 24, 2016

Thanks for your help on this @fabienwarniez ... if you want to add yourself to the list of contributors feel free to send a PR.

@rayfix rayfix closed this as completed Nov 24, 2016
daneov added a commit to daneov/swift-style-guide that referenced this issue Dec 19, 2016
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants