Create Editorconfig File as Part of Cargo Project

tools and infrastructure cargo
1

Editorconfig is a way to solve the old tabs vs spaces debate, and more. It allows to express and enforce a minimal style guide across the majority of development platforms. This becomes especially important as soon as collaborative project work enters the picture.

Let’s look at an example editorconfig configuration file:

# https://editorconfig.org
root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

It defines that for all files matching the pattern * the following rules should apply. It defines the charset, line ending character, indentation size, indentation style, whether or not a and only one new line should be inserted at the of the file and whether or not trailing whitespaces at the end of lines should be trimmed. With the exception of the indent size and style these rules are hardly controversial. Concerning indent size and style, the rust book talks about it at the very beginning here, suggesting indent size 4 and spaces.

Generally editorconfig is flexible, all rules can be specified and overwritten for patterns, using it privately and professionally for several years, I have yet to run into problems with it. The only issue is if the individuals editing platform requires a plugin and the person doesn’t know about it and or didn’t care to install it. Yet if the file is completely ignored the situation is like before and for those that know about it or have their development platform pick it up automatically it helps avoid unnecessary issues.

Creating this file as part of default cargo projects, both binary and library, has many advantages as described above. Yet there are also downsides. More generated files can increase the knowledge burden, and the chosen defaults could conflict with the individuals preference. However with the rust book explicitly stating an opinionated default, I think the upsides out way the downsides here.

Personally, every time I create a new rust project I find myself whishing it had created a editorconfig file, and then manually copying it from one of my other projects. Further this could be an opportunity to a apply a text recommendation to major parts of the rust ecosystem, given that rust tries to avoid the C++ nightmare of there are 13 different subtly different ways of doing the same thing. With this there could be one way to express a minimal style guide for the rust community, and even potentially lint against it.

Another idea would be to require it if the crate is published. That way only projects with intend of being shared require this file and the downsides it brings, yet I’d prefer introducing this file ecosystem wide, because adopting it afterwards is more hassle than if the project started with it from the beginning.

I am curious to get some feedback about this.

4 Likes
2

So far no one has left a comment, and there is handful of likes. Does that mean everyone is ok with this and I should open an RFC?

3

Ultimately, a lack of comments means nobody’s found something interesting enough to comment on. A like is low-commitment, but I’d suggest that this is probably worth opening a proper RFC for.

The full RFC should probably reference the default behavior of rustfmt to justify its choices.

4

I, and many others, may not have commented or "like"d it because our editors of choice already default to the advised Rust defaults for .rs files. Since my editors of choice use .editorconfig files when present, I simply copied the proposed default and created the file in my root projects folder.

I would support an RFC on this if one were written.

2 Likes
5

I prefer if this was part of rustfmt instead of cargo. It feels more aligned there than in cargo. Since fmt takes care of formatting and plus you already have an optional file if you want a different style.

1 Like
6

I think Rust already covers this with rustfmt, which defaults to an agreed-upon set of formatting rules (many of which are Rust-specific). If users want to stray from the default, there is rustfmt.toml. I think it would be more fruitful for editors that understand Rust (.rs files) to default to using rustfmt defaults and optionally parse rustfmt.toml (if it exists) for any deviations the Rust project at hand.

For example, I believe intellij-rust tries to make its default formatting settings as close to what rustfmt does as possible, so that editor wrapping, completion, etc is as conformant as possible.

7

The defaults for various editors for editing .rs files already match the recommended Rust style, and rustfmt covers this as well. I’d prefer not to see cargo creating a file like this just to cover the defaults.

Now, if you want to change the defaults for your projects, you might need to create configuration files specifying your preferred defaults, whether for editors or for rustfmt. In that case, you might want to make use of cargo templates to have files automatically copied into new projects you create.

But I don’t think cargo should do this by default.

8

Ideally all development platforms would see a file ending in .rs and automatically do the 'right' thing. However that is far from the reality. The chance that a majority of development platforms will ever do so are unlikely, also what does the right thing mean, all of rustfmt, parts of it, which parts? Also what about toml files or other file types generated by cargo.

With editorconfig we can have support for a well defined minimal subset of rustfmt today, supported by 18 of the 20 most used development platforms, list taken from here Stack Overflow Developer Survey 2017, and 1 with and open issue for it [enhancement] add .editorconfig support · Issue #1711 · rstudio/rstudio · GitHub.

Let's not wait and wish for a potential future, when we can take concrete steps to improve collaborative work on Rust projects by removing some needless friction today.

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.