Enforcing guidelines


(Steven Van Impe) #1

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.

···

---
Steven Van Impe
Lecturer @ University College Ghent, Belgium
@svanimpe


(Chris Lattner) #2

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.

-Chris

···

On Dec 10, 2015, at 12:45 AM, Steven Van Impe via swift-evolution <swift-evolution@swift.org> wrote:

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.


(Brent Royal-Gordon) #3

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


(Douglas Gregor) #4

We should have such a policy, and Clang’s approach to handling warnings is a fairly good model:

  http://clang.llvm.org/docs/UsersManual.html

But, nobody has signed up to design/implement a warning opt-in/opt-out/escalation mechanism for the Swift compiler.

  - Doug

···

On Dec 11, 2015, at 1:40 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

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?


(Jason Dusek) #5

What if there were a kind of quoting for non-conforming names? For example,
instead of:

PQlibVersion()

one writes:

`PQlibVersion`()

This would have the effect of marking out non-conforming, weird code
explicitly.

(It might be the case that only a single leading backtick, in the manner of
Lisp quoting, is better in practice; and I don't know enough about the
grammar of Swift to say that backtick is the best choice.)

Best Regards,
Jason Dusek

···

On Fri, 11 Dec 2015 at 13:14, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 11, 2015, at 1:40 AM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:

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?

We should have such a policy, and Clang’s approach to handling warnings is
a fairly good model:

http://clang.llvm.org/docs/UsersManual.html

But, nobody has signed up to design/implement a warning
opt-in/opt-out/escalation mechanism for the Swift compiler.

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution