A Short Note – iOS Best Practices And Swift Coding Standards With Code Organization, Spacing and Comments

Hello Readers, CoolMonkTechie heartily welcomes you in A Short Note Series (iOS Best Practices And Swift Coding Standards With Code Organization, Spacing and Comments).

In this note series, we will learn about iOS Best Practices and Swift Coding Standards With Code Organization, Spacing and Comments. 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 Code Organization, Spacing and Comments which will helps to ensure our code as efficient, error-free, simple ,easy maintenance enabled and bug rectification.

So Let’s begin.

Code Organization

We can use extensions to organize our code into logical blocks of functionality. Each extension should be set off with a // MARK: – comment to keep things organised.

Protocol Conformance

We can prefer adding a separate extension for the protocol methods when adding protocol conformance to a model. This keeps the related methods grouped together with the protocol and can simplify instructions to add a protocol to a class with its associated methods.

Preferred :

class MyViewController: UIViewController {

  // class stuff here

}

// MARK: - UITableViewDataSource

extension MyViewController: UITableViewDataSource {

  // table view data source methods

}

// MARK: - UIScrollViewDelegate

extension MyViewController: UIScrollViewDelegate {

  // scroll view delegate methods

}

Not Preferred :

class MyViewController: UIViewController, UITableViewDataSource, UIScrollViewDelegate {

  // all methods

}

Since the compiler does not allow us to re-declare protocol conformance in a derived class, it is not always required to replicate the extension groups of the base class.

This is especially true if the derived class is a terminal class and a small number of methods are being overridden. When to preserve the extension groups is left to the discretion of the developer.

For UIKit view controllers, consider grouping lifecycle, custom accessors, and IBAction in separate class extensions.

Unused Code

Unused (dead) code, including Xcode template code and placeholder comments should be removed. An exception is when our tutorial or book instructs the user to use the commented code.

Aspirational methods not directly associated with the article whose implementation simply calls the superclass should also be removed. This includes any empty/unused UIApplicationDelegate methods.

Preferred:

override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

  return Database.contacts.count

}

Not Preferred:

override func didReceiveMemoryWarning() {

  super.didReceiveMemoryWarning()

  // Dispose of any resources that can be recreated.

}

override func numberOfSections(in tableView: UITableView) -> Int {

  // #warning Incomplete implementation, return the number of sections

  return 1

}

override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

  // #warning Incomplete implementation, return the number of rows

  return Database.contacts.count

}

Minimal Imports

Import only the modules a source file requires. For example, don’t import UIKit when importing Foundation will suffice. Likewise, don’t import Foundation if we must import UIKit.

Preferred:

//1
import UIKit

var view: UIView

var deviceModels: [String]

//2
import Foundation

var deviceModels: [String]

Not Preferred:

//1

import UIKit

import Foundation

var view: UIView

var deviceModels: [String]

//2

import UIKit

var deviceModels: [String]

Spacing

Indent using 2 spaces rather than tabs to conserve space and help prevent line wrapping. Be sure to set this preference in Xcode and in the Project settings as shown below:

• Method braces and other braces (if/else/switch/while etc.) always open on the same line as the statement but close on a new line.
• There should be exactly one blank line between methods to aid in visual clarity and organization. Whitespace within methods should separate functionality, but having too many sections in a method often means we should refactor into several methods.
• There should be no blank lines after an opening brace or before a closing brace.
• Colons always have no space on the left and one space on the right. Exceptions are the ternary operator ? :, empty dictionary [:] and #selector syntax addTarget(_:action:).
• Long lines should be wrapped at around 70 characters. A hard limit is intentionally not specified.
• Avoid trailing whitespaces at the ends of lines.
• Add a single newline character at the end of each file.

We can re-indent by selecting some code (or Command-A to select all) and then Control-I (or Editor ▸ Structure ▸ Re-Indent in the menu). Some of the Xcode template code will have 4-space tabs hard coded, so this is a good way to fix that.

Preferred:

//1

if user.isHappy {

  // Do something

} else {

  // Do something else

}

//2

class TestDatabase: Database {

  var data: [String: CGFloat] = ["A": 1.2, "B": 3.2]

}

Not Preferred:

//1

if user.isHappy

{

  // Do something

}

else {

  // Do something else

}

//2

class TestDatabase : Database {

  var data :[String:CGFloat] = ["A" : 1.2, "B":3.2]

}

Comments

When we are needed, we can use comments to explain why a particular piece of code does something. Comments must be kept up-to-date or deleted.

We should avoid block comments inline with code, as the code should be as self-documenting as possible.

Exception: This does not apply to those comments used to generate documentation.

We should also avoid the use of C-style comments (/* … */). We can prefer the use of double- or triple-slash.

Conclusion

In this note series, we understood about iOS Best Practices and Swift Coding Standards With Code Organization, Spacing and Comments. We discussed about iOS Swift based Code Organization, Spacing and Comments concepts 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 Code Organization, Spacing and Comments concepts in iOS Swift. 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 !!???