Swift: Global constant naming convention?

Naming ConventionsConstantsSwiftGlobal

Naming Conventions Problem Overview


In Swift, it seems that global constants should be camelCase.

For example:

let maximumNumberOfLoginAttempts = 10

Is that correct?

I'm used to all caps, e.g., MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS, from C, but I want to acquiesce to Swift conventions.

Naming Conventions Solutions


Solution 1 - Naming Conventions

Swift 3 API guidelines state that "Names of types and protocols are UpperCamelCase. Everything else is lowerCamelCase."

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

Ideally your global constants will be located within an enum, extension, or struct of some sort, which would be UpperCamelCase, and all properties in that space would be lowerCamelCase.

struct LoginConstants {
    static let maxAttempts = 10
}

And accessed like so,

if attempts > LoginConstants.maxAttempts { ...}

(credit to Ryan Maloney's answer for calling out the benefits of enum)

Solution 2 - Naming Conventions

I've been debating using camel case with a leading capital for class-level constants. For example:

static let MaximumNumberOfLoginAttempts = 10

It's still camel-case (as Apple appears to recommend), but the capitalized leading character makes it clear that the value is immutable.

Solution 3 - Naming Conventions

To improve on bmjohns answer, it's better to use an enum instead of a struct to act as a namespace for your constants. An enum with no cases can't be instantiated, whereas a struct can. If it is a struct, then instantiating it (via LoginConstants()) is allowed, but that has no meaning and doesn't make sense to do.

The convention is to use enumerations for namespacing, as such:

enum LoginConstants {
    static let maxAttempts = 10
}

This ensures that the only valid usage of LoginConstants is for accessing its static members.

Solution 4 - Naming Conventions

Apple advocates the camelCase. That said, many use _camelCase just to differentiate it especially if you are likely to have the same name at a lower scope.

Solution 5 - Naming Conventions

I commonly see constants declared with a k, like so:

static let kLoginAttemptsMax = value

This also follows camel casing to a "T".

Solution 6 - Naming Conventions

There are a couple of options.

  1. Use Apple's naming convention as thisIsMyConstant.
  • Upside: it's promoted by Apple, so it's a "standard" thing.
  • Downside: no way to tell something is a constant or a variable without Option+Click.
  • Side note: Apple is not always right. A lot of people were using UIColor.myColor instead of UIColor.MyColor() way before Apple made the change, including me.
  1. Use Objective-C style kThisIsMyConstant. As a lot of Swift developers are objc experts, it should be pretty obvious for most Mac/iOS developers.
  2. Use C style THIS_IS_MY_CONSTANT. It's also used by a lot of other languages like Java.
  3. Use something like ThisIsMyConstant. I can't think of any languages using this style for now (there should be some but I just can't recall), but it's kind of close to Apple's suggestion.

Edit: it also depends on your linting/autoformatting tool(s). More thoughts were added as comments.

Solution 7 - Naming Conventions

Apple shows us constants with camelCase.

I use the bether readable variant. So for your example:

let maximumNumberOfLoginAttempts = 10
let MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS = 10

'MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS' ist bether readable for me and it shows instantly, that it's a constant var.

Solution 8 - Naming Conventions

You can see not just what Apple says, but what they do.

You can have a look at Foundation class, that is a class created by apple and it is imported by default in the ViewController file when you create a new project.

Press command+option+click over the class to see its declaration.

image to see two swift examples from apple

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionma11hew28View Question on Stackoverflow
Solution 1 - Naming ConventionsbmjohnsView Answer on Stackoverflow
Solution 2 - Naming ConventionsGreg BrownView Answer on Stackoverflow
Solution 3 - Naming ConventionsRyan MaloneyView Answer on Stackoverflow
Solution 4 - Naming ConventionsTokurikuView Answer on Stackoverflow
Solution 5 - Naming ConventionsHobbyistView Answer on Stackoverflow
Solution 6 - Naming Conventionssuperarts.orgView Answer on Stackoverflow
Solution 7 - Naming ConventionsJavatarView Answer on Stackoverflow
Solution 8 - Naming ConventionsChristianView Answer on Stackoverflow