Skip to content

Latest commit

 

History

History
94 lines (73 loc) · 5 KB

2.Naming_Conventions.md

File metadata and controls

94 lines (73 loc) · 5 KB

Naming Conventions for Code

  • 1 - Class names does not need to be prefixed using the classic Obj-C naming convention. Swift types are automatically namespaced by the module that contains them. If two names from different modules collide you can disambiguate by prefixing the type name with the module name.

  • 2 - Use Pascal Naming Convention for struct, enum, class, typedef, associatedtype, protocols etc (camel case plus uppercased first letter.

  • 3 - Use Camel Case Convention (with initial lowercase letter) for function, method, property, constant, variable, argument names, enum cases, etc.

  • 4 - When dealing with an acronym or other name that is usually written in all caps, actually use all caps in any names that use this in code. The exception is if this word is at the start of a name that needs to start with lowercase - in this case, use all lowercase for the acronym.

    // "HTML" is at the start of a constant name, so we use lowercase "html"
    let htmlBodyContent: String = "<p>Hello, World!</p>"
    // Prefer using ID to Id
    let profileID: Int = 1
    // Prefer URLFinder to UrlFinder
    class URLFinder { ... }
  • 5 - All constants that are instance-independent should be declared as static in order to avoid declaring one constant per instance. These constants should be placed in a marked section of their class/struct (after a // MARK:), or inside a case-less enum (if they can be grouped for a common context). The advantage of using a case-less enumeration is that it can't accidentally be instantiated and works as a pure namespace.

    Prefer:

    class MyClassName {
            // MARK: - Constants
            static let buttonPadding: CGFloat = 20.0
            static let indianaPi = 3
            static let shared = MyClassName()
    }
    class MyClassName {
        enum Constants {
            static let buttonPadding: CGFloat = 20.0
            static let indianaPi = 3
        }
    }
  • 6 - Prefer declaring constants in the scope in which they will be used rather than in a central shared file like Constants.swift.

  • 7 - Avoid ambiguous names for variables, classes etc (for example RoundAnimatingButton is preferred to CustomButton)

  • 8 - Avoid single name variables or abbreviations (for example use animationDuration and not animDur).

        // We don't want to use abbreviations, so don't use
        // `VC` instead of `ViewController`
        let popupVC: UIViewController // popUpViewController is preferred
        
        // for the same reason...
        let animDur: TimeInterval // animationDuration is preferred
  • 9 - Include type information in variable/constant names only when it's not obvious otherwise.

    class Person {
        // Its okay to omit 'String' in variable name because it's obvious that it's a string from property name itself.
        let firstName: String
        // When it's not obvious add the name
        let personImageView: UIImageView
    }
  • 10 - When working with IBOutlet make sure to add the outlet type at the end of the name.

    // PREFERRED
    @IBOutlet weak var submitButton: UIButton!
    @IBOutlet weak var emailTextField: UITextField!
    // NOT PREFERRED
    @IBOutlet weak var btnSubmit: UIButton! // type is added at the start and it's abbreviated
    @IBOutlet weak var buttonSubmit: UIButton! // type must be placed at the end
  • 11 - When naming function arguments, make sure that the function can be read easily to understand the purpose of each argument.

  • 12 - A Protocol should be named as nouns if they describe what something is doing (e.g. Collection) and using the suffixes able, ible, or ing if it describes a capability (e.g. Equatable, LogReporting). If neither of those options makes sense for your use case, you can add a Protocol suffix to the protocol's name as well.

File Naming Conventions

  • 1 - A file containing a single type MyType is named MyType.swift.
  • 2 - A file containing a type MyType and some top-level helper functions is also named MyType.swift. (The top-level helpers are not the primary entity.)
  • 3 - A file containing a single extension to a type MyType that adds conformance to a protocol MyProtocol is named MyType+MyProtocol.swift.
  • 4 - A file containing multiple extensions to a type MyType that add conformances, nested types, or other functionality to a type can be named more generally, as long as it is prefixed with MyType+; for example, MyType+Additions.swift.
  • 5 - A file containing related declarations that are not otherwise scoped under a common type or namespace (such as a collection of global mathematical functions) can be named descriptively; for example, Math.swift.