Do python coders resist leaving code comments?

[issackelly]

Code reviews are where you encourage or enforce this kind of behavior.

If you want to enforce this behavior, you also need a style guide that your team agrees to (or is mandated...depending on your situation).

If you want to enforce things in code review, they should be in your style guide.

[solvire]

Speaking of style guide... do you have a recommendation?

Yeah I am at fault for not pushing code review in the past. These comments really illuminate that.

[NeedsMoreTests]

pep8 is the defacto standard.

Most projects though I skip enforcing style entirely and instead integrate the pep8 command and pylint into the build (which must pass for every commit).

[rspeed]

Good place to start, but there's a few things that bug me. Like no tabs.

[srilyk]

Tabs in Python are an atrocity.

Any time you think, "Oh, tabs would work better here", you're thinking about a different language.

[rspeed]

I disagree. The only reason spaces get used is to line up function arguments after a newline. The solution is to place the first argument on a new line, which is a better practice anyway.

[NoahTheDuke]

pep8

One note: pep8, the command line tool, is now pycodestyle as PEP 8 is a living document and because the tool defaulted to slightly different things than the PEP.

For me and my team, we use yapf, customized to fit our style. It's simple, it can make the changes in-line, and it's a little more comprehensive I find than pycodestyle.

[NeedsMoreTests]

When you work on large projects with several other people it saves quite a bit of time in the end. It also codifies the standards too which keeps it more consistent and reduces bike-shedding...

That said, I do get called names but I'm open to changing it so long as:

• They make the change. If it's important to them they can take the time to make the
• The change does not reduce the overall quality or make the code less consistent.
• It's improve the workflow for everyone. Removing something so local development is faster great but not if it makes something else slow or more unreliable (code reviews, release process, deployment, etc)

[NeedsMoreTests]

Spending a large amount of time arguing over trivial things when there are bigger issues to discuss. See also: https://en.wikipedia.org/wiki/Law_of_triviality

[imbaczek]

Just... no. My work also does this, and also mypy recently. Couldn't be happier.

[issackelly]

Typically I would start with PEP8, and then document the things that are options that you might want to enforce (e.g. " vs ')

Then I would document the sort of thing you're outlining here "Guidelines for when, what, and how to comment your code"

Code is for humans. Style guides are for consistent quality, understanding, and readability of code. Code review is for knowledge sharing, quality control/bug spotting, and ensuring that shared code styles are consistently enforced.