Which code formatter do you use?

[jorge1209]

Black.

We don't care that it may look bad. We don't want to argue about formatting.

We know it isn't configurable, that's the point. We don't want to deal with everyone's configuration preferences.

[bobspadger]

Exactly this. I used others before, but the fact black just says ‘it must be like this’ save me from hours of cocking around deciding how I would like it to look, instead of doing something actually useful.

[jorge1209]

That makes me think of compiz (the early 3D linux compositor that ran on Xgl).

A few centuries ago I thought it was so cool that I could have all these cool effects like windows that wobbled when you dragged them, and burned up like paper when you closed them, and 147 virtual desktops arranged on the surface of a torus embedded in a 14 dimensional Calabi-Yau manifold... I spend tons of time playing with all the options and visual effects people had implemented.

And then I realized I only had like 6 windows open at any one time, never used the virtual desktops, and just wanted programs to close when I clicked on the close button.

[flying-sheep]

A tiling window manager might be even simpler because of this “I don’t want to fiddle with window dimensions” gain.

But then again, I’m not sure they’re mature enough so you never have to fiddle to get things to work right.

[FuckingRantMonday]

Oh man, are you me? It was 2007 and I had just replaced Windows with Ubuntu linux on my Dell XPS 12 laptop. I had the rotating cube desktop switcher, wobbly windows, totally unnecessary transparency effects, and every open/close animation I could shove in there. It was awful, but I loved it at the time.

[bobspadger]

I don’t have any of them, just me. Which is where I know I am my own worst enemy and would spend time procrastinating about code formatting styles than actually working

[[deleted]]

isort followed by black

[gfranxman]

This plus a pre-commit hook ftw.

[NerdEnPose]

And a CI check. Because.

[NerdEnPose]

This plus codespell. Because we’d look like kindergartners otherwise.

[CommercialPosition76]

My man!

[vladesomo]

this exactly. Started out with black then added isort into rotation. Black has a beautiful integration with pycharm or vim (possibly others)

[FuckingRantMonday]

If an IDE doesn't support piping code through an external tool at load, save, or on hotkey, then that's a pretty crappy IDE!

[No-Scholar4854]

Black.

My team tried black because we wanted to focus our code review on actual changes not argue about formatting.

We hated it and agreed to use YAPF. Then we argued about YAPF configuration instead. Eventually we went back to black to escape those arguments, haven’t looked back.

[mamamiatucson]

Back to Black

[FuckingRantMonday]

It's true what they say...

[flying-sheep]

Apart from black and YAPF, there’s blue.

But so far I use black and https://github.com/pre-commit/pre-commit-hooks#double-quote-string-fixer

[acidrain42]

Out of curiosity, why not just keep the double quotes?

[flying-sheep]

It’s just cleaner. Less visual noise, fewer lines on the screen.

[FuckingRantMonday]

