Proposal: Require functions to have a cyclomatic complexity of <= 10.


(Amir Michail) #1

I think that this one metric built into the language would have a huge impact on Swift development and for the better.


(David Turnbull) #2

The language doesn't have to evolve to make this part of the code analyzer.
I don't need cyclomatic complexity analysis in the language or the regular
build process. Better to compile faster.

-david

···

On Sun, Jan 31, 2016 at 8:45 AM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

I think that this one metric built into the language would have a huge
impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Robert Widmann) #3

I agree. It would be awesome to have a code linter that takes this into account though, but I don't see it as a full-fledged sema phase.

~Robert Widmann

2016/01/31 12:34、David Turnbull via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

The language doesn't have to evolve to make this part of the code analyzer. I don't need cyclomatic complexity analysis in the language or the regular build process. Better to compile faster.

-david

On Sun, Jan 31, 2016 at 8:45 AM, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:
I think that this one metric built into the language would have a huge impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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


(David Sweeris) #4

-1 because 64k isn't actually always enough for everyone.

- Dave Sweeris

···

On Jan 31, 2016, at 08:45, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

I think that this one metric built into the language would have a huge impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jonathan Tang) #5

This would also be very restrictive on a lot of common & not-unreasonable
patterns. A 5-way switch-case with a guard statement in each case has a
complexity of 10, but few people would find it unreadable. Implementing
the HTML5 spec, even if you break each state up into its own function,
often requires case statements with 20-30 branches, and the adoption agency
algorithm itself has cyclomatic complexity > 10. An autogenerated lexer
can have hundreds of branches within a function, but since it is generated
by code and the programmer just looks at a bunch of regexps, nobody cares.

I would love to see some of the compiler information (token stream, parse
tree, type analysis, and CFG) exposed as libraries, though, for linters and
other semantic analysis tools to use.

···

On Sun, Jan 31, 2016 at 11:40 AM, Developer via swift-evolution < swift-evolution@swift.org> wrote:

I agree. It would be awesome to have a code linter that takes this into
account though, but I don't see it as a full-fledged sema phase.

~Robert Widmann

2016/01/31 12:34、David Turnbull via swift-evolution <
swift-evolution@swift.org> のメッセージ:

The language doesn't have to evolve to make this part of the code
analyzer. I don't need cyclomatic complexity analysis in the language or
the regular build process. Better to compile faster.

-david

On Sun, Jan 31, 2016 at 8:45 AM, Amir Michail via swift-evolution < > swift-evolution@swift.org> wrote:

I think that this one metric built into the language would have a huge
impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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


(John Randolph) #6

-1. Same reason.

-jcr

···

On Jan 31, 2016, at 3:10 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

-1 because 64k isn't actually always enough for everyone.


(Amir Michail) #7

-1 because 64k isn't actually always enough for everyone.

I’ve been using the implementation of cyclomatic complexity in swiftlint and have not encountered any limitations that I couldn’t overcome by refactoring my code.

···

On Jan 31, 2016, at 6:10 PM, David Sweeris <davesweeris@mac.com> wrote:

- Dave Sweeris

On Jan 31, 2016, at 08:45, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

I think that this one metric built into the language would have a huge impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Sweeris) #8

You’ve missed my point… (although, to be fair, it should’ve read “640k”)

Saying, as a language restriction, that you can’t have a cyclomatic complexity > 10 is like saying that you can’t have more than x functions in a file, y lines of code in a function, or n properties in a struct. Why? What’s the point?

- Dave Sweeris

···

On Feb 1, 2016, at 08:28, Amir Michail <a.michail@me.com> wrote:

On Jan 31, 2016, at 6:10 PM, David Sweeris <davesweeris@mac.com> wrote:

-1 because 64k isn't actually always enough for everyone.

I’ve been using the implementation of cyclomatic complexity in swiftlint and have not encountered any limitations that I couldn’t overcome by refactoring my code.

- Dave Sweeris

On Jan 31, 2016, at 08:45, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

I think that this one metric built into the language would have a huge impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Craig Cruden) #9

Code analytics, code style enforcement can be done by linters — and as such should not be enforced through the language compiler itself. Trying to foresee all possible scenarios, is fraught with unintended consequences.

···

On 2016-02-01, at 23:28:36, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 31, 2016, at 6:10 PM, David Sweeris <davesweeris@mac.com> wrote:

-1 because 64k isn't actually always enough for everyone.

I’ve been using the implementation of cyclomatic complexity in swiftlint and have not encountered any limitations that I couldn’t overcome by refactoring my code.

- Dave Sweeris

On Jan 31, 2016, at 08:45, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

I think that this one metric built into the language would have a huge impact on Swift development and for the better.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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