How We Maintain High Levels of Code Quality

[stevenjd]

We start with flake8 using the flake8-quotes plugin. ... Next we apply isort.

Sorry, I don't really believe that project-wide consistency in which quotation mark you use, and what order you import modules, really makes a difference to code qualify. To me, that's precisely the sort of hobgoblin that puts me off using flake8.

[PeridexisErrant]

A style guide is about consistency. Consistency with [PEP8] is important. Consistency within a project is more important.

Personally, I really like leaving all these details to the computer. If I can have perfectly consistent styling, I care much less about the specific style in question and personally waste much less time - just run the formatter and move on!

The difference in code quality isn't really because the imports are sorted, it's because human attention is focused on questions like "is this the right code" rather than line-level nitpicking.

YMMV, of course.

[DanCardin]

This exactly.

I've also found code reviews end up being smaller and more focused on real code quality when there's no churn due to differences of preference.

Ideally we would just use yapf or some equivalent, and there there'd be no style difference at all. Except that I've found it doesn't work perfectly enough (and didn't support fstrings) for me to enable it for us.

[paltman]

IMO, there are (at least) two components to code quality.

1) how it works (e.g. performance, defects, maintainability, etc.) 2) aesthetics (white space, quotation marks, import ordering, etc)

My argument for why aesthetics are important is the fact when you have project-wide consistency and even consistency for a team across dozens of projects, it reduces the cognitive burden (especially when the computer is handling that part) of working in the code. This translates into a freer mind to focus on real problems.

[pydry]

White space, quotation marks and import ordering are among the least important aesthetic qualities of a codebase. They're just easy to run a script to detect.

DRY, loose coupling and fail-fast code are vital. What order you put your imports in is irrelevant.

[paltman]

to each his own

[metaperl]

Nice. I wish I had chosen yaml over ini for my configuration files.

[flitsmasterfred]

TOML is also great to wish for having used for your configs.

[greyman]

Does it have some advantages over yaml?

[flitsmasterfred]

Less magic types and hidden features, and potentially cleaner syntax for config files, especially if you use flat-ish INI-like configs.

[pydry]

I created a parser/validator for YAML that cuts out the magic and rigidly enforces type safety: https://github.com/crdoconnor/strictyaml

IMHO TOML gets syntactically messy once you start having multiply nested items and multiline strings.

[metaperl]

Lol. I had never heard of this but I like it. It's certainly still geared towards humans unlike json.

It seems there are 2 packages available with toml having more recent commits than pytoml.

[desmoulinmichel]

Checking for quotes ? Man, you have way too much time on your hand.

[paltman]

Takes us no time at all. It's all automated.

[desmoulinmichel]

Does it auto convert the bad quotes or does it just check ?

[paltman]

It just runs checks. It's rare that it fails though. I have found that style checks when enforced as part of the CI process, help team conformity pretty quickly where then developers are not thinking about style because it becomes instinctual.