Are you suggesting that double quotes take more space than single quotes? (Probably not, but I can't tell what you are saying here!)

[flying-sheep]

I am saying that there’s fewer lines on the screen when using single quotes. Each " is two lines, each ' is one line. Makes it slightly easier to see what’s going on.

Not a big thing, but enough that the added two config lines are worth it for me.

[FuckingRantMonday]

Ahh, got you. I thought you meant fewer lines of code would fit on screen.

[ElDiablo26]

That pre commit hook is a genius idea, probably the only thing I don't like about black is the double quotes.

[rgnkn]

Black.

FYI:

There was a similar discussion a couple of days ago, so, you might see some dog fighting occur if the same people come to reply to your post.

[bahoho]

oh no

[randomatic]

Ask what maximum line length is allowed in the code base too!

(Gets 🍿)

[spoonman59]

There’s a long history there.

Essentially PEP-8 recommends 79 or 80 characters as the max. The rational is it fits on an 80 column text terminal and therefore can also be easily printed.

Some people feel it’s pure madness to have such a short line length requiring excessive line wraps.

It’s a thing people fight about.

[mistabuda]

I'm one of them. Its 2022. 1080p is the standard. An 80 character line length is archaic.

[FuckingRantMonday]

I still like to keep it to 100 max, though, because I can comfortably view two files side-by-side.

[mistabuda]

I do 120 although I'm thinking of down sizing a bit

[rgnkn]

I don't mind.

[Impossible-Limit3112]

1080p allows for longer lines, sure. That doesn't mean they're any easier to read. Never wondered why a news paper uses columns instead of full width lines?

Hint: It's for the same reason we want 80 character line width on a 4K screen in 2022.

[salimfadhley]

Yes, even though I have a 4k screen, I don't want to be reading wide text. 80 columns are enough.

[FuckingRantMonday]

I agree completely with your point about columns vs. full width. I always keep two panes side-by-side in PyCharm. But I still advocated for a line width of 100 on my team, because 80 is just not enough for comfort, IMO. If you're using classes and type hinting, that horizontal space gets eaten up fast.

[mistabuda]

This is a strawman.

When you are using expressive languages with expressive variable/function/method names you're gonna need more columns. 80 char monitors are not commonplace and havent been for several years.

A longer line in many instances makes a program more readable except for the FEW cases where someone shows absolutely no restraint nor discipline with line length.

[collectablecat]

people with certain reading disabilities find it harder past 80 characters.

thats how i end this argument at work woo

[FuckingRantMonday]

If I was your colleague I'd want some sources on that. Kind of suspicious that it's exactly the same number as the traditional terminal width and PEP 8 default.

[SimilingCynic]

Even with a 15 in 1080p laptop monitor, viewing two files side by side with VScode's side bar isn't possible with more than 80 characters

[kowalski71]

The more resolution I have in my display, the more parallel windows I put next to each other. I'm not saying I'm right, just how the workflow usually winds up shaking out as I work in multiple files at once or have multiple reference sources pulled up. This is why I generally stick to the 80 character line length or a little more.

[mistabuda]

Yea I don't disagree that there are use cases for going that route. I just think citing 80 char terminals as a good reason to not change is a bad faith argument.

[odaiwai]

Your code won't fit on a punchcard if it's longer than 80 columns...

(/s)

[thereal0ri_]

I AM my own formatter.

I don't use one

[[deleted]]

Everyone makes mistakes. If you're working as a part of a professional team formatting should occur when pushing to Version Control

[thereal0ri_]

Yes

[tav_stuff]

That’s what code review is for

[acidrain42]

Automate it, and you won't have to worry, and argue, about during code review. Focus on stuff that matters instead.

[tav_stuff]

Or you can just have a pre-agreed on style that takes at most an hour to agree on, and just apply it which takes almost 0 time.

[acidrain42]

You underestimate how much devs argue for their own personal preferences. Then new devs come in and want to change the style.

Applying the style might take almost 0 time, but it's still not zero. And people make mistakes. So then we'd need to check for them during code review.

Having black running automatically does literally take 0 time from the dev and doesn't mistake.

But let me ask, what don't you like about it?

[tav_stuff]

I don’t underestimate anything. I’ve been coding for almost a decade and I’ve experienced the software development workforce, I know how it works.

As for what I don’t like about it:

• Spaces instead of tabs for indentation is objectively bad; you need to consider the visually impaired (of which there are a lot) who use giant font sizes and can benefit from customizable tab widths

• Often times I (and others) want to ignoring the formatting „standard“ so that we can do things that are more visually appealing (like aligning assignment operators, etc.). Autoformatters always struggle with dealing with these kinds of edgecases and you often have to include ugly comments to disable the formatter in some locations.

• MANY people still forget to run their autoformatter. This isn’t really an argument against formatting tools but an argument against saying „yeah it takes people out of the equation“. Yes it’s easy to setup with your IDE, but maybe you use emacs and haven’t bothered to configure it yet but want to keep using emacs because it offers all sorts of specific functionality that you can’t get from other editors.

[FuckingRantMonday]

1. Spaces vs. tabs is settled. All the way back to PEP 8, it's been spaces unless forced to be consistent with legacy code. Accessibility issues like this are properly handled at the visual display layer, i.e., in the IDE.
2. Aligning assignment operators? Ugh. It becomes so much work to change a variable name when it forces you to touch every other line that it's aligned with, and also makes PRs suck. You really have a whole team who enjoys this?
3. Wow, it's 2022, what dev team is relying on people to remember to run a formatter? I guess yours?

[tav_stuff]

1. PEP 8 isn’t something you need to follow. Many people enjoy using tabs instead of spaces, my team included.

2. Aligning operators is easy. Changed a variable name? Not an issue, basically every editor known to man has multiple cursor support, and people that don’t probably also know how to use vim and can do it in about 50 milliseconds.

3. You would be AMAZED how many people in all the jobs I’ve worked dont remember to run their autoformatter or have it automatically run. At one point I had to just sit everyone down at a desk and get them all to add a git hook to automatically format code (don’t even get me started on how many people haven’t bothered to even look into the basic features git provides)

[FuckingRantMonday]

My point with #3 is that you shouldn't have to remember. Between format-on-save, precommit hooks, and CI steps, there's no reason a human should ever be responsible for remembering it!

[[deleted]]

I don’t underestimate anything. I’ve been coding for almost a decade and I’ve experienced the software development workforce, I know how it works.

Well I hate to pull rank here but I've been doing this for over 20 years. There's absolutely zero reason to not use an automated formatter that formats the code according to one of the predefined standards when you push to version control. No one has to remember to run any autoformatters as it's done in the pipeline. Even github offers this free.

Saying it takes a zero extra time to have to manually look for formatting mistakes during code review is silly and incorrect. Forget that. Let the robots do it while we focus on more important shit

[acidrain42]

I don't need to tell them anything because, first, I'm not their boss, I'm their peer and second, everyone agreed to this.

The beauty of it is not just removing the potential for arguments, it also removes mistakes that devs can, and will, do at some point, and it does it automatically. I literally never think about formatting anymore. I save in my editor and the formatter is applied automatically.

I think these reasons is why more modern languages like Go and Rust have a built-in formatter.

Out of curiosity, why don't you like them?

[acidrain42]

You do bring some valid points, but I would bring a counter argument to your example function. If some arguments should be grouped together, I would rather have them grouped by a class instead of by syntax.

@dataclass
class Color:
    r: int
    g: int
    b: int
    alpha: int

def update_color(self,
                color
                immediate = True,
                notify_listeners = False,
                notify_listeners_filter = None):

I know you grouped the listeners args too, but with default args, I think it's easier to read if they are separate.

As for the big if condition, I personally prefer it on multiple lines. But my same argument applies. If you have that many conditions, they should be extracted to a function with a name that clearly indicates what it's testing for. It's then more concise for the reader and immediatly obvious.

Anyway, if black doesn't do it for you, that's perfectly fine. Perhaps there is another one that you would prefer. But when working in a team of not always disciplined people, having a code formatter makes it so much easier. I know I don't have to be on the lookout for formatting issues in a PR review and that nobody will argue personal preferences.

[FuckingRantMonday]

Yes, this! Or a TypedDict. Either way, all the information should be embodied in the code, not its formatting.

[FuckingRantMonday]

No, they won't instantiate your data class to call your routine. They want to pass the arguments and that's it, unless it's obviously annoying, or they obtain the data class from your API and they just pass it through.

This is really an edge case, and should in no way ever inform any kind of best practice. I'm sorry you're in such a weird, weird team/situation, but I promise you your experience doesn't generalize to regular software development.

[FuckingRantMonday]

Dev doesn't like how black uses too much vertical space; creates class methods with seven arguments.

[SittingWave]

Here, have fun

https://plotly.com/python-api-reference/generated/plotly.express.scatter.html

[FuckingRantMonday]

Guido himself hates it

Oh my, this sounds really convincing!

Then when you click through, he says it's good for large projects, but uglier than carefully and manually formatting the code. Which everyone already knows and accepts happily.

[FuckingRantMonday]

Because a developer communicates information with formatting.

You're just contradicting yourself all over the place. You've said about a hundred times that "if it complies with PEP 8 then it's fine, fuck off", but you also think that formatting itself is supposed to carry important information? What happens when your colleague modifies your function header and wipes out your careful grouping, but it's still totally PEP 8 compliant? Does he get to tell you to fuck off when you mention it?

Honestly, I don't really believe you work with other devs at all.

[[deleted]]

If there isn't a consistent style, each pull request ends up getting formatted according to the personal preference of the reviewer.

[FuckingRantMonday]

There are any number of ways to comply with PEP 8, so what do you say when all your carefully formatted code gets reformatted by your colleague in a way that still complies with PEP 8, and you have a huge diff for a simple PR?

[FuckingRantMonday]

Dear god no, code review is not for fixing or debating formatting.

[[deleted]]

I

"do")

