Styling rules that I do not feel comfortable with

Python Help
1

Hi,

I just installed a linting and formatting plugin and I see my code all filled with yellow lines and warnings. One of them is about the way I align things, I did some research and I see:

image
image787Ă—244 4.54 KB

from here. I understand that the correct form makes it easier to add more variables. If one adds an extra long variable the alignment of the other variables would change. However I do believe that the wrong version is far more readable. That in my code manifests in places like:

image
image851Ă—183 39.9 KB

There are many other small things that I seem to be doing differently from what is in PEP8, but I want to keep this brief. My point is, I feel like following PEP8 and applying all these fixes is going to take me from code that I can read and work with to something worse.

Cheers.

1 Like
2

That’s fine. PEP 8 is a set of guidelines. You don’t have to follow them. And if your plugin is applying rules you don’t want to follow, you just need to change the configuration of the plugin to match your preferences.

I’m moving this to the “Python Help” category, as it’s not a proposal for a change to Python, but a request for assistance in using Python.

6 Likes
3

As @acampove points out, some stylistic choices are not so much wrong as not the one chosen by someone else.

Ideally, a tool like the one being used would allow a user to customize a profile of some kind that spells out which choice they are making about something that is optional.

But if there was a way to record your choice, some other program you use probably would not know or care. And, if you chose your style from among others, should it be an error when you don’t selectively indent?

Consider another style I can invent which is deliberately ragged so when I am reading or perhaps counting, it helps me see the lines as different:

alpha =   1
beta   =     2
gamma =   3
delta =      4
epsilon = 5

My display as I type is glitchy so you may not see what I intend. Imagine, if needed, that I have my results in two columns, alternating.

This could be meaningful for me or someone reading the code, but as noted, editing can cause problems with having to redo everything.

And, this reminds me a bit of other possible standards. As an example, in situations where you have comma-separated values, what happens at the end? Some environments I have used allow a dangling comma and simply ignore the fact that nothing follows. This allows the lines to be moved around or new ones added in middle or the last one deleted, without causing syntax errors. But, clearly, if a language sees the empty slot differently, this kind of setup is wrong and can cause errors. As one example, in a CSV file, a trailing comma might mean there is another column and it seems to be empty.

If there has to be a single standard, then one has to be chosen. If several are possible, then either allow the user to select which is their preference or provide a way to suppress that error.

And, of course, the programmer can show some flexibility in the face of inflexibility and mainly go along even when they don’t like it.

I do note an annoyance in Python in this case.

Many other languages ignore whitespace before a variable is declared but Python uses indentation for grouping much of the time. So in other languages, you can right justify the variable name rather than just lining up the results. The following would be bad python:

# Bad python indentation
  alpha = 1
   beta = 2
  gamma = 3
  delta = 4
epsilon = 5

This might have given you a similar functionality as the LHS might line up in a constant width font but generality could really cause errors when run say indented in an if block.

1 Like
4

One the the goals of PEP8 is to make the code we write more consistent. It’s a generic, Python style guide. But it’s just that, a guide. You should be able to configure whichever linter(s) you use to use the style the way you want it to be - or to ignore the ones that are not options in that linter.

While this is all fine for individual projects that you are the only person maintaining, larger projects (whether open source or something for a company) should adhere to a set style convention that is reasonably close to PEP8. The reason for this is lowering barriers for onboarding new people. One of the things that many groups (be they teams in a company or open source maintainers) require is the use of a formatter such as black or ruff before merge in order to uniformly enforce style standards (and limit the arguments that can arise from them.)

If what you’re working on is for you alone, use whatever style you feel comfortable with. If you’re working as part of a group, set the standards as a group and use a tool to enforce them. PEP8 just happens to be the community agreed upon style guide for Python.

1 Like
5

It’s not that generic! It’s a guide for writing code in the standard library. It got much more widely adopted because it’s a reasonable set of guidelines and people crave a standard to point to, so they don’t have to think about it.

3 Likes
6

When I say “generic” I mean that it’s the baseline as opposed to a team specific style guide. That’s where we start and then groups tweak it to create their own. I’ve never been on a team that attempts to follow every part of PEP8 - they all tweak (usually by expanding to cover things that aren’t covered) to some degree.

1 Like
7

Dear Avi,

Thank you for your comment.

Yes, in fact I can choose to ignore certain rules with:

image
in my pycodestyle file. This is more about the fact that I do not agree with certain guidelines, I think they make the code less readable so I am uncomfortable with the fact that on the one hand one should try to conform to a uniform way of writing code, such that it is sharable and we make life easier for everyone. On the other hand that seems to mean lowering the quality of my code.

8

in fact I can choose to ignore certain rules with:

image
in my pycodestyle file.

So the warnings themselves aren’t, strictly, the issue here for you.

This is more about the fact that I do not agree with certain
guidelines, I think they make the code less readable so I am
uncomfortable with the fact that on the one hand one should try to
conform to a uniform way of writing code, such that it is sharable
and we make life easier for everyone. On the other hand that seems
to mean lowering the quality of my code.

For your own code, style it in the way you find most readable.
I certainly do, and run pycodestyle with several warnings disabled.
I also use yapf to autoformat my code, which is very configurable,
as opposed to black or ruff, which pretty much use pure PEP8.

There are some things which yapf can’t be told to do, like your value
alignment example which I also like, but it is close enough that I’ll
accept what I can get from yapf.

The trouble with readability is that some things are genuinely
subjective. PEP8 is a decent starting point. My own yapf settings are
PEP8 as a baseline, with several modifications.

The basic rules are:

  • the stdlib uses PEP8
  • use whatever you like for personal code; you get to choose what is
    highest quality by your own criteria
  • in a group such as a shared project or workplace, most teams agree to
    a common style so that the code is at least consistently formatted;
    you need to get people to agree to changes to that style

A lot of teams punt on this to a degree.
Using autoformatters has a few advantages:

  • all the code gets a consistent style
  • there isn’t diff churn from styling changes
  • as a dev you don’t need to spend time arduously aligning code in a
    specific way, though the are some idioms which encourage particular
    types of layout

PEP8 is pretty readable, the black and ruff autoformatters are fast
and apply PEP8 quite rigorously. Many devs seem happy to accept that
as a performant and adequate approach. If nothing else, it is easier
than convincing everyone to use a different style.

1 Like