(I possbily should start a topic on “common repository structure/layout” at this point , but this is the last one, I swear)
“EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.”
The benefit in contrast to lints/formatting checkers running in CI is that EditorConfig applies in the local editor, i.e. the formatting is correct without invoking any tool, neither locally nor in CI.
I love EditorConfig, and I agree we should standardize our formatting. For the large part I think the solution is to use nixfmt-rfc-style to avoid having to deal with nix settings in the EditorConfig, but we should standardize our markdown settings, and other languages or markups as they arise.
I’m in agreement with this. One major thing we should keep track of is making sure the editorconfig matches whichever formatter the language uses (prettier for JS/TS, black for PY, cargo fmt for RS, etc.)
I’ve added the pieces that I know to be correct, I am planning on going through and looking at other langs later, feel free to add to it, or even just comment some languages you would like to see up there.
Now that I think about it some more: I think we should set up some place, where stuff like repo structure guidelines (stuff like: name is kebab case, readme contains badges of SIGs that maintain the repo, editorconfig, and probably some other stuff I’m already forgetting) and other ‘if you set up a new Y for your SIG, you can follow this’ stuff is.
For now, I mainly want this to reduce the work required when setting up the basic stuff for new SIGs with out having to keep up with each forum thread (not that it’s bad we have so many forum threads - I’m genuinely amazed at the amount of stuff we’re getting done (are some of you even sleeping at all ) - but it’s still a lot to keep up with).
I’m not sure how beneficial this place is in the long term, but on the other hand: small deviations in each SIGs repo would lead to nobody knowing what exactly the plan was in the beginning. Preventing that from the start doesn’t seem like that bad of an idea.
Fully on board with this - tabs allow users to customize line spacing in their editor to their personal preference. Unfortunately in some languages it’s unavoidable (Python, Haskell iirc, come to mind) so we do need to make a decision there (if we even can… python…). But agreed, tabs where possible.
Hi! Is it possible to leave out indent_size = 4 from the config? Since indent style is set as tab, the size is only visible locally and users can configure that per their taste/needs. Unless I’m missing something, please let me know.
If nobody beats me to it, I’ll compile a list for the languages in the wiki article with how their tab support is (both language and formatter/linter wise) this afternoon.
I will note that the configs that have a formatted listed for them will replace tabs with spaces unfortunately. At the very least I know python and JS/TS does
python: supported by the language; but discouraged by the community’s formatting guidelines (PEP8); not officially supported in pycodestyle (in the sense that: the error for ‘using tabs instead of spaces’ can be suppressed, but the tabs may lead other checks to raise spurious errors)
, but this is the last one, I swear)
) - but it’s still a lot to keep up with).