Motivation
Developers are supposed to follow Coding style. However, from time to time a PR is created and then its author is asked to change tabs to spaces, for example.
Introducing an .editorconfig
file can mitigate these formatting issues:
User story
A contributor wants to create a new PR. She clones Bitcoin Core repo, opens her editor, the editor loads .editorconfig
rules and writes her patch with correct formatting rules. Less Coding Style issues is then discovered in the PR review process and thus less CI runs are needed.
What is EditorConfig file?
https://editorconfig.org provides very well and concise explanation:
What is EditorConfig?
EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.
Support
.editorconfig
is supported in many IDEs and text editors. Sometimes, the support is out-of-box and sometimes a plugin is needed. However, for example, VS Code detects .editorconfig
presence and automatically offers you to install the missing plugin.
See https://editorconfig.org/#pre-installed for details on support. Visual Studio is supported, VS Code and IntelliJ IDEA are supported and many others.
My editor does not support .editorconfig
Then nothing really changes for you.
.editorconfig
vs .clang-format
As explained here:
Note that Visual Studio also supports EditorConfig, which works in a similar way. ClangFormat, however, has a much larger variety of style options than EditorConfig, including some very C++ specific rules that can be set, and it is already used by C++ developers today.
Having both .editorconfig
and .clang-format
in a project, may not always work correctly though, I think. As some editors may have a plugin for .editorconfig
and a plugin for clang-formatter
which may not work correctly in unison.
Proposed .editorconfig
This proposal is based on Developer Notes:
0# This is the top-most EditorConfig file.
1root = true
2
3# For all files.
4[*]
5charset = utf-8
6end_of_line = lf
7insert_final_newline = false
8
9# Shell scripts
10[*.sh]
11indent_size = 4
12indent_style = space
13trim_trailing_whitespace = true
14
15# C++ files
16[*.{h,cpp}]
17indent_size = 4
18indent_style = space
19trim_trailing_whitespace = true
20
21# Python files
22[*.py]
23indent_size = 4
24indent_style = space
25trim_trailing_whitespace = true
26
27# Makefiles
28[Makefile,*.am]
29indent_style = tab
30trim_trailing_whitespace = true
31
32# Markdown files
33[*.md]
34trim_trailing_whitespace = true
35
36# .cirrus.yml, .appveyor.yml, .fuzzbuzz.yml, etc.
37[*.yml]
38indent_style = space
39indent_size = 2
40trim_trailing_whitespace = true
Note that the syntax can be much shorter but it is not my goal here, I prefer clarity at this point.
So what is this specifying:
charset
: UseUTF-8
in all files.end_of_line
: Line endings should beLF
by default in all files.insert_final_newline
: Do not add a blank line at the end of a file by default.
And then there are rules for various types of files.
The rules does not cover everything. One can see that there actually many different file types (meaning, unique file extensions) using this simple PowerShell script:
0Get-ChildItem -Recurse | % {$_.Extension.ToLower()} | sort | unique
with the following output:
0.1
1.ac
2.adoc
3.am
4.bash-completion
5.bat
6.bmp
7.c
8.cc
9.cert
10.cfg
11.clang_complete
12.clang-format
13.cmake
14.cmd
15.cnf
16.com
17.conf
18.cpp
19.css
20.csv
21.doxyfile
22.dtd
23.empty
24.exe
25.exp
26.gci
27.gitattributes
28.github
29.gitignore
30.gitmodules
31.guess
32.h
33.hex
34.hpp
35.html
36.icns
37.ico
38.idb
39.ilk
40.in
41.include
42.ini
43.init
44.ipp
45.jam
46.js
47.json
48.lastbuildstate
49.lib
50.list
51.log
52.m
53.m4
54.md
55.mk
56.mm
57.moc
58.obj
59.openrc
60.openrcconf
61.patch
62.pc
63.pdb
64.pl
65.plist
66.png
67.po
68.pro
69.py
70.python-version
71.qbk
72.qm
73.qml
74.qrc
75.raw
76.rb
77.rc
78.recipe
79.res
80.s
81.sage
82.sass
83.scm
84.scss
85.service
86.sgml
87.sh
88.sln
89.spec
90.sub
91.supp
92.svg
93.targets
94.td
95.tlog
96.ts
97.tx
98.txt
99.ui
100.user
101.v2
102.vcxproj
103.verbatim
104.vscode
105.xml
106.xpm
107.xsl
108.y
109.yapf
110.yml
111.yy
What do you think?