19 ms·
Black, the uncompromising Python code formatter, is stable
- throwawayt215 5y agoHooray! Loosely related - This is Python pip. Trail of Bits has a tool pip-audit that audits Python environments and dependency trees for known vulnerabilities. https://github.com/trailofbits/pip-audit https://github.com/trailofbits/pip-audit
- woodruffw 5y agoNot that I don't appreciate the shoutout (I'm one of the developers of pip-audit), but what's the connection? Is it because black is installed via pip?
- throwawayt215 5y agoYeah. Thanks for pip-audit
- crlees 5y agoI'm pleased to announce that Black is finally non-beta software! :party:! Change log: https://black.readthedocs.io/en/latest/change_log.html https://black.readthedocs.io/en/latest/change_log.html Going forward we'll follow our stability policy (https://black.readthedocs.io/en/latest/the_black_code_style/index.html#stability-policy https://black.readthedocs.io/en/latest/the_black_code_style/...). Work continues as usual with bugfixes and enhancements, but style changes are now introduced under our new `--preview` CLI switch. This allows us to evolve Black's style without too much disruption to users that want consistency. The default style is updated yearly. Thanks to our maintainers for orchestrating the efforts, especially to our most recent reinforcement Batuhan (@isidentical) who was responsible for our match statement support! A hearty thank you to all of our contributors for pushing Black forward, and to our users for being the reason we do it!
- scrollaway 5y agoCongratulations. I'm a Python developer of 17+ years and Black is truly a huge blessing in the Python ecosystem. That said, I'm a little sad to see it's gone stable without adding support for tabs, which would be extremely simple to add at this point (cf. https://github.com/jleclanche/tan/commit/e23c038167528bdacddd6779c6b4234e2634cfa3 https://github.com/jleclanche/tan/commit/e23c038167528bdacdd...). I have a lot of people using this tab-capable fork, that I did not advertise anywhere. Łukasz seems to have a personal grudge against tabs which may be why the issue for tab support was closed early on, but there's a plethora of good reasons to support it behind a flag. I don't want to rehash those arguments here on HN but you think you could re-think the approach a bit? I'd be happy to do a PR if it's not getting rejected right away with "no discussion allowed" like the last one was (before Black was moved to PSF maintainership).
- deleted 5y ago[deleted]
- wenc 5y agoI think one of the great benefits of Black is that it is opinionated. Giving folks the option to select the type of indentation blunts the benefits. If you have a huge code base which mixes tabs and spaces it’s going to be hard to diff and merge code (or even reuse code snippets).
- scrollaway 5y agoThe point of black is that you run it on the same codebase with the same parameters. Prettier works the exact same way and does have --use-tabs as a parameter. Nobody died. No codebase ended up with mixed tabs and spaces from it. Codebases either do --use-tabs or don't. Like I said, there are a lot of reasons to allow for this. For one thing, tabs are an accessibility feature, but also it's impossible to use Black in an environment that prefers tabs. Whereas there's no such thing as "an environment that prefers exactly two spaces after every comma inside tuples", thus you don't need an option for this.
- dang 5y agoPast related threads: Black – Uncompromising Python code formatter - https://news.ycombinator.com/item?id=19939806 https://news.ycombinator.com/item?id=19939806 - May 2019 (244 comments) Linting 400kLOC of Python Code with Black - https://news.ycombinator.com/item?id=18536731 https://news.ycombinator.com/item?id=18536731 - Nov 2018 (1 comment) Black: An uncompromising Python code formatter - https://news.ycombinator.com/item?id=17151813 https://news.ycombinator.com/item?id=17151813 - May 2018 (255 comments)
- woodruffw 5y agoCongratulations to the Black authors! It's a wonderful tool, probably the first one I install when creating a local Python development environment.
- hivacruz 5y agoThis is a great tool. I wish there was some settings to use single quotes instead of double quotes.
- nopenopenopeno 5y agoThere probably is, if you use another formatter that isn’t Black.
- xapata 5y agoI like yapf.
- crlees 5y agoThere is: -S, --skip-string-normalization Don't normalize string quotes or prefixes.
- hivacruz 5y agoIIRC, the -S only avoid single quotes to get switched to double quotes. What I meant was allowing Black to switch double-quotes to single quotes automatically.
- j1elo 5y agoFunny that this is a common reaction against opinionated tools: "I wish there was a configurable option to apply my opinions" But the whole idea is that you should learn to suppress your ego and let the tool be the one dictating stylistic choices... Like the sibling comment mentions: Dusty Phillips, writer: "Black is opinionated so you don’t have to be."
- ForHackernews 5y ago"My opinion is the correct one" - Author of some tool
- 5y ago
- iddan 5y agoThis is exciting! Can it now be a plug-in for Prettier?
- formerly_proven 5y ago> Black prefers [i.e. converts] double quotes (" and """) over single quotes (' and '''). Can someone explain this to me? Why would you ever prefer " over ' in a language where both can be used equally?
- nopenopenopeno 5y agoIt’s easier and faster to differentiate between “ and ` than between ‘ and `.
- floober 5y agoUniformity, presumably
- odiroot 5y agoI prefer them too. Makes it easy to notice than single ones. It's just a personal preference, there's no big logic behind it.
- Teongot 5y agoBecause "don't" is easier to read than 'don\'t'
- JackFr 5y agoWhen you’re embedding SQL in a string, a you use ‘ a lot more than “. Not the only use case, but one to give some consideration.
- throwaway894345 5y agoI think that’s only MySQL. Postgres uses double quotes for identifiers and single quotes for literals. EDIT: I misinterpreted that single quote as a backtick. In any case, both single and double quotes are common in SQL, but single quotes are a bit more common.
- iqanq 5y agoAnd 'do not' is easier to read than both :)
- EddieLomax 5y agoIt's now enabled by default in IPython, for better or worse: https://github.com/ipython/ipython/pull/13397 https://github.com/ipython/ipython/pull/13397
- ccordoba12 5y agoThat will be reverted in the next version, i.e. it'll be optional.
- teddyh 5y ago“the next release will likely revert it” — Matthias Bussonnier, https://github.com/ipython/ipython/issues/13463#issuecomment-1014449047 https://github.com/ipython/ipython/issues/13463#issuecomment...
- kzrdude 5y agoGreat, I'm sure it will end up with a good solution eventually. Unfortunate that it had to be this heated about this change. R. Hettinger needed to learn to always be graceful when commenting or criticizing the work of others, especially volunteers. And we all saw how wild the difference is in engagement for a project like ipython between the "normal" level and the "viral" level. Users are just using it and depending on it, never interacting with the project, but if something attracts attention it can be like a thousand flies flocking to it. Often when something gets negative attention..
- dvalc 5y agoThere are several main personalities in the python-dev space: 1) People who easily get passionate but are gentlemen when it counts. R. Hettinger is one of these. 2) People who get passionate and are politicians. GvR is one of those and he is above the CoC. 3) Vicious politicians who always remain calm. These are the most dangerous, are often mediocre and climb the ladder at various large corporations. Some of these have not contributed much. 4) Some really nice people. You generally won't see much of them in discussions. R. Hettinger is independent and honest, unlike the snake pit that runs Python.
- nopenopenopeno 5y agoThought I’d never see the day lol
- Mockapapella 5y agoFuck I love Black -- makes working with other developers amazing once you stick it in a precommit. The quote from Dusty Phillips on the homepage is perfect and has stuck with me for years. I don't have to debate with developers about their individual preferences over what's best because we can just use Black and be done with it.
- crlees 5y agoHere here! Same.
- mumblemumble 5y agoI love it even though I dislike quite a few of its formatting rules. Because the only thing worse than a slightly wonk formatting convention is spending any time at all implementing, arguing about, or otherwise worrying about formatting conventions.
- faut_reflechir 5y agoI don't love how Black doesn't let you put some clarificatory parentheses -- for instance, they get wiped from `eq_balanced = (left_hand_side == right_hand_side)` But the benefits of never wasting time on discussing inanity outweigh any specific complaints.
- rsfern 5y agoYou can disable formatting for specific lines or blocks with `# fmt: off` https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html https://black.readthedocs.io/en/stable/the_black_code_style/...
- rr808 5y agoAnyone have a foolproof way to reformatting all the code in a repo without screwing up history? I've seen some complicated commands which seem too sketchy to a git novice like myself.
- mumblemumble 5y agoDo it all in one commit. Then put that commit's (full) sha in a file named something like .git-blame-ignore-revs Then `$ git config blame.ignoreRevsFile .git-blame-ignore-revs`
- rr808 5y agoThanks, that is helpful, esp I can google that to get more docs. One issue is everyone in the team needs to do so, but its probably worth it.
- faangiq 5y agoIs there an equivalent for TS/JS? How about Java?
- _old_dude_ 5y agoprettier [1] and google-java-format [2] [1] https://prettier.io/ https://prettier.io/ [2] https://github.com/google/google-java-format https://github.com/google/google-java-format
- simonw 5y agoPrettier is the closest I've found for JavaScript.
- mmcnl 5y agoPrettier is equally amazing indeed.
- iddan 5y agoCheck out Prettier
- lelandfe 5y ago“Standard” was popular for a while but fell out of vogue. Prettier is the one to reach for these days. I’m a big fan
- simonw 5y agoAdopting Black made me realize quite how much of my coding thinking capacity had previously been spent thinking about code formatting - I used to really sweat the details about how to break up a long function call, where to put the line breaks, how to indent my dictionary literals... With Black, I don't spend a single moment thinking about that at all. I estimate I've got a 5-10% productivity boost in my time-spent-writing-code from this!
- eawoifjaiowepfj 5y agoIt's been at least a decade since I've not used an autoformatter on every piece of code ever. I didn't realize there were people who worked at places without autoformatters still.
- npage97 5y agoTo add onto this, I also found that Black works as a nice heuristic indicating to split up code when the formatted output isn't "pretty" into separate lines.
- epage 5y agoHad a similar experience when I used rustfmt (which led me to trying black). I was used to formatters that over formatted, removing newlines used to dilineate sections of code, etc. I tried rustfmt when learning Rust because I figured id learn adopt standard practices. It was revolutionary. I went from formatting as I went, even for prototyping to throwing code at my editor and letting rustfmt fix it. Big difference in productivity.
- ublaze 5y agoI remember we migrated 2+ million LoC to being formatted by Black at Dropbox. Our Livegrep instance with a custom Git blame implementation always crashed at the commit made to do the migration :-) We had to pause our merge queue because we didn't want to run into conflicts, and I remember the `git push` ended up taking a while. There was only one change that we had to make to Black to get it working on our codebase - https://github.com/psf/black/commit/024c9cab55da7bd3236fd88759c9735d6149b464 https://github.com/psf/black/commit/024c9cab55da7bd3236fd887... Glad to see it's now stable.
- ublaze 5y agoTo clarify, the slow git push was likely custom pre-receive hooks being slow.
- Operyl 5y ago`another_really_really_long_element_with_a_unnecessarily_long_name_to_describe_what_it_does_enterprise_style` hahahahaha, I love that test case.
- skrause 5y agoWhen I switched the company to Black, I reformatted the whole repository history with it. Every developer had to clone the repository again and reapply their local changes to it, but in the end it was a good choice because "blame" still works perfectly since we don't have one big reformatting commit.
- glacials 5y agoAn alternative is to use Git's blame.ignoreRevsFile[1] option to ignore specific commits when calculating blames. The downside is that although you can save the list of commits in the repo, you cannot do the same for the config setting itself, so it calls for some light automation at scale. [1]: https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
- 5y ago
- ForHackernews 5y agoStill ugly. I hate looking at code mangled by this thing. Single quotes? Fluent interfaces? Go write Go if you want ugly code you don't have to think about. Don't @ me.
- throwaway894345 5y agoPretty sure Black prefers double quotes in the main case, but what are “fluent interfaces”? Go is pretty great though, I completely understand the envy! :)
- JacobHenner 5y agohttps://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface
- throwaway894345 5y agoDoes Black inhibit method chaining? In any case, I don’t see the value in fluent interfaces—if I had to choose between an opinionated code formatter and something people do because Martin Fowler told them to do it, I would take the former every time.
- cdcarter 5y agoSure, but why would black make those hard? (It doesn't, in my experience).
- moffkalast 5y agoYeah, and I wasn't aware there was anything to format. This is Python after all, code style is enforced by compiler lol.
- captainmuon 5y agoPersonally, I don't understand the appeal of opinionated code formatters. If you don't want to discuss "taste" questions, then just don't, it doesn't matter what option you pick. If it is an important question, then you should debate it. I think you can convey meaning with subtle code style differences. Empty lines to delineate blocks. Single quotes if the string is a keyword, double quotes if it is for the user. Spaces around operators to make an expression clearer. I spend a minute or two before I commit to make the code tidy (linter and then manual tweaking) and would expect that from everybody on my team - it takes often less time than rebasing and picking good commit names, for example. But even though it annoys me slightly when I encounter Black (or god forbid, Go) used in a project, I know a lot of people like it a lot, and it is good to have the choice. So congrats to the release! :-)
- ferdowsi 5y ago> If you don't want to discuss "taste" questions, then just don't, it doesn't matter what option you pick. If it is an important question, then you should debate it. I'm personally glad to see Python development come to the same conclusion enforced by Go's opinionated tooling. That is: style questions are almost always unimportant to producing value, but teams still waste excessive time on them because of the engineering tendency to bikeshed triviata.
- mumblemumble 5y agoI think the general consensus of many people, myself included, is that it doesn't matter what the specifics are, as long as they're being applied consistently. Beyond that, it's a question of optimizing the cost/benefit ratio. The problem with most things that have to be applied manually is that they're also applied inconsistently. It's like Hungarian notation. Over time, it becomes pure noise: you can't rely on it, especially when reading someone else's code, so it's safer to just ignore it. At which point, the convention's cost/benefit is approaching infinity, because its denominator nearly zero. So I'm not sure I care if the absolute cost is small. It's still an almost complete waste of effort. The only place I've ever seen manual conventions applied consistently enough to be useful in a sustainable way is when someone's carved out their own private silo of code that is mostly only touched by them.
- 5y ago
- sergiotapia 5y agoHuge milestone for the Python community! Very happy for you guys. In Elixir, `mix format` has saved so much time across multiple projects and teams. I can't remember the last time I talked about line breaks and how to divvy up a long multiple line function header.
- robertlagrant 5y agoHere's the best thing about Black: Python has significant whitespace, so you can't just click "ignore whitespace changes" in Github diffs and it doesn't matter. You have to put up with every silly whitespace change. Until Black.
- robertlagrant 5y ago5 upvotes generate a pro tip: have your CI run black --check against the code you want formatted. That way different devs can run the formatting how they like (in tox; in a pre-commit hook; in IDE; on the command line) and CI just enforces that it happened.
- CyberShadow 5y agoUnfortunately Black will reformat code which has only been indented/outdented, causing false diffs even with "ignore whitespace changes".
- deleted 5y ago[deleted]
- robertlagrant 5y agoThat's true. What I mean is it won't keep being reformatted when everyone runs their own formatter on the code before they start working on it.
- vogre 5y agoI think every language should have such tool by default, like Go does.
- _tom_ 5y agoLong ago, I worked at a company that decided it needed coding standards. We spend two weeks arguing about coding standards. Nothing else got done. Ever since then, I am not opinionated about coding standards. The benefits do not match the costs. Although I do like the approach of "use something like black on precommit", and if you don't like it, you can reformat to your standards on check out, and be happy. It will get fixed on check in.
- voidfunc 5y agoSort of why I think Go got it right with gofmt. Its not as strict as it could be but all Go looks more or less the same and it’s because it was built into the language
- colechristensen 5y agoToo many people have too strong opinions on the subject. Some things are reasonably good ideas, many more are just arbitrary, strict rules prevent doing reasonable exceptions, and an enormous amount of time is wasted discussing the matter.
- _3u10 5y agoits the penultimate bike shedding issue. If you're coders can code it doesn't matter, and if they can't formatting their poor code isn't going to fix it.
- colechristensen 5y agoJust an off topic note on language: penultimate means second to (last, final, biggest, etc), i.e. the one before the ultimate. Perhaps an odd choice of word in context that is often misunderstood. It leads to the question “then what is the ultimate bike shedding issue?”
- _3u10 5y agoyes, ironically the word choice is to avoid bike shedding, if I said it was the ultimate issue there would be all sorts but but no, this issue, where as if it's the 2nd everyone can have their pet issue be most important and we can reach agreement on it and move forward while tabling the discussion of what is the ultimate issue. Whenever you have one of these bike shed issues in a meeting, do this: Give everyone 5 minutes to say their piece, give everyone an opportunity to ask 2 follow up questions to anyone, and a 2 minute response. Go through everyones opinion, take a vote and move on. Then set a date 1 year in the future to review/change the policy.
- oever 5y agoWe never agreed on the indents I typed a hundred tabs You go back to space and I go back to black
- h_protagonist 5y agowith these lyrics i might even like the song. awesome reference!
- gbarboza 5y agois it just me, or does the logo look _really_ similar to the ford logo?
- scrollaway 5y agoIt's meant to, as it references Henry Ford's "any color so long as it is black" quip.
- jreese 5y agoShameless self-promotion, as a former coworker of Łukasz, Black's creator: Another coworker and I have created an import sorter that fits well alongside Black, called µsort. It is designed from the ground up to be a safe, stable import sorter that won't move imports in ways that potentially change behavior of the codebase, and without needing developers to litter their code with "skip" directives. We use it in our daily formatting codemods on tens of thousands of source files every day, and just finished our 1.0 release in December. https://usort.readthedocs.io https://usort.readthedocs.io Going further, if you like enforcing both formatting and import order in your CI pipeline, I also created the project µfmt, which combines both Black and µsort into a single, atomic formatting step. This ensures there's never any conflict of opinion between the two tools, and any formatting changes are presented as a single diff result. https://ufmt.readthedocs.io https://ufmt.readthedocs.io
- chrisseaton 5y ago> that won't move imports in ways that potentially change behavior of the codebase How can that be the case? Can't Python imports have behaviour that varies on the time of the day if they want? An import could monkey patch a basic operation one day but not the next.
- jreese 5y agoAbsolutely! We're hoping that the vast majority of modules are good citizens, but we also know that the reality not perfect. That's why µsort allows you to configure a list of modules with known import-time side effects, and µsort will then treat those are barriers everywhere. https://usort.readthedocs.io/en/stable/guide.html#side-effect-imports https://usort.readthedocs.io/en/stable/guide.html#side-effec...
- stefan_ 5y agoEven better, you can overwrite the default importer to substitute your own with any behavior you want. Used in EVE Online to do their "hide the python code somewhere" scheme.
- wcdolphin 5y ago
- ed25519FUUU 5y agoI use black and love it— but only with 120 line lengths. The default of 80 is wayyy to low for the days of 4k monitors. The tricks it uses to split some things up onto new lines actually makes it less readable.
- megapolitics 5y agoI agree. I've sometimes found Black's output to be on the borderline of unreadable with the default line length of 80. My team settled on a length of 120 (the only Black config item we changed) and it has largely, though not entirely, solved that problem.
- ambivalence 5y agoAs long as you can easily review code side-by-side with line numbers intact, you're good. The default was chosen for lower resolution 13" laptop monitors to be able to display the Phabricator diff page (think: Github PR review page) without having to wrap any lines.
- mmcnl 5y agoI agree 80 is too low, but it doesn't have anything to do with 4k monitors, it's just that 80 is too short. Any longer than 120 is not readable imo. Luckily Black lets you change the line length so it's not an issue.
- ed25519FUUU 5y agoMaybe it’s different for other people but smaller text is much easier on my eyes with a 4k monitor.
- topper-123 5y ago> Black is opinionated so you don't have to be. This is a very nice quote and sums up my own view on black (and code formatters in general) nicely. Thera are things you don´t really want to have an opinion about.
- MrPowers 5y agoI like Black for normal Python code, but it seems to mangle Pandas / Dask code at times. I still use it extensively cause it doesn't seem like there are other good alternatives. I wrote a blog post on how to use Black in Jupyter Lab notebooks if anyone is interested: https://coiled.io/blog/code-formatting-jupyter-notebooks-with-black/ https://coiled.io/blog/code-formatting-jupyter-notebooks-wit... It's really nice to format a notebook with the click of a button.
- nu11ptr 5y agoI don't always like Black's results, but I do like the opinionated nature in general and that I don't have to sit and think about how I want it configured. Wouldn't mind a few knobs though.
- CyberShadow 5y agoOne missed opportunity in Black's algorithm is that it currently treats the maximum line length as a literal hard limitation in number of characters. Here is a trivialized example: to_add = [item for item in data.new_items if item not in data.old_items] to_remove = [ item for item in data.old_items if item not in data.new_items ] Although the constructs are nearly structurally identical, they can be formatted very differently, which sometimes hinders understanding them. A different approach would be to instead normalize all words to a certain fixed width. So, "to_add" and "to_remove" would have the same virtual width. A related issue is that leading indentation counts towards the width limit. This causes refactorings which simply move code around (changing its indentation level) to change the code's shape, even when the code hasn't otherwise changed. This is exacerbated by that one often needs to mold code in such a way that Black formats it in an agreeable way, but this is generally not done during refactorings, so the readability of the code suffers. I had the opportunity to write a formatter (for SQL, also unconfigurable/opinionated); it seems to successfully avoid these problems: https://github.com/CyberShadow/squelch https://github.com/CyberShadow/squelch
- IgorPartola 5y agoVery much this. I will often times deliberately line up related operations to make the meaning clear. Black then clobbers all over it.
- qbasic_forever 5y agoLine length is there for a reason, it's to fit everything on the screen. Ignoring leading spaces/indentation or giving a 'fudge factor' doesn't help keep everything on the screen. Ultimately there has to be a hard limit and it's silly to argue over special cases that should exceed it (because that's just another thing to bikeshed over in code reviews). Black sets a hard limit and enforces it--done, no more discussion. IMHO it's a code smell to have a bunch of long lines of code that are all visually similar but vary in a tiny and easy to miss way. Here's another way to think about the code you wrote that boils it down to an even smaller and more focused intent: new = set(data.new_items) old = set(data.old_items) to_add = new - old to_remove = old - new It's not exactly the same as what you wrote but you get the idea, and it can be made simpler if you're using set types to start with. It's kind of a nudge that if your intent is to do set-like operations like difference, intersection, etc. then you might want to use the right tools for the job instead of banging out more procedural code.
- zelphirkalt 5y agoI'm not a big fan of automatic code formatters, unless they get somewhat more configurable. One simple example is line length. Usually a code formatter will break long lines, for example a function call with some arguments. But what if I have a log call there? Do I want to have that log span 3-6 rows, just because the silly formatter thought it is a long line? Well it is a long line, but I don't want to break it into multiple lines, as that would give that log call waaaay too much space. When the log call spans multiple lines, it distracts from the bits of code between log calls. Another example is, that these code formatters are often configured wrongly in people's code editors to reformat everything in the whole file. That adds lots of changes and people do not afterwards separate their commits for "only reformatting" and the actually important bits of their changes. As PEP8 already says: "A Foolish Consistency is the Hobgoblin of Little Minds". An automatic code formatter is the epitome of consistency, as it applies the rules everywhere the same way. In many places it might give some benefits, but in others it will ruin the original code formatting. I am experienced enough to format my code in a readable way and I don't need it reformatted, just because someone has to try out some tool. Especially log calls. Those are a pet peave of mine.
- heavenlyblue 5y ago> Do I want to have that log span 3-6 rows, just because the silly formatter thought it is a long line? Yes. I do not understand what’s wrong with it. Code formatting is a political stance. It’s so much easier to adopt that than have everyone have slightly different opinions on how things should be formatted.
- zelphirkalt 5y agoSo my function of 3-4 lines actual code with log lines in between (so maybe 8 lines) becomes a function of 20 lines, because of the code formatter changing those log lines and putting every argument on a new line. Now the function takes two third of my screen and I cannot scan it as quickly with my eyes any longer. I cannot simply skip log lines, but need to check for the end of the log calls instead. No thanks.
- 5y ago
- altgeek 5y ago(Note: I mostly write Java these days, so my viewpoint is colored by this.) Code is meant to be read by humans. Compilers don't have wetware eyes. Homogenizing code that was hand-formatted for the situation ignores the art and craft of writing software. I think formatters do have use as a "base" (e.g. Allman or K&R curlies?), especially for junior devs, but experienced developers that care about their software that has their name on it normally put their best foot forward. They would strive to present the most readable software they can put forth. I've been writing software since 1981 and have yet to meet a code formatter that I like. `// @formatter:off` !
- Daishiman 5y agoOne man's "readable code" is another person's trash. As the number of commiters in a codebase increases, the chances that you find at least one person's code to be an irritating annoyance increases exponentially. The only way to avoid it is to have the political power to call out the team member that's annoying. Easy enough to do if you're the lead and nobody will question your decisions. The worst and dumbest fights I've encountered is with people with 30 years of experience who have diametrically opposed opinions. I _especially_ despise having to call out very senior engineers when their own code misbehaves.
- altgeek 5y agoYes, very true. One has to prove their point of view. It's easier when the engineer in question has proven themselves in the org (I would say industry, but when you arrive at a shop, you generally need to start over.) I should have made the distinction between "senior in years" vs "senior via software admired by peers". Since code is skewed heavily to the left of "read:write", the primary issues that formatting should address are [1] muscular eye fatigue induced by "formatting" or non-formatting that leads to excessive eye saccades (i.e. eyes "jumping" from point to point, or obliquely) [2] formatting that obscures logic leading to cognitive fatigue. Another thought experiment I've used is: Imagine that you replaced [A-Za-z0-9] with squares and made it black and white. Leave the language's keywords alone. Does the shape of the code suggest the logic and flow? etc. That's more in the zone of cognitive load. That's why it's an art and craft, to me. My thinking is also colored by smaller shops, since a stint as a cog in some large orgs burned up my soul. And yes, I've been in a few dumb fights ;)
- deleted 5y ago[deleted]
- gopjop 5y agoI'd be using black, if it wasn't enforcing double quotes. That's just a bad call.
- gjenks 5y agoTry “blue” instead: https://pypi.org/project/blue/ https://pypi.org/project/blue/ It’s mostly black with some monkey patching for single quotes. (I’m on of the authors. Feedback welcome!)
- jsmeaton 5y agoI think most people felt the same way when adopting black in the early days, I know I did. But you get over it pretty quickly. Now single quotes look so wrong to me. I also always hated single quote docstrings even in single quote code bases.
- MisterBiggs 5y ago> Blackened code looks the same regardless of the project you're reading. Formatting becomes transparent after a while and you can focus on the content instead. Honestly every language needs something like this. Black is literally the first tool I install when I write Python and it's sorely missed when I move to a language without an opinionated formatter.
- efxhoy 5y agoWell done black team! For me it is a fantastic tool which saves some brain clock cycles when applied, both when reading and writing, which is valuable to me. Thank you.
- The_rationalist 5y ago
- synergy20 5y agoUsed it to reformat my python code for two years, great work!
- ggm 5y agoGreat! Black finds all my problems and manages to make my hackwork look respectable in public. I don't always like the output but I at least can understand it.
- patrick451 5y agoI honestly don't understand why devs are so hung up on formatting. I know, I know consistency. I've heard that for years. I disagree that it matters. Where I work, one codebase is formatted with black, another is not. The un-blackened codebase is rife with all sorts of style inconsistencies. This does not make it more taxing to read. The only downside is the useless PR nits from folks who randomly decide you ought to format something a bit differently. If it were up to me, I would just ban all style related comments and move on with life. But adopting Black seems politically feasible, so I advocate for that.
- mdaniel 5y ago> I honestly don't understand why devs are so hung up on formatting. Because easily 98% of the work of any developer is being a "wetware compiler" since "code is written for other people." So the faster the human can mentally run the code, the faster they can then decide what action to take next > This does not make it more taxing to read. Ah, spoken like someone who has not yet worked in a "foreign language" shop, where the developers are new to the language at hand and bring their old "best practices" to the current language
- patrick451 5y ago>Because easily 98% of the work of any developer is being a "wetware compiler" since "code is written for other people." People always say this. But they fail to provide any evidence that consistency helps, and if so if by how much. All they have is personal experience, which is all I have as well. And my personal experience says it just doesn't matter. > Ah, spoken like someone who has not yet worked in a "foreign language" shop, where the developers are new to the language at hand and bring their old "best practices" to the current language Quite the assumption. That's where many of the inconsistencies come from. And Black isn't going to help with different language idioms. That matters a lot more than whether or not you use a trailing comma for the last item of a multi-line list or not.
- BerislavLopac 5y agoI'm a huge fan of black, and have been using it in most of my projects for a long time. That being said, my biggest gripe with it is that it has at some point started reformatting docstrings [0] in addition to the code -- strictly following PEP 257 [1] -- without any way to disable that behaviour. While I understand the desire to standardise, docstrings are not executable code, and should be allowed more flexibility when it comes to formatting. [0] https://github.com/psf/black/issues/1779 https://github.com/psf/black/issues/1779 [1] https://www.python.org/dev/peps/pep-0257/ https://www.python.org/dev/peps/pep-0257/
- deleted 5y ago[deleted]
- EthOptimist 5y agoI remember seeing his presentation at the Python meetup at Yelp HQ in San Francisco a few years ago. Happy to see it come to reality
- cloverr20 5y agoHave been a long time user of yapf along with isort, yapf is way less opionated and its been good till now. https://github.com/google/yapf https://github.com/google/yapf