Naming advice for static, class and let constants

You believe it is important to distinguish between things with a getter and a setter, visually. This is not a necessary belief. Some things make sense to get, some to set, and some, both. Apple does not yet know that some things are appropriate to only be set, but they will surely learn. In the meantime, we just won't set some things, and we may use this:

/
/
/
/
@noreturn public func setOnlyPropertyGetterError(propertyName: String = __FUNCTION__) {
   fatalError("\(propertyName) is set-only")
}

I have 4 lines of documentation but they won't paste because this forum is not ready.

Conventions are, after all, conventional — that is to say, usual, not mandatory. If you feel you are not served by the convention, then I don't see why you can't set your own rules. This would be especially true in this case if you're trying to promote consistency of symbols across your various implementations (Java, C++), if it's useful for a client to recognize symbols as being the same in different contexts.

That said, keep some things in mind:

— In your Swift version, you'll likely want to make these symbols be class properties, not global properties. (The same ought to be true of the other implementations, but probably isn't for historical reasons.) Your constant may not be 'someImportantConstant', but rather 'SomeClass.someImportantConstant'. Especially if you're providing a 3rd party library, you really should avoid putting symbols in the global namespace, even though they're implicitly qualified by the library module name.

— In C, the reason for the all uppercase convention wasn't to distinguish constants, but to distinguish macro symbols. The reason this mattered (I suspect) is that macro symbols aren't inherently strongly typed. In Swift, this distinction doesn't exist.

— I think it's a genuine question why you (or anyone) thinks it helps to have constants stand out from other symbols. I have to admit to having the same impulse myself, when naming things, but I haven't really been able to come up with an answer why it matters. Other than habit.

Start constants with a lowercase "k" (harkening back to my MacApp days), e.g., kSomeImportantConstant

I still use this in Swift. It may be archaic but it's simple and it works.

All caps with underlines to me calls too much attention to those variables in my opinion, it's too loud. However, this would be more common to "old school" programmers in general, as far as I know the "k" prefix is mostly or entirely a Mac thing.

I would not recommend capitalizing constants. You can do whatever you want in your own code of course but it will be frowned upon. 🙂

k is German but Swift is English; it's not a good match. As someone who only came to native Apple programming because of Swift and Metal, k also builds no recognizability because it is not used in new code.

I think it's a genuine question why you (or anyone) thinks it helps to have constants stand out from other symbols. I have to admit to having the same impulse myself, when naming things, but I haven't really been able to come up with an answer why it matters. Other than habit.

Nicely put. I agree with this (including the admission of having the impulse to make constants "special").

We're not really talking about "constants" per se; the Swift convention is pretty clear that immutable values shouldn't have special names. The question is more specifically whether there should be some distinguished notation for "extrinsic, potentially arbitrary, global, scalar, constant values."

The benefit of making those types of values obvious to inspection, I'd say, is that readers of the code know that they don't have to worry about where they come from. They're just known constants. Don't you worry your pretty little head about that.

Of the OP's options, I really like the enum solution. It's unimprovably Swifty, and the .EnumCaseName notation clearly indicates a symbolic, immutable value. The API has to support the enum cases directly, though. It would be pretty unsightly to see MyConstants.OptionA.rawValue in client code.

For cases that don't fit with enums and that don't have an obvious class to contain them, what about the option of packing constants into an arbitrary struct:

struct FooLibraryConstants {
    static let alertColor = UIColor.redColor()
    static let bitMask = 0xFF80
}

This option keeps the global namespace tidy and marks all mentions of the constants with a FooLibraryConstants prefix. Clear, but maybe a bit wordy.

Short extract from Math API, that's used in Swift and comes from Apple

#define M_E 2.71828182845904523536028747135266250 / e */

#define M_PI 3.14159265358979323846264338327950288 / pi */

All full cap !