Create `.editorconfig`

[Alvaro-Kothe]

Pandas currently uses several formatters (e.g., meson-fmt, clang-format, ruff format) in its .pre-commit-config.yaml to enforce code style. To further improve developer experience, we could add .editorconfig. This helps text editors and IDEs apply formatting settings (e.g., spell language, text width, charset, etc.) that align with the project rules.

[Zrahay]

I was wondering if I could take this up if no one's working on this? 😊

[Zrahay]

Hey @Alvaro-Kothe! Should it also include support for file types .yaml, .md, .rst and .sh?

Thanks!

[Alvaro-Kothe]

Should it also include support for file types .yaml, .md, .rst and .sh?

I don't think it's necessary to specify the format for .md, so it should fall in the general ruleset. Specifying the format for *.yaml, *.rst and *.sh as long with other source code formats in this project (Python, Cython, C and meson) should be beneficial.

[rhshadrach]

If we add such a file, does it change the way IDEs (PyCharm, VS Code) behave automatically?

[Alvaro-Kothe]

If we add such a file, does it change the way IDEs (PyCharm, VS Code) behave automatically?

Yes, an .editorconfig file can define code formatting settings across IDEs per file type, and it will override default — or user-defined — settings if needed. Here's how it affects PyCharm and VS Code:

• VS Code: Requires a plugin to recognize .editorconfig files. Once installed, it will apply settings based on the file type.
• PyCharm (and other JetBrains IDEs), Vim, NeoVim, Emacs: Has built-in support for .editorconfig, so no additional setup is needed. It automatically adjusts formatting according to the file's rules, overriding default settings if configured.

For example, If you have a default "tab as spaces" and indent size of 4, adding an .editorconfig file with the following content:

root = true

[*.{yaml,yml}]
indent_style = space
indent_size = 2

[Makefile]
indent_style = tab

Will change the behavior for .yaml and .yml files. Pressing <Tab> in these files will insert 2 spaces instead of 4. Now, on a Makefile, it will insert a literal <TAB> character instead of spaces.

The impact of .editorconfig depends on its settings. Common adjustments include:

• Indentation: Spaces vs. tabs and indent size.
• Encoding: Enforcing utf-8 or other encodings.
• Line endings: Using lf (Unix-style) or crlf (Windows-style).
• Other: Trimming trailing whitespace or adding a final newline.

These changes are typically minor but ensure uniform formatting across tools.

This file is present in several other projects too, for example:

• Arrow
• PyTorch
• NumPy

[jbrockmendel]

no way to combine this with other stuff e.g. setup.cfg? in the old days we had a ton of these dotfiles that eventually got consolidated in setup.cfg, but i think that eventually got removed in favor of pyproject.toml.

[rhshadrach]

overriding default settings if configured.

Is a user able to override the setting? Also, when are the rules enforced? Is it whenever a file is modified in the IDE (even if not saved) or only upon saving?

I'm a bit negative here. pre-commit means that you can have your IDE set to however you want, and the code will be reformatted upon commit. It's been working well, I don't see a need for anything else. Having this file seems a bit intrusive.

[Alvaro-Kothe]

no way to combine this with other stuff e.g. setup.cfg?

Unfortunately, no. This is the default file that most text editors will look for.

Is a user able to override the setting?

Yes, it can be disabled, but it depends on the text editor. In NeoVim I can disable editorconfig with vim.g.editorconfig = false. And I also can override the setting that it applied with :set or :setlocal, I don't know how it's in other text editors.

when are the rules enforced?

.editorconfig rules are applied when a file is opened in an editor. The editor recursively searches for an .editorconfig file in the file's directory or any parent directories, applying matching rules based on file type. These settings only affect files within the project containing the .editorconfig file, leaving other projects or sessions unchanged. For example, in Pandas, only files within its directory structure are impacted. If I open a file outside of pandas, my text editor will use my default settings.

Is it whenever a file is modified in the IDE (even if not saved) or only upon saving?

It depends on the setting:

• During editing: Settings like indent_style, indent_size and max_line_length are applied as you type.
• On save: Settings like insert_final_newline or trim_trailing_whitespace are applied when saving the file, as they modify the file's content.

Only the rules explicitly defined in .editorconfig are enforced, so its scope is focused on the project and limited to what is defined.

pre-commit means that you can have your IDE set to however you want, and the code will be reformatted upon commit.

pre-commit ensures formatting at commit time, regardless of IDE settings. While, .editorconfig complements this by aligning the editor's behavior with the rules enforced by pre-commit during development. This reduces the need for pre-commit to make extensive changes, or for the contributor to do more keystrokes for the correct formatting.

[Alvaro-Kothe]

overriding default settings if configured.

Having this file seems a bit intrusive.

To clarify, .editorconfig does not modify your editor’s configuration files, such as ~/.config/nvim/init.lua, ~/.config/Code/User/settings.json or .vscode/settings.json. Instead, it applies specific formatting settings at runtime only for files within the project’s directory, leaving your editor configuration unchanged.

[Zrahay]

@Alvaro-Kothe Hey there! I was wondering if any further discussion is needed on this or should I make a PR?

[Alvaro-Kothe]

It still needs more discussion. I am still +1 on adding this file.

[Zrahay]

Cool! I'll try working on other issues till then. 😊

[rhshadrach]

Confirmed that EditorConfig can be disabled on PyCharm. I still find this a bit intrusive, but this makes me not strongly opposed.

It still seems to me like this is adding more config files to solve a problem that doesn't exist, but if other contributors find it helpful I won't oppose.

This reduces the need for pre-commit to make extensive changes, or for the contributor to do more keystrokes for the correct formatting.

I don't find this problematic.