Title case usage for let values about swift-style-guide HOT 11 CLOSED

I agree with Andrew. 100%. 

camelCase for let!

—
Chris

On Sun, Dec 14, 2014 at 1:52 PM, Andrew Clissold [email protected]
wrote:

let MaximumWidgetCount = 100

I hate to say it, but I vehemently believe that TitleCase should be used strictly for names of types, and never for instances of types.
It's a difficult thing to get used to, coming from the worlds of I_AM_REALLY_SURE_I_WANT_THIS_TO_BE_A_CONSTANT of Java and kIWantToSignifyThisIsAConstantButHateCaps of Objective-C.
I'd argue that the ubiquity of "make it a let until proven otherwise" in Swift is very beneficial to readability as well as the compiler's ability to better optimize code (due to the increased frequency of immutable values), and that this ubiquity means that title case is not necessary, even for class-level constants.

:]

Reply to this email directly or view it on GitHub:
#74

from swift-style-guide.

My opinion on this is that for global constants, TitleCase should be used. camelCase should, IMO, only be used for local variables and constants. The TitleCase lets you know that the value is a global constant, but is not as annoying as the java CONSTANT_VALUE, and does not need the strange k-prefix

I do understand the argument that TitleCase should only be for class and name types, but I think that in the scenarios that you would use these constants, there would be little confusion.

from swift-style-guide.

I'd have to vote to agree with the current guideline – the example given is a module-wide constant, not a class-level constant. (Just to be sure we're talking about the same thing, I mean constants defined with let outside the class definition and accessible throughout the module.)

I've seen people go into contortions like a struct with a single static value, or an enum with one value to get nice-looking constants like Maximums.widgetCount but that seems like over-engineering – just call it MaximumWidgetCount and be done with it!

Lower camel case is already overloaded – methods, functions, properties, local variables – and we still survive, so I don't see much of a problem with using title case for both types and module/global constants.

from swift-style-guide.

Technically, if you want to avoid all this, you can create a global struct with static constants like this:

stuct Globals{
    static let maximumWidgetCount = 100
    static let nodeHeight: CGFloat = 150
}

That way, the values use camelCase, but are very distinguishable as global values because of their Globals. prefix.

But I do not think that would be the preferred way.

from swift-style-guide.

TitleCase screws with my head personally. I'm always like "who would make a class named that?" Or "why the heck is that a class and what does it do?". Throws me through a loop. 

If it's a global thing I'd vote for the struct approach so that I know very clearly it's a global constant and not a class/type. 

For the writing guide I guess I don't mind. But I'd personally never use title case in my projects. 

—
Chris

On Sun, Dec 14, 2014 at 4:21 PM, Evan Dekhayser [email protected]
wrote:

Technically, if you want to avoid all this, you can create a global struct with static constants like this:

stuct Globals{
    static let maximumWidgetCount = 100
    static let nodeHeight: CGFloat = 150
}

That way, the values use camelCase, but are very distinguishable as global values because of their Globals.</code prefix.

Reply to this email directly or view it on GitHub:
#74 (comment)

from swift-style-guide.

It's not called TitleCase; it's called PascalCase.

And it can't be used for constants. The logical reasoning would be:

1. Swift requires the name of the type to be used to call class methods (unlike C#, which only requires the type name to be used outside of the class that defines the static method).
2. Swift allows class and instance methods to have the same signature.
3. If you name a constant/variable the same as its defining type, you cannot differentiate between the class and instance methods.

However, you don't even need to bother going through that logic, because naming the constant the same as its type won't even compile, also unlike C#. Ergo, camelCase for all properties. Sometimes you want constants named the same as their type, and different naming conventions for those instances would be confusing.

I can see why this convention would be tricky to define, because Apple got the casing wrong for enum constants. Those should also be camelCase.

from swift-style-guide.

It's a clarity issue for me. Something that's a global- or module-level constant is important enough that I'd like its scope to be obvious. I actually like the kSomeConstant naming with the k – partly since it's a lower-case k (and satisfies the "all constants and variables are camel cased" rule) and also since it makes the scope obvious.

For tutorials and teaching, I think issues of scope are often confusing – is this a property? Local variable? Global constant? I think the current guideline helps with that. We can usually tell properties from methods apart based on their names even though they're all camel case; I suspect we can tell class/type names apart from constant names too, even if we UpperCamelCase them both.

But – I think globals are uncommon enough in our tutorials that we can go either way here depending on consensus here. And also depending on the enum discussion in issue #79.

from swift-style-guide.

If the code is written in English, k doesn't make sense. k also came from an era where monitors didn't have the ability to have some text look different from other text, and IDEs and CSS didn't exist. I'd like lets to look different than vars, but naming isn't the right way to handle that anymore. There are only two letter cases, but an infinite variety of how that text can be styled.

from swift-style-guide.

I'm of the opinion that SCREAMING_SNAKE_CASE is the best for global constants, mostly because when you have a global constant it's generally be serving the purpose that a #define would in Objective-C.

from swift-style-guide.

Most of our global constants are for shared singletons, like:

let sharedSomeService = SomeService()

We put other constants into classes, structs, or enums, depending on context.

struct Debug {
  static let isLoggedToConsole = true
}

Debug.isLoggedToConsole is easier to read and manage.

from swift-style-guide.

OK, we'll go camel case. I added a small hedge with private thinking this is still for a module-level constant. For exported globals I still think we need something different like SCREAMING_SNAKE_CASE but we can discuss that later.

from swift-style-guide.