[swift-evolution] Enforcing guidelines

Brent Royal-Gordon brent at architechies.com
Fri Dec 11 03:40:40 CST 2015


>> Has any thought been given to making some of the design guidelines required by the compiler, instead of just guidelines? One guideline in particular I am thinking of is:
>> 
>> "Follow case conventions: names of types, protocols and enum cases are UpperCamelCase. Everything else is lowerCamelCase.”
>> 
>> As a teacher, I have to remind my students of this convention several times a day, mostly because students learn and use different languages (with different conventions) at the same time. After nil unwrapping, inconsistent casing is probably the #2 source of bugs my students write.
> 
> I think we’d have to carefully consider the exact policies that we support out of the box, but I’m not completely opposed to this sort of feature.  It should also only apply to declarations, not uses of values (e.g. you should be able to “use” a misnamed decl imported from a C header).
> 
> I’d also suggest that this produce a warning for violations, not an error.

Does Swift have a general policy that it should be possible to silence any warning the compiler emits?

If so, I might tie this to a pragma (“strict caps”/“no strict caps”?). I’m not sure if it should be on by default in source files, but I think it definitely should be in the REPL (and in Xcode playgrounds) so that students learn good style.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list