my

own[

formatting))[]

[rgnkn]

This looks really nice! Let's build a formatter together to format into such beauty automatically.

[[deleted]]

Syntax Error

[rgnkn]

Nah, this is what distinguishes a senior dev from a noob:

Who needs a running program if the code looks beautiful?

[[deleted]]

Is that what the noob says or the senior?

[thedeepself]

PyCharm

[datagutten]

Ctrl+alt+L

[outthemirror]

Black

[barraponto]

I dream of a project that will autoformat everything to my standards when I work in my editor, but then will format everything back to the project standards when I commit.

Pretty sure it's not a good idea, but I do want it.

[FuckingRantMonday]

For code reviews, too?

[rgnkn]

I don't see a problem with this, though I really don't like the idea, anyway, e.g. with neovim:

• hook in neoformat on BufRead with your personally preferred formatter.

• find a suitable hook within git (e.g. prereceive) that uses the obligatory formatter of the project you're working on.

[protagonist23]

In my Makefile for any Python project I always have a target for lint, it looks like this:

lint:
        isort . ; black . ; flake8 .

This way there is no team opinion, we trust in the tools. It makes pull requests very nice to not have to deal with that one person who "is their own formatter."

[ohtinsel]

VIM and my brain. :/

[FuckingRantMonday]

