Should we have some sort of code style?
See original GitHub issueI notice there’s not much consistency across the codebase in some cases (e.g., 'strings'
and "strings"
, etc.). Any code style is good enough (I really like black). This could be enforced in a post-commit or post-merge hook.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Why Coding Style Matters - Smashing Magazine
Coding style guides are an important part of writing code as a professional. Whether you're writing JavaScript or CSS or any other language, ......
Read more >How important is a good coding style for the decision to hire a ...
Taking coding style to mean things like naming, general ordering, unit separation, and everything else that deals with readability and ...
Read more >Code Style and Formatting - The Turing Way
A coding style is a set of conventions on how to format code. For instance, what do you call your variables? Do you...
Read more >Why Enforcing Code Style is Important - Cory Rylan
Why should we care about code styles? Isn't it enough that our code works? Well there are a couple of reasons to care...
Read more >Coding conventions (code style)
Everyone has opinions about coding style. This document contains some high-level advice. It doesn't go into minutiae like how many spaces per indentation...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
What Minsik said was indeed true. I have some new thoughts about this.
I agree with making it easier to contribute. Personally I think precommit hooks are a little tedious on developers since it requires them to set it up, but I am open to discussion on that point.
I do think just running
black -l 100
on the source and adding a github action to check if future contributions abide by the constraints sounds like a good option.This is correct on all points. I’m not sure it would be as bad as some renames or moves: I needed multiple revision checkouts to see the original history of
io
.One more concrete (and common) concern is that it will mess with all open PRs, so we should try and push them through before running a formatter. Rebasing them after formatting the codebase will be a pain.
I use black as part of https://pre-commit.com/ (but not in GHA) for all my other projects. I think we should do whatever makes contributing to the code and modifying it easier.