Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

project metadata: specify maximum line length for flake8/pycodestyle #37

Merged
merged 1 commit into from Nov 21, 2023

Conversation

marcusmueller
Copy link
Contributor

After throwing a bit of eyeballing on the existing code base, 120 characters seems to be a common enough and sensible choice of maximum line length

After throwing a bit of eyeballing on the existing code base, 120 characters seems to be a common enough and sensible choice of maximum line length

Signed-off-by: Marcus Müller <marcus@hostalia.de>
Copy link
Collaborator

@Teque5 Teque5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with merging this, but have you considered 88?

Curious what is your procedure to use flake8 and/or pycodestyle?

Generally I run black on python code then run flake8 just to make sure I don't have unused variables or imports.

@marcusmueller
Copy link
Contributor Author

I'm okay with merging this, but have you considered 88?

I hadn't; the motivation came from even sensibly short lines being broken down by my tooling; I hence opted to go with what seemed to encompass most of the current codebase

Curious what is your procedure to use flake8 and/or pycodestyle?

Neovim + pylsp reads tox.ini's [flake8], pycodestyle is used by the GNU Radio CI, and my best guess was that if we do it for one, we should do it for both tools. (very annoying they use different sections, anyways…)

Generally I run black on python code then run flake8 just to make sure I don't have unused variables or imports.

I usually use the LSP key bindings in my editor to clean up indents, empty line counts and other "mechanical" stuff, and typically only run black when I'm working on a new file – it tends to change too much on existing code bases.

@Teque5 Teque5 merged commit 55950f4 into sigmf:main Nov 21, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants