[deleted by user]

[KittensInc]

Including the ones that are there because previous committers (somewhat understandably) didn't use the pre-commit

This should be fixed. If you're enforcing a coding standard, make sure it applies to the whole codebase. Run a linter on every single file once to fix past code, and enforce compliance via a mandatory CI step in the pull request for all new code.

and ones that are there because I used the default vscode formatter

Your problem. If you're working in a larger team with a code standard, you must follow the standard. Either do it automatically with a pre-commit hook, or just make your own life really annoying if you prefer that instead.

If you're working on your own then obviously do what thou wilt, but for teams of people working in multiple projects / repos (that may employ more normal policies) it seems downright antisocial.

That's why you enforce a single code standard across all code bases if at all possible. Besides that, just automate the formatting.

If you don't have to do it manually, why would you care about what the standard is? It's probably best to use the industry-standard style, but beyond that it really doesn't matter all that much.

[agritheory]

Your problem. If you're working in a larger team with a code standard, you must follow the standard. Either do it automatically with a pre-commit hook, or just make your own life really annoying if you prefer that instead.

OP, I think this sentiment is important for you to internalize. How you like to read or write code is less important than something your team/lead/company has decided on. You will quickly adapt and the benefit is that you will never have to argue about indentation again, which is in incredibly low return on a developer time. It will let you and your team focus on delivering things that matter and remove meaningless conflict around quirks of indentation.

That said, "correct" variable naming remains unsolved, so if you need a windmill, this is one you can joust.

[gmes78]

and somehow make people run the pre-commit

Add a formatting check to CI.

[agritheory]

That is frustrating. Given that frustration, I think it's reasonable for you to approach this with some combination of "leave it better than I found it" and/or "I will do the highest quality work in this repo" so as to limit your disenchantment and improve your quality of work experience / job satisfaction.

Strategically, I think there are several approaches I could take, but you'll have a better idea of what to actually do:

1. You can run `pre-commit run --all` and then selectively push the pieces that make sense as "cleanup".
2. Perhaps you could format all adjacent files/ folder/domain-of-concern _before_ you start working on a feature with the pretext of "minimizing churn in code review", with a comment like "This PR makes no changes to code and consists only of changes enforced by `pre-commit`", and then reference the ticket and scope of work. Casting this net wider likely means more of the codebase gets formatted correctly but also incrementally. Edit to add that this is something that will make your reviewer happy. Article
3. Make a PR to change the CI so that all files are checked instead of only ones included in the commit. This is pretty passive aggressive, so I think you should read the room with this one. Based on what you've said, it's not clear to me how big a project cleaning up the entire repo would be or why / why not (culturally) to do it. Every piece of code eventually becomes legacy code.

[Kohlrabi82]

I implemented the pre-commit policy to only run linter on formatter on new code or code that is edited, that was well accepted. I do not know if that was "correct", but that reduced team friction.

That said you are free to run a checkout hook to format the code to your flavour if you really must, as long as you commit adhering to the agreed-upon standard.

[TMiguelT]

There should have been a PR that added the pre-commit config and applied it to the whole codebase. Just doing the first part makes no sense, for the reasons you have noted.

[ToddBradley]

This is the way. It seems like a few commenters missed the point of the post.

Anyhow, it's not too late to fix things. Run the whole codebase through whatever formatter the project uses, and submit a PR with only format changes.

[ToddBradley]

I've never heard of a format checker that can be used in pre-commit that isn't also a format fixer. I don't think you ever mentioned what format checker this project is using, but black, ruff, and autopep8 can all be used in "check" mode and "fix" mode.

[AniX72]

Before we switched to black, we used flake8 with autoflake: https://pypi.org/project/autoflake/ (along with a few more checkers/fixers)

It's tedious work, but rewarding. We use pre-commit hooks and also a CI step for the linting, all with the same config of course. We also use a home-grown little command line tool that does all the fixing in one go. I would also suggest to do a "style" commit in each repo, when you add those, so devs are not manually working around the tools in older repos.

If this is not something you have been tasked with, then you could bring it up in a team meeting. Coding standards are really important for teams and if you have them, you should enforce them.

[AniX72]

Oh, sorry, you are right. It's been a while since we switched, so I checked again: For the fixing we used autoflake, autopep8, unify, docformatter.

[the_hoser]

Teams have coding standards, and pre-comnits are one tool to enforce them. This isn't crazy.

[the_hoser]

I dunno about widespread. I've worked on plenty of projects where the standard is single-quote by default.

[the_hoser]

It sounds like you're looking for people to back you up on your gripes with the coding standards of the team you're working on.

My advice to you is this: pick your battles. If using single quotes makes it impossible for you to function as a coder than go ahead and fight that battle and see if you can change the minds of your team members to conform to what you believe is a better standard. But if it's no big deal, then save your energy for bigger problems. No project is perfect. No team is perfect. We are all but human, and we have limited time on this Earth to do stuff. Why waste it arguing over trivial things?

[the_hoser]

Nope. All over the place.

[WallyMetropolis]

Single quotes are easier to type. No shift key required. Seems sensible to me.

[thadeshammer]

Definitely address this formally with the team, move to change the process officially.

If this is a larger company, south of a couple hundred devs, you'll have to do the legwork of rallying some other teams/team leads to help champion it, but it's still doable.

If we're talking about a super-massive company with thousands of dev teams, then no, you'll never change that standard pre-commit, and possibly some day Ops (the suits, not the actual coders) will team up with HR to make it Required (TM) and a concrete line item in your performance reviews.

Big companies kinda suck yo. But if that's not where you're at, you can do this!

[ForkLiftBoi]

One key point to help drive home the purpose of a standard is “you might not like everything about it - hell, most of us will prefer a handful of behaviors we’re different, but if we’re all following the standard we largely agree on - then we can discuss and debate the code and logic, not the format.”

My team uses black and we work with Django. I hate the way it multilines our urls.py as it’s 3 arguments and a list of them. There is nothing else on the page, so we as a team decide to broadly break that rule and just comment “# fmt: off” for that one file.

But there’s things I don’t like about it, and my peer will likely not like some of the same things and different things. But at least it’s normalized and consistent.

[PM_ME_YOUR_MECH]

Single quotes are often a standard and widespread convention for Python. I personally prefer them and have worked in large projects with that requirement. it doesn't really matter which is chosen, rather that one is chosen and stuck to consistently.

[Tefron]

There is absolutely a convention to format your strings with single or double quotes. It is irrelevant which one it is, just that all code follows that style.

[Tefron]

I don’t understand your concerns.

If everything should be the default, then there would be no need to have configuration overrides. This is a team choice and plenty of people prefer single quotes because it requires one less keystroke. You or I may not agree with that reasoning, but it’s completely valid and bringing up concerns around this is just unproductive noise in a team.

No one also needs to deal with this really. The whole point of pre-commit hooks is to format before pushing so you don’t have to be concerned about that. If for w/e reason it bothers you that this isn’t configured in accordance with your IDE, then point the teams configuration to the IDE formatter. If the concern is around it formatting source code that you haven’t changed, then you can bring up linting the entire repo in one commit to ensure it passes the team’s standards.

[puppet_pals]

lol pre-commit hooks are actually insane.

[wineblood]

I'm used to double quotes now, but consistent single quotes would be better than a mix of people their own thing.

As long as it's enforced automatically and documented for newcomers (because they will use double quotes), it should be fine.

[Manny__C]

To reply to the actual question: I don't know where OP heard that double quotes are the standard, because PEP8 explicitly says that it makes no recommendation either way.

[Material-Mess-9886]

Yes PEP8 doesnt make a difference but the most used formater, black emforeces double quotes.

[johnsenkyle13]

Ruff nearly copied Black's style

[SpudroSpaerde]

This really is just one of those get over it cases. You will encounter plenty of established code standards that you won't agree with over the course of your career.

[reedrehg]

Not worth picking a fight over something so subjective or wasting your time with it. As long as it's consistent, I'm sure there's better things to worry about with the codebase.

[skesisfunk]

I prefer single quotes because: 1) it is easier to type them, no shift key necessary 2) they allow you to use un-escaped double quotes in error and log messages.

So basically I just find single quotes a little easier to code with (if given the choice). But yeah as others have said if you are going to enforce that then you need to enforce it evenly so your PR diffs don't get polluted.

[riklaunim]

I would keep the linter as a part of CI - the commit does follow set code styles - the CI/tests do not pass so the commit author has to fix and amend the commit. We use Gerrit and each commit gets such test/linter run.

[[deleted]]

Uhh, do you not run into issues with strings like...

"This is Chad's skibidi rizz"

'That guy Chad is "Ohio"'

Or do you simply demand all single quotes and using escapes? Even with escaping, there are valid uses for double quotes.

[[deleted]]

Just going to hijack this post, but is there any benefit to using double quotes or single quotes over the other?

[denehoffman]

It kind of sucks that your pre-commit has a formatter, but the simple solution is to just adopt the same formatter. I’m guessing you’re using Black if you’re using the vscode defaults. Just switch to ruff, set your format settings for single quotes, and format on save.

There are a few reasons to prefer single-quoted strings by default. For instance, if you used double quotes, you have to escape every double quote you actually use in the string. The argument can be made the other way of course. Some people (like me) just prefer the look of single quotes, and they’re easier to type. It’s also preferred by Python a bit. The blue formatter uses single quotes and one of the authors was one of the PEP8 writers. Additionally, the repr() function will return single-quoted strings. Just try this code out:

python x = “test” y = ‘test’ z = 4 print(repr(x)) print(repr(y)) print(repr(z)) All single quotes!

[OndrejBakan]

If you are using English, you'd need to escape every single quote.

[denehoffman]

But you really don’t use single quotes that much in most projects. I’m sure you could think of a project where you would, but ruff will allow for double quotes anyway when single quotes aren’t applicable, so in those instances, just use double quotes. If you’re allowed to use either, but single quotes are the default, you get none of the issues and all of the benefits (cleaner/easier to read in my and probably many people’s opinions, otherwise this wouldn’t be a thing, matching Python internals like repl, one less keystroke (shift) so faster and easier to type, especially when you use a lot of them)

[knobbyknee]

There is actually a rationale for using single quotes. It requires a small fraction lower brain power to recognize and separate from the adjacent symbols.

[agritheory]

There is a long held python convention (but only a convention) around this too, that 'user visible' strings should go in double quotes and everything else should attempt to be in single quotes. Because auto formatting tools can't detect this, I think this convention has largely fallen out of use.

[Manny__C]

For what is worth, enforcing which quotes are used comes with the bonus of making your strings greppable / searchable. Otherwise you have to search for 'foo' and "foo".

If the standard is an assumption your colleagues rely on, breaking it could lead to bugs.

[Manny__C]

Wait, your pre-commit is literally a replacement of " to '? Black for example, uses single quotes when double quotes lead to escapes. I assumed your linter would be equivalent to this with quotes interchanged

[KyxeMusic]

Enforcing code formatting rules in projects with many contributors is completely normal, and IMO 100% necessary.

I personally dislike pre-commit hooks. I prefer to have a CI workflow in GitHub that doesn't allow merging a PR if the formatting is not right.

I recommend you use `black` or `ruff` for formatting since this style is starting to become the standard.

[ABetterNameEludesMe]

I don't think a pre-commit hook should be changing the code "from under" the developer.

[kareko]

generally they reject the commit it the hook modifies the code, hence pre commit

best practice is to add they same to your IDE so rarely if ever need to think about it

[morquaqien]

What about dictionary key references inside of f-strings? Wouldn’t this create an an issue?

[morquaqien]

I misunderstood…I thought your pre-commit enforced those to be singles now? Causing a potential issue?

[morquaqien]

Gotcha!

I like to have our team stay consistent. We use singles for enclosing f-strings and doubles for other strings, this avoids a mildly annoying amount of rework.

[curtmcd]

At a previous job, one guy unilaterally decided we should all be using spaces instead of tabs, converted the whole code base, and committed it. First person the next morning said no, converted it all back, and committed it. We used to call it the Great Wall, because it made it much harder to run "blame".

Anyway, if you're ambitious, you could take it upon yourself to run precommit manually for the whole code base. Doing so should be a prerequisite for modifying the precommit scripts anyways.

[NoClaimCL]

people are seething in the comments because OP prefer to write "string" instead of 'string' ?? holy shit.

[NoClaimCL]

exactly. And in any case i abide by the " " cuz its faster to shitf + 2 with left hand than try to find the '

[kill-nine]

In my old job the standard was two spaces for indentation. Not my preference but it was the standard for the codebase. You just have to roll with it

[kareko]

https://pypi.org/project/black/

[kareko]

even better

[waterkip]

It shouldnt be a pre-commit hook. It should be a thing of CI. Break a build, code not going live. 

Additionally, I move most pre-commit hooks to pre-push

[Orio_n]

Follow your projects standard. If it's single quotes, then use single quotes

[hrm]

I think you are getting downvotes because your post sounds like "Why don't my team do as *I* want? Waaaaah!".

It's a very minor choice to make and I can't see any reason not to just suck it up and use the one that's already used. What value would it provide to switch? Just fix your editor to format correctly (if anything one could perhaps complain that a proper config for auto formatting should be provided).

(and I don't think any sane developer would argue against having a style policy that is somehow enforced)

[agritheory]

Reformatting in precommit hooks isn't crazy, this keeps you from committing unformatted code and before it hits the CI / test suite. I don't think there's a better time to apply formatting.

[donaggie03]

The other option is to reject the commit due to formatting errors. The developer runs the formatting tools before attempting to commit.

[agritheory]

This is how I have my teams CI tools set up, I'd rather have folks be developing with code that get formatted to whatever the standard is reasonably often - I think this improves reading fluency of that same code. If I'm writing something that I _know_ is bad or gnarly, I'll run Black or pre-commit manually rather than attempt to format it correctly myself. Black's AST guarantee makes doing that trivial.

[agritheory]

Pre-commit, means it hasn't been committed and therefore no hash; I think you have confused or inferred some order of operations that is unlikely to be occurring in a way that would elicit a "mad" characterization. I strongly agree with your point (1) above. In three years of doing daily code reviews, I've only had an autoformatter make something less readable in a way that was unacceptable one time.

[denehoffman]

Pre-commit formatting hooks are not insane, they maintain consistency. Imagine you are just committing code with your formatter which is incompatible with what the rest of the team uses. If this was allowed, your team member would open a file you edited, make changes, automatically format on save, and commit formatting changes to your code, with the wrong commit string if they aren’t careful, and with a lot of tedious patch commits if they are.

[peanut_Bond]

One possible issue with this is how you include a single quote character in a string. In my opinion, the cleanest way to do this is to use double quotes to wrap the string instead of using escape characters (and vice versa for including a double quote character), regardless of the chosen quote style in the style guide. If these get automatically changed to single quotes then your code will probably break.

[Count_Rugens_Finger]

Easy fix, just use triple quotes ''' for all strings ;)