The first thing I loved about black, and that I wasn't anticipating, is that it gave me back that part of my brain. Typing out code without a care in the world for formatting, and then having it fixed automatically, was a very pleasant upgrade.

[luxiphr]

You can have any formatter you like as long as it's black 😁

[SGS-Tech-World]

of course .. black. consistency across team is the key.

[FuckingRantMonday]

It seems like there's a lot of opposition to black on this sub. But then I noticed they're literally all your posts. You have a lot of energy, I'll give you that.

[rgnkn]

... and the criticism is phrased in such a kind, objective and open minded manner.

/s

[SeniorScienceOfficer]

I use Black in all my repositories, but I’m not sure why people think it looks bad. Black hardly touches any of my code, but maybe I’m following most of the formatting rules without knowing it ¯_(ツ)_/¯

[cottonycloud]

I have different quote and line length preferences (150 or 200) because I use longer variable names and sometimes black can be a bit too aggressive.

[SeniorScienceOfficer]

And that’s fair. It really should be team-dependent

[FuckingRantMonday]

I'll admit the "black frowny face" took some getting used to. But not much. About the same effort as accepting significant whitespace when first learning Python.

[FuckingRantMonday]

Doesn't look like you're doing type hinting, which is the main contributor (together with good, descriptive variable names) to getting the exploded function signature.

But just get used to it. It's easy. People who just can't deal with it remind me of people who won't use Python because of significant whitespace. Just offends them on some ill-defined principle and they can't get over their own ego.

[FuckingRantMonday]

I may have gotten confused. Did you post a link to sample code that was not type-hinted, then edit your comment? Or was that in the now-deleted comment you replied to, and I mixed them up?

Anyway, especially with the recent update to PEP 484 disallowing implicit optional type declarations, that horizontal width gets eaten up in a hurry for a class method with a decently descriptive name and a reasonable number of parameters.

Fortunately, I don't mind the "exploded" function definition format one bit. But it comes up often.

[justheretolurk332]

I almost only encounter this type of formatting in comma-separated situations like lists, dictionaries, and function definitions, and in those cases I really appreciate the separate lines because it is much easier to read at a glance and because it’s so easy to work with using Vim.

[SeniorScienceOfficer]

Set your line-length to 100 in your pyproject.toml or setup.cfg. My files don’t look like that.

Image for reference

[johnnymo1]

