Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at Netguru
Wiadomość napisana przez Amir Michail <amichail@gmail.com> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com <mailto:adrian.kashivskyy@me.com>> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
This is a bit pedantic. Every programming language and associated community (that I am aware of) makes a distinction between the set of inputs accepted by the compiler/interpreter, and the set of inputs constrained by whatever community conventions have evolved over time.
Anyways, I am -1 on this as well for the same reasons Adrian brought up: endless disagreement over what constitutes "OOP", "functional", etc programming style, and the loss of the ability to leverage Swift in a multi-paradigm fashion without ugly boilerplate.
Austin
On Dec 5, 2015, at 5:43 AM, Amir Michail <amichail@gmail.com> wrote:
On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
All programming languages are already enforcing subjective views about best practice in one form or another.
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com <mailto:adrian.kashivskyy@me.com>> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
All programming languages are already enforcing subjective views about best practice in one form or another.
On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng@gmail.com> wrote:
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com <mailto:adrian.kashivskyy@me.com>> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
Amir, you may be interested in SwiftLint: GitHub - realm/SwiftLint: A tool to enforce Swift style and conventions.
On Sat, Dec 5, 2015 at 1:43 PM, Amir Michail <amichail@gmail.com> wrote:
On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng@gmail.com> wrote:
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
All programming languages are already enforcing subjective views about best practice in one form or another.
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com <mailto:adrian.kashivskyy@me.com>> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
SwiftLint looks really nice, but one thing I'd really like is automatic formatting. I'd absolutely like to see clang-format adapted with Swift support. Maybe the SwiftLint people can, now that Swift is open source, contribute the bulk of the SwiftLint project directly into clang-format.
On Dec 5, 2015, at 9:09 AM, Paul Young <paulyoungonline@gmail.com> wrote:
Amir, you may be interested in SwiftLint: GitHub - realm/SwiftLint: A tool to enforce Swift style and conventions.
On Sat, Dec 5, 2015 at 1:43 PM, Amir Michail <amichail@gmail.com> wrote:
On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng@gmail.com> wrote:
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
All programming languages are already enforcing subjective views about best practice in one form or another.
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
SwiftLint looks really nice, but one thing I'd really like is automatic formatting.
That's a feature of IDE, not the language itself.
Pozdrawiam – Regards,
Adrian Kashivskyy
Wiadomość napisana przez Harlan Haskins <harlan@harlanhaskins.com> w dniu 05.12.2015, o godz. 17:52:
SwiftLint looks really nice, but one thing I'd really like is automatic formatting. I'd absolutely like to see clang-format adapted with Swift support. Maybe the SwiftLint people can, now that Swift is open source, contribute the bulk of the SwiftLint project directly into clang-format.
On Dec 5, 2015, at 9:09 AM, Paul Young <paulyoungonline@gmail.com <mailto:paulyoungonline@gmail.com>> wrote:
Amir, you may be interested in SwiftLint: GitHub - realm/SwiftLint: A tool to enforce Swift style and conventions.
On Sat, Dec 5, 2015 at 1:43 PM, Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> wrote:
On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
All programming languages are already enforcing subjective views about best practice in one form or another.
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com <mailto:adrian.kashivskyy@me.com>> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com <mailto:amichail@gmail.com>> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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
SwiftLint looks really nice, but one thing I'd really like is automatic formatting.
That's a feature of IDE, not the language itself.
Not necessarily. The existence of "go fmt" has resulted in teams running it as a pre-commit translation and as a way of standardising across all users, regardless of IDEs. Otherwise you end up with multiple IDEs (like Eclipse and IntelliJ) which do formatting slightly differently and lead to all manner of pointless arguments.
Letting "the IDE" do formatting is fine provided there is a maximum of one IDE.
Alex
Sent from my iPhat 6
On 5 Dec 2015, at 19:23, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
Pozdrawiam – Regards,
Adrian KashivskyyWiadomość napisana przez Harlan Haskins <harlan@harlanhaskins.com> w dniu 05.12.2015, o godz. 17:52:
SwiftLint looks really nice, but one thing I'd really like is automatic formatting. I'd absolutely like to see clang-format adapted with Swift support. Maybe the SwiftLint people can, now that Swift is open source, contribute the bulk of the SwiftLint project directly into clang-format.
On Dec 5, 2015, at 9:09 AM, Paul Young <paulyoungonline@gmail.com> wrote:
Amir, you may be interested in SwiftLint: GitHub - realm/SwiftLint: A tool to enforce Swift style and conventions.
On Sat, Dec 5, 2015 at 1:43 PM, Amir Michail <amichail@gmail.com> wrote:
On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng@gmail.com> wrote:
Rather than having the compiler attempt to enforce (subjective, constantly evolving) best practices, maybe we should think about ways to make it easier for people to write their own linters that can integrate well with the rest of the toolchain.
All programming languages are already enforcing subjective views about best practice in one form or another.
Austin
On Dec 5, 2015, at 5:02 AM, Amir Michail <amichail@gmail.com> wrote:
The problem is that solo developers rarely have the self-discipline to avoid obviously bad code style.
On Dec 5, 2015, at 5:15 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
I'm -1 on that – compiler should guarantee the program correctness, not style correctness.
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.)
I almost immediately thought of whole projects where people would put `@style(hybrid)` at the top to get rid of troublesome compiler warnings, or put the "style exception" annotation for the whole file. This would become "public static void main" of Swift.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
My greatest concern is about who will define what "bad smell" and individual styles look like. Coding style is a very subjective matter, and should not be enforced by compiler or any manifest (that's why I'm against strict code style guides as well).
Besides, enforcing one style per source file would loose one of the best features of Swift – diversity. Swift is a multi-paradigm language, influenced by the best features of many other modern languages. It is imperative, functional, object-oriented and protocol-oriented at the same time. We'd loose that variety.
Regards,
Adrian Kashivskyy
iOS Developer at NetguruWiadomość napisana przez Amir Michail <amichail@gmail.com> w dniu 05.12.2015, o godz. 00:53:
Perhaps you could specify a programming style at the top of each file (e.g., OOP, functional, hybrid, etc.) and code that doesn’t match that style would result in a compiler error.
For example, a long method could trigger an error along with suggestions for refactorings to fix this “bad smell”.
If you don’t want to fix the problem, you could use a style exception construct to surround the code in question and it would get rid of the compile error.
_______________________________________________
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_______________________________________________
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
SwiftLint looks really nice, but one thing I'd really like is automatic formatting.
That's a feature of IDE, not the language itself.
Not necessarily. The existence of "go fmt" has resulted in teams running it as a pre-commit translation and as a way of standardising across all users, regardless of IDEs. Otherwise you end up with multiple IDEs (like Eclipse and IntelliJ) which do formatting slightly differently and lead to all manner of pointless arguments.
Letting "the IDE" do formatting is fine provided there is a maximum of one IDE.
This is perhaps out of scope for this group, but I’ve actually long wanted languages to move in a direction where indentation is not present at all in the source file—your git repo might never have an instance of /\n[ \t]/ in it. Instead, it’s automatically added by the IDE while displaying the code, based on the block beginnings and endings present in the actual source. This would make incorrectly indented code a thing of the past; it would also be obvious when you’re missing a curly bracket, because your code would be indented all wrong. And it would end the destructive whitespace wars, because everyone could just set their IDE to do whatever they liked best.
--
Brent Royal-Gordon
Architechies
Just to chime in on this thread with some guidelines for thought:
1) The compiler does have some code smell warnings (e.g. unmutated var -> let).
2) It is really important that these be warnings, not errors. Turning them into errors makes refactoring code a pain (as commonly complained about in the go community).
3) By doing these sorts of things, the compiler needs to be conservative in its policies - the policies that it enforces has to be unquestionably the right thing to do.
Separate from compiler-enforced policies, I’d *love* to see someone tackle implementing a "go fmt” analog that reformats Swift code into a standard style, as well as a “clang format” tool that could be used by IDEs for on-the-fly editing of code, as well as a “linter” / static analysis tool which can flag potential issues while having a higher tolerance for false positives. These should be separate from the “always on” compiler diagnostics though.
-Chris
On Dec 5, 2015, at 12:54 PM, Alex Blewitt via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhat 6
On 5 Dec 2015, at 19:23, Adrian Kashivskyy <adrian.kashivskyy@me.com <mailto:adrian.kashivskyy@me.com>> wrote:
SwiftLint looks really nice, but one thing I'd really like is automatic formatting.
That's a feature of IDE, not the language itself.
Not necessarily. The existence of "go fmt" has resulted in teams running it as a pre-commit translation and as a way of standardising across all users, regardless of IDEs. Otherwise you end up with multiple IDEs (like Eclipse and IntelliJ) which do formatting slightly differently and lead to all manner of pointless arguments.
Letting "the IDE" do formatting is fine provided there is a maximum of one IDE.
How would you do code review then? ;)
Regards,
Adrian Kashivskyy
iOS Developer at Netguru
Wiadomość napisana przez Brent Royal-Gordon <brent@architechies.com> w dniu 05.12.2015, o godz. 22:10:
SwiftLint looks really nice, but one thing I'd really like is automatic formatting.
That's a feature of IDE, not the language itself.
Not necessarily. The existence of "go fmt" has resulted in teams running it as a pre-commit translation and as a way of standardising across all users, regardless of IDEs. Otherwise you end up with multiple IDEs (like Eclipse and IntelliJ) which do formatting slightly differently and lead to all manner of pointless arguments.
Letting "the IDE" do formatting is fine provided there is a maximum of one IDE.
This is perhaps out of scope for this group, but I’ve actually long wanted languages to move in a direction where indentation is not present at all in the source file—your git repo might never have an instance of /\n[ \t]/ in it. Instead, it’s automatically added by the IDE while displaying the code, based on the block beginnings and endings present in the actual source. This would make incorrectly indented code a thing of the past; it would also be obvious when you’re missing a curly bracket, because your code would be indented all wrong. And it would end the destructive whitespace wars, because everyone could just set their IDE to do whatever they liked best.
--
Brent Royal-Gordon
Architechies
I have a fairly minimal held-together-by-bandaids linter I put together:
I have hesitated to develop it much further because I didn't want to be committed to inter-process SourceKit hacking and did not yet have access to a reliable parse tree. In its current state, it's a regex-based line-by-line scan.
The rules it follows are here: https://github.com/erica/testlint/blob/master/testlint/sources/Linter.m
with fairly copious commenting
-- Erica
On Dec 5, 2015, at 11:15 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Separate from compiler-enforced policies, I’d *love* to see someone tackle implementing a "go fmt” analog that reformats Swift code into a standard style, as well as a “clang format” tool that could be used by IDEs for on-the-fly editing of code, as well as a “linter” / static analysis tool which can flag potential issues while having a higher tolerance for false positives. These should be separate from the “always on” compiler diagnostics though.
-Chris
Separate from compiler-enforced policies, I’d *love* to see someone tackle
implementing a "go fmt” analog that reformats Swift code into a standard
style, as well as a “clang format” tool that could be used by IDEs for
on-the-fly editing of code, as well as a “linter” / static analysis tool
which can flag potential issues while having a higher tolerance for false
positives. These should be separate from the “always on” compiler
diagnostics though.
I agree that a compiler cannot be too stylistically opinionated, and that
an opt-in, standalone linter/formatter is preferable.
As others have mentioned, there's a community-built tool called SwiftLint
<https://github.com/realm/SwiftLint> that does much of this today. It's an
AST-assisted tool to enforce code style conventions & automatically correct
certain violations. Rules can be enabled/disabled and parameterized either
inline in the source or via a YAML configuration file.
One of the tool's main limitations so far is that the Swift AST it operates
on is obtained from a reverse-engineered SourceKit interface and is
incomplete.
Myself and other SwiftLint contributors intend to replace the
reverse-engineered SourceKit backend with more official tooling that was
just open sourced, which will enable SwiftLint to do things like an
opinionated go-fmt/clang-format style formatting (source->AST-source) and
some types of static analysis like identifying cyclomatic complexity.
One thing I'd like to discuss with relevant Swift project owners (notably
Argyrios and Chris) is the possibility of moving SwiftLint development into
github.com/apple, which would increase the tool's exposure and pace of
development. I hope to make a more official proposal for how that
transition could happen in the upcoming week, probably in swift-dev.
On Sun, Dec 6, 2015 at 9:07 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:
On Dec 5, 2015, at 11:15 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
> Separate from compiler-enforced policies, I’d *love* to see someone
tackle implementing a "go fmt” analog that reformats Swift code into a
standard style, as well as a “clang format” tool that could be used by
IDEs for on-the-fly editing of code, as well as a “linter” / static
analysis tool which can flag potential issues while having a higher
tolerance for false positives. These should be separate from the “always
on” compiler diagnostics though.
>
> -ChrisI have a fairly minimal held-together-by-bandaids linter I put together:
I have hesitated to develop it much further because I didn't want to be
committed to inter-process SourceKit hacking and did not yet have access to
a reliable parse tree. In its current state, it's a regex-based
line-by-line scan.The rules it follows are here:
https://github.com/erica/testlint/blob/master/testlint/sources/Linter.m
with fairly copious commenting-- Erica
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution