[swift-evolution] "bad smells" should be compiler errors with suggestions on how to fix them

[Austin Zheng]

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 at 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 at me.com <mailto:adrian.kashivskyy at 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 Netguru
>> 
>>> Wiadomość napisana przez Amir Michail <amichail at gmail.com <mailto:amichail at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/c451d368/attachment.html>