On projects I've been working on I started using "prettier" fro JavaScript and it made a huge difference to code consistency across the team, which was great, but my favourite benefit (that I'm not sure I've seen mentioned much here) is I can write code faster if I don't have to format it. Being able to just type without worrying about it, then hit save and it jumps into place, means if I'm working on files without automatic formatters I now feel like I'm doing a machine's job tidying things up.
Having said that - whilst I use black on all of my python projects, it's not had anywhere near as much of a positive impact as prettier has on JavaScript because: - python is generally more readable and consistent naturally than JavaScript - significant whitespace in python means you still spend time manually formatting code so you save less time than with JavaScript - I've found black to be unreliable - it silently fails on quite a few of my files - prettier is smarter about allowing you to add whitespace to make things like lists more readable, but black is 100% fixed in its ways The best thing about automatic formatters, in my opinion, is even if you don't like the style at least you don't have to talk about it any more! And you tend to get used to it eventually. On Mon, 22 Apr 2019 at 19:10, <[email protected]> wrote: > I wonder if there's a middle ground between minimizing code churn and > having a standardized formatter. Our team recently switched to yapf after > carefully configuring a .style.yapf file that's included in the root > directory of every new repo. Once that config file is done, the workflow > for yapf vs an unconfigurable formatter is identical. > > > I experimented a bit with the following .style.yapf settings on the django > codebase and think the output is as good as black's without some of the > arbitrariness of string quotes: > > [style] > based_on_style = pep8 > column_limit=100 > i18n_function_call=['_'] > blank_line_before_nested_class_or_def=True > join_multiple_lines=False > indent_dictionary_value=False > > coalesce_brackets=True > dedent_closing_brackets=True > align_closing_bracket_with_visual_indent=False > space_between_ending_comma_and_closing_bracket=False > > split_complex_comprehension=True > split_before_first_argument=True > split_before_logical_operator=False > split_before_bitwise_operator=False > split_arguments_when_comma_terminated=True > split_before_expression_after_opening_paren=True > split_before_named_assigns=True > > > Yapf currently has more stars than black, but whether black has more > momentum or not, who can say. > > > On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote: >> >> >>> I'm just saying that if "As contributor, I can haz automatic code >>> formatter to lower the barrier" is precisely the story you want to solve, >>> then black may not be the only solution you want to consider deeply ;) >>> >>> >> Jamie, sure, I wasn't responding directly to you about this, more to the >> general people arguing against blacks style choices. I would happily >> consider alternatives to black - although (without any formal research to >> back this claim) it does feel like black has the most community support. >> >> My point is mostly that if there is a growing community consistency >> through black then I'd be hesitant to choose another tool that goes against >> this. >> >> >> >>> > Consistency in the end is the most important thing (even PEP8 agrees >>> > there). >>> >>> Not sure where you got that impression: >>> https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds >>> <https://www.google.com/url?q=https%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds&sa=D&sntz=1&usg=AFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw> >>> >>> Pep8 clearly states consistency is less important then readability (it's >>> the >>> first thing mentioned and mentioned repeatedly that you can use as an >>> argument >>> to break consistency). And this is the primary advantage of black, since >>> readability is hard to quantify (and therefore lint or format) and I >>> think >>> this is where black has succeeded (by breaking consistency where it is >>> needed). >>> I mostly follow the discussion with interest from the sidelines, but >>> just >>> wanted to correct this consistency argument: if you want consistent >>> code, go >>> with autopep8, it'll keep your lines consistent below 79 characters and >>> quite >>> an unreadable mess. >>> -- >>> >> >> Thanks for the correction Melvyn, you're right - aside from readability >> and backwards compatibility consistency is important. >> >> I'd also note the irony of using PEP8 to argue for consistency with a >> tool that is (at least on line length) inconsistent with PEP8. Although I >> really don't want to start a debate on line length. >> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/444c7f75-ddfd-4a56-ab23-bb70dd9d877b%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/444c7f75-ddfd-4a56-ab23-bb70dd9d877b%40googlegroups.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 [email protected]. To post to this group, send email to [email protected]. 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/CAMyx3A3LoAtWAA503ooq779TABQPRre1nTwGhC6vX%3DF-3oXUwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
