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

Alex Blewitt alex.blewitt at gmail.com
Sat Dec 5 14:54:39 CST 2015



Sent from my iPhat 6

> On 5 Dec 2015, at 19:23, Adrian Kashivskyy <adrian.kashivskyy at 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. 

Alex

> Pozdrawiam – Regards,
> Adrian Kashivskyy
> 
>> Wiadomość napisana przez Harlan Haskins <harlan at 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 at gmail.com> wrote:
>>> 
>>> Amir, you may be interested in SwiftLint: https://github.com/realm/SwiftLint
>>> 
>>> 
>>> 
>>>> On Sat, Dec 5, 2015 at 1:43 PM, Amir Michail <amichail at gmail.com> wrote:
>>>> 
>>>>> On Dec 5, 2015, at 8:14 AM, Austin Zheng <austinzheng at 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 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> 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> 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
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> 
>>>>>>  _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>>>  _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/38c0f194/attachment.html>


More information about the swift-evolution mailing list