Yeah, it's very common to confuse style with formatting. Not having to
think is a productivity win when and only when you don't care about your
product's quality (in which case I'd suggest using generators and stop
thinking about code altogether). Language is a communication tool, a
programming language is a tool programmers use to talk to each other, and
code passed through autoformatters (especially if author _didn't think_
about style) is harder to understand then written by thinking humans. It's
pretty much like trying to stop thinking about style in English -- by using
some processor to put your commas and whitespace in place you can generate
something that is usually possible to understand, at least for the most
part, but that and _good style_ would still be worlds apart (yes, natural
languages are different, it's much easier to make things worse there, but
it's not any easier to make things better in programming languages).

There are situations where compromising style for formatting is acceptable
and even a good idea, I don't think here is one of them. Removing a
significant expressive tool from a language just to ensure your whitespace
is arranged according to some arbitrary rules is about as
counter-productive and pointless as it can get. Not because sometimes it
produces some bad results but exactly because it prevents humans from
thinking and expressing themselves properly. What would you think about
some processor renaming all your variables so that you don't have to think
about naming them? Must be even better for productivity.

Ivan.

On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton <josh.smea...@gmail.com>
wrote:

> Ivan, what you’re talking about is subjective code formatting, and lends
> itself to extreme bikeshedding and little consensus. Django already has a
> formatting standard that mergers try to enforce at review and commit time.
> But it’s time consuming, prone to missing things, and requires lots of back
> and forth.
>
> Not having to think of formatting at all, either as a developer or
> reviewer, is a major productivity win. Even if some of the formatting
> choices are not agreeable.
>
> On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers
> (Contributions to Django itself) <django-developers@googlegroups.com>
> wrote:
>
>> My two cents: black's mostly ok but I'm against any auto-formatting. Code
>> style is much more than whitespace arrangement, it requires looking,
>> creative thinking, judging, and sometimes actually compromising rules and
>> looks for readability while the usual attitude with such tools is "I have
>> this autoformatter tool so I don't have to think about style anymore, see,
>> all my whitespace is nice and shining". Using some helpers in your favorite
>> editor is great but relying on automatics without looking is almost
>> completely counter-productive.
>>
>> I find that PR autocommenter is a great way to keep issues detectable by
>> flake8/pylint to a minimum.
>>
>> Ivan.
>>
>> On Sat, Apr 13, 2019 at 6:35 PM Herman S <herman.schis...@gmail.com>
>> wrote:
>>
>>> Hi.
>>>
>>> I propose that Django starts using 'black' [0] to auto-format all Python
>>> code.
>>> For those unfamiliar with 'black' I recommend reading the the projects
>>> README.
>>> The short version: it aims to reduce bike-shedding and non value-adding
>>> discussions; saving time reviewing code; and making the barrier to entry
>>> lower
>>> by taking some uncompromissing choices with regards to formatting.  This
>>> is
>>> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>>>
>>> Personally I first got involved contributing to Django couple of weeks
>>> back,
>>> and from anecdotal experience I can testify to how 'formatting of code'
>>> creates
>>> a huge barrier for entry. My PR at the time went multiple times back and
>>> forth
>>> tweaking formatting. Before this, I had to research the style used by
>>> exploring
>>> the docs at length and reading at least 10-20 different source – and
>>> even those
>>> were not always consistent. At the end of the day I felt like almost 50%
>>> of the
>>> time I used on the patch was not used on actually solving the issue at
>>> hand.
>>> Thinking about code formatting in 2019 is a mental energy better used
>>> for other
>>> things, and it feels unnecessary that core developers on Django spend
>>> their time
>>> "nit-picking" on these things.
>>>
>>> I recently led the efforts to make this change where I work. We have a
>>> 200K+
>>> LOC Django code-base with more than 30K commits. Some key take-aways: it
>>> has
>>> drastically changed the way we work with code across teams, new
>>> engineers are
>>> easier on-boarded, PR are more focused on architectural choices and
>>> "naming
>>> things", existing PRs before migration had surprisingly few conflicts
>>> and were
>>> easy to fix, hot code paths are already "blameable" and it's easy to
>>> blame a
>>> line of code and go past the "black-commit", and lastly the migration
>>> went
>>> without any issues or down-time.
>>>
>>> I had some really fruitful discussions at DjangoCon Europe this week on
>>> this
>>> very topic, and it seems we are not alone in these experiences. I would
>>> love to
>>> hear from all of you and hope that we can land on something that will
>>> enable
>>> *more* people to easier contribute back to this project.
>>>
>>> I've set up how this _could_ look depending on some configurables in
>>> Black:
>>>
>>> * Default config: https://github.com/hermansc/django/pull/1
>>> * Line length kept at 119: https://github.com/hermansc/django/pull/3
>>> * Line length kept at 119, no string normalization:
>>> https://github.com/hermansc/django/pull/2
>>>
>>> Please have a look at the Black documentation. It explains the benefits
>>> better
>>> than I possibly could do here.
>>>
>>> With kind regards,
>>> Herman Schistad
>>>
>>> [0]: https://github.com/ambv/black
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers  (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADPNjZ52oJ-vQL1L27VH2a4%2Bd82q4K0z7PGXv8xwokXtexy3%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
          • ... Emil Madsen
            • ... Florian Apolloner
      • ... Dmitriy Sintsov
        • ... Kye Russell
          • ... Josh Smeaton
  • R... Scot Hacker
    • ... Adam Johnson
      • ... Florian Apolloner
  • R... 'Ivan Anishchuk' via Django developers (Contributions to Django itself)
    • ... Josh Smeaton
      • ... 'Ivan Anishchuk' via Django developers (Contributions to Django itself)
        • ... Josh Smeaton
          • ... Dan Davis
            • ... Tobias Kunze
              • ... Tom Forbes
              • ... Jon Dufresne
            • ... Brice Parent
  • R... Matthias Kestenholz
  • R... Jani Tiainen
    • ... Luke Plant
      • ... Tim Graham

Reply via email to