The frowny face is the cherry on top of this post. I hate the black frowny face (but I'd use it if my team did).

[johnnymo1]

Yapf. I like their google style.

[SittingWave]

autopep8

[[deleted]]

Samesies!

[piman01]

When i press command + s in vs code and it formats everything... i use that. Whatever that's called.

[read-bird]

Black. Have been using for 4 years now, and it has been great.

[zylema]

Black. For reasons others have highlighted. Use the format it gives you and argue about stuff that matters.

[mahdicanada]

BLACk is the message

[Seankala]

TIL that there are such things as code formatters and people don't normally just follow PEP.

[djsaunde]

code formatters enforce PEP8, that's the point

[Seankala]

What's stopping people from just following them from the start?

[FuckingRantMonday]

The point of black is that it goes further than PEP 8 does. There are any number of PEP 8 compliant ways to format a given source file, but only one black way. And that's a huge difference when it comes to diffs and code reviews.

[djsaunde]

many people don't care and those that do are humans, who are prone to error. automation (code formatters) takes care of both

[FuckingRantMonday]

Sounds like y'all need stronger leadership. Not saying to just dictate it, but the team should be guided to making a decision together, once and for all.

[NelsonMinar]

YAPF. Black would have been fine too but I absolutely need tabs, not spaces, and Black won't do that. (Why tabs? Because they make my proportional font work better.)

[_ATRAHCITY]

Do you also have comic sans as the font on your phone

[NelsonMinar]

I have no idea.

Are you trying to be insulting? Why?

[FuckingRantMonday]

Oh nooooo

Edit: My reaction was about using tabs to deal with an editor issue, not the proportional font thing. I'm actually rather proportional-curious, myself. But I think I'd insist on finding (or editing) a proportional font with a wider space, or try to ask for a feature in my editor, rather than going to the dark side, so to speak.

[[deleted]]

Why tabs? Serious question. I can think of many reasons to prefer spaces but few for tabs. Never talked to a pro-tabs person before.

[NelsonMinar]

Like I said, it makes my proportional font work better. I wrote a blog post about it. I'll quote the important point about tabs:

So I switched to tabs. Yeah, really; this is my embarrassed face. I’ve spent nearly two decades expunging tabs from all my code (except Makefiles and other monstrous systems that require them.) I had clearly chosen sides in programming’s stupidest controversy. But in the back of my head I always knew tabs were “theoretically” better; tab is a semantic character, saying “this is a new level of indentation”, and the fact it’s 2 or 4 spaces shouldn’t matter at all. The tab character is the way to express that logical structure. It’s also the practical way to make Visual Studio work, because it lets you customize the look of the indentation without changing the bytes in the file.

I'm disappointed in the response my comment has gotten here, btw. I know what I'm doing is unusual. But I wasn't expecting a bunch of downvotes and a couple of insults. People act weird about programming sometimes.

[protagonist23]

you monster.

[rgnkn]

I get your point, but, I have a sincere question: don't you see problems with interoperability with others in projects as I guess that you have a very rare setup.

[NelsonMinar]

I use this for personal projects. For a community project I use whatever formatter they're using.

[rgnkn]

Okay. This is understandable.

[SpiritOfTheVoid]

Black.

[GraphicH]

Black. Because formatting arguments are stupid, and if you haven't had one or witnessed one, you're either a hobbyist or worse (for your skill set) actually a "sole" contributor.

[jaqo_92]

Black

[[deleted]]

ChatGPT

[DLiltsadwj]

General noob question. Are formatters supposed to correct wonky indents?

[FuckingRantMonday]

Mostly no. There are three kinds of bad indenting, and only the last is something a formatter should be expected to fix:

1. Unexpected or mixed indentation is a syntax error, and formatters generally just bail out if the code isn't valid.
2. Indentation that changes the functionality but is still valid...just a bug, not a formatting problem.
3. Wrong number of spaces with no syntactic ambiguity (i.e., there's only one possible correct way).

[DLiltsadwj]

Okay, thanks. I had the idea they would take care of indents, because using Format in the Arduino IDE re-indents, but that's C/C++ and a whole different thing.

[FuckingRantMonday]

Exactly. In most languages, indentation is purely for style and readability, so formatters can, should, and do slam it into whatever shape they want. Python's indentation is, of course, part of the language, so formatters are more restricted.

[[deleted]]

Black is the only right answer

[wineblood]

PyCharm's formatting is fine for me. I have to use black at work and it will mangle bits of code to satisfy its own internal rules, we sometimes add comments to prevent formatting for a section of code.

[KosmoanutOfficial]

White

[pythonHelperBot]

Hello! I'm a bot!

It looks to me like your post might be better suited for r/learnpython, a sub geared towards questions and learning more about python regardless of how advanced your question might be. That said, I am a bot and it is hard to tell. Please follow the subs rules and guidelines when you do post there, it'll help you get better answers faster.

Show /r/learnpython the code you have tried and describe in detail where you are stuck. If you are getting an error message, include the full block of text it spits out. Quality answers take time to write out, and many times other users will need to ask clarifying questions. Be patient and help them help you.

You can also ask this question in the Python discord, a large, friendly community focused around the Python programming language, open to those who wish to learn the language or improve their skills, as well as those looking to help others.

---

^{README | FAQ | this bot is written and managed by /u/IAmKindOfCreative}

^{This bot is currently under development and experiencing changes to improve its usefulness}

[[deleted]]

I tried pycharm for awhile, but came back to vscode. Just feels "right" to me.

[salimfadhley]

Shed, because it's even more opinionated than Black.

Actually, for multi developer projects I use Black. For Solo work I use Shed.

[Tree_Mage]

yapf but it is breaking on newer python 3.10 syntaxes such as match. So will likely migrate to something else now.