A Short Note – iOS Best Practices And Swift Coding Standards With Naming Conventions

Hello Readers, CoolMonkTechie heartily welcomes you in A Short Note Series (iOS Best Practices And Swift Coding Standards With Naming Conventions).

In this note series, we will learn about iOS Best Practices and Swift Coding Standards With Naming Conventions. Coding standards act as a guideline for ensuring quality and continuity in iOS code. We will discuss about iOS best practices and swift coding standards with Naming Conventions which will helps to ensure our code as efficient, error-free, simple ,easy maintenance enabled and bug rectification.

So Let’s begin.

Overview of Naming Conventions

Descriptive and consistent naming makes code easier to read and understand. We can use the swift naming conventions described in the API Design Guidelines. Some key takeaways include:

• Striving for clarity at the call site
• Prioritizing clarity over brevity
• Using camel case (not snake case)
• Using uppercase for types (and protocols), lowercase for everything else
• Including all needed words while omitting needless words
• Using names based on roles, not types
• Sometimes compensating for weak type information
• Striving for fluent usage
• Beginning factory methods with make
• Naming methods for their side effects
  • Verb methods follow the -ed, -ing rule for the non-mutating version
  • Noun methods follow the formX rule for the mutating version
  • Boolean types should read like assertions
  • Protocols that describe what something is should read as nouns
  • Protocols that describe a capability should end in -able or -ible
• Using terms that don’t surprise experts or confuse beginners
• Generally avoiding abbreviations
• Using precedent for names
• Preferring methods and properties to free functions
• Casing acronyms and initialisms uniformly up or down
• Giving the same base name to methods that share the same meaning
• Avoiding overloads on return type
• Choosing good parameter names that serve as documentation
• Preferring to name the first parameter instead of including its name in the method name, except as mentioned under Delegates
• Labeling closure and tuple parameters
• Taking advantage of default parameters

Prose

When we refer methods in prose, being unambiguous is critical. We can refer method name in the simplest form as possible.

• Write method name with no parameters. Example: Next, we need to call addTarget.
• Write method name with argument labels. Example: Next, we need to call addTarget(_:action:).
• Write the full method name with argument labels and types. Example: Next, we need to call addTarget(_Any?,action:Selector?).

For example using UIGestureRecognizer, Write method name with no parameter is unambiguous and preferred. We can use Xcode’s jump bar to lookup methods with argument labels. We can put the cursor in the method name and press Shift-Control-Option-Command-C (all 4 modifier keys) and Xcode will kindly put the signature on our clipboard.

Delegates

When we create custom delegate methods, an unnamed first parameter should be the delegated source. UIkit contains numerous examples of custom delegates methods.

Preferred :

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

func namePickerViewShouldReload(_ namePickerView: NamePickerView) -> Bool

Not Preferred :

func didSelectName(namePicker: NamePickerViewController, name: String)

func namePickerShouldReload() -> Bool

Use Type Inferred Context

We can use compiler inferred context to write shorter, clear code. 

Preferred:

let selector = #selector(viewDidLoad)

view.backgroundColor = .red

let toView = context.view(forKey: .to)

let view = UIView(frame: .zero)

Not Preferred:

let selector = #selector(ViewController.viewDidLoad)

view.backgroundColor = UIColor.red

let toView = context.view(forKey: UITransitionContextViewKey.to)

let view = UIView(frame: CGRect.zero)

Generics

Generic type parameters should be descriptive, upper camel case names. When a type name doesn’t have a meaningful relationship or role, use a traditional single uppercase letter such as T, U, or V.

Preferred:

struct Stack<Element> { ... }

func write<Target: OutputStream>(to target: inout Target)

func swap<T>(_ a: inout T, _ b: inout T)

Not Preferred :

struct Stack<T> { ... }

func write<target: OutputStream>(to target: inout target)

func swap<Thing>(_ a: inout Thing, _ b: inout Thing)

Class Prefixes

Swift types are automatically namespaced by the module that contains them and we should not add a class prefix such as RW.

If two names from different modules collide, we can disambiguate by prefixing the type name with the module name. However, we can only specify the module name when there is possibility for confusion which should be rare.

import SomeModule

let myClass = MyModule.UsefulClass()

Language

We can use US English spelling to match Apple’s API.

Preferred:

let color = “red”

Not Preferred:

let colour = “red”

Conclusion

In this note series, we understood about iOS Best Practices and Swift Coding Standards With Naming Conventions. We discussed about Naming Conventions which will helps to ensure our code as efficient, error-free, simple ,easy maintenance enabled and bug rectification.

Thanks for reading! I hope you enjoyed and learned about Naming Conventions concepts in iOS. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe us on this blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolmonkTechie as below link :

• iOS Note
• iOS Articles
• CoolMonkTechie Home Page

You can also follow other website and tutorials of iOS as below links :

• AppCoda.com
• Raywenderlich.com

If you have any comments, questions, or think I missed something, feel free to leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???