Swift 3 functions naming convention [closed]

Question

I'm a little bit confused by function naming convention in Swift 3

I went through Swift 3 Guidelines and I found that method naming convention should look like this:

func move(from start: Point, to end: Point)
x.move(from: x, to: y)

but...

If I look on the UINavigationController methods I found pushViewController and presentViewController methods. The methods calls looks like this:

navigationController?.pushViewController(viewController, animated: true)
navigationController?.present(controller, animated: true)

and here I'm wondering why the pushViewController method call is not Swift3 like. And why there is a inconsistency between this two methods. Due to guidelines, I think the push method should look like this:

rootNavigationController?.push(viewController, animated: true)

then it would be more Swift 3 like.

Let's consider a simple example:

//1
func saveName(_ name : String) {}
saveName("John")

//2
func save(_ name: String){}
save("John")

//3
func save(name: String){}
save(name: "John")

In my opinion, I think the option number 3 fits the most to the Swift 3 Guidelines. But on the other hand due to my example with pushViewController and present(controller) methods the option number 1 is good too.

So my question is:

Which is the best option that fits the Swift 3 Guidelines the most?

UPDATE

Due to @Sweeper answer, it solves why there is an inconsistency between push and present methods.

Sources:

https://github.com/raywenderlich/swift-style-guide

https://swift.org/documentation/api-design-guidelines/#parameter-names

Answer 1

Please have a look at here: https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md

It says that:

- Never prune a suffix from the base name of a method that matches a property of the enclosing class:

This heuristic has the effect of preventing us from producing too-generic names for methods that conceptually modify a property of the class.

... If we were to drop GestureRecognizer, leaving just add, we end up with a method that conceptually modifies the gestureRecognizers property but uses an overly generic name to do so:

This is why pushViewController was not renamed. In UINavigationController, there is a property called viewControllers. To avoid an "overly generic name".

Why was present renamed then?

Note that present is defined in UIViewController. UIViewController does not have a property called viewController or viewControllers, so the ViewController part gets pruned.

Answer 2

Inconsistency:

• Much of the UIKit and Foundation frameworks have been built in Objective-C and have existed before Swift.
• So they have a Swift interface to access them, most of the places they have tried to match it and yes at times there is inconsistency.

Goal:

It is perfectly ok to have functions with or without external parameter name. It depends on the scenario (class, function and context)

The goal is to define the function name in such a way that the function name alone (without the parameters) describes what the function will do.

Look at from the usage and how it would be invoked. A clear name really can improve readability and pave way for a good design (avoiding confusion over where a function belongs in class A or class B

Example:

struct Record {
    
    var name : String
    var age : Int
    
    func save() {}
}

• In this case, it is might make sense not to have any parameters at all as name and age are properties in Record

• So the class / struct / enum also adds context, so unnecessary / redundant words can be avoided.

• Functions with side effects are represented with verbs

• Functions without side effects are represented with nouns

• Refer the below link for mutating and non-mutating functions.

Answer:

So it depends on the context and try to look at the usage of the API, that would give more insights how you can design your API.

record.save()

Note: The above is just an example, may be in your scenario save function might be part of a different context.

Reference:

https://swift.org/documentation/api-design-guidelines/