Closed Okeanos closed 1 year ago
I wouldn't go too crazy and obviously not on the source code files. We also have platform specific files in there that have different formats. Line length is much less important in non source files.
That's perfectly reasonable. To expand and update the previous example it's probably best to start with the existing rules and text file rules and not have a general [*]
block.
# https://EditorConfig.org
# https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties
# top-most EditorConfig file
root = true
# General rules for all files:
# [*]
# Don't exist yet and have to be carefully evaluated before introduction
# C++ files:
[*.{cpp,h}]
indent_style = space
indent_size = 4
# Special handling of particular file types:
[*.ui]
indent_style = space
indent_size = 2
# Plain text files:
[*.{adoc,conf,css,editorconfig,gitattributes,gitignore,html,ini,js,md,plist,properties,svg,txt,xml,yaml,yml}]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = false
indent_style = space
indent_size = 2
# Other uncategorised I could identify as plain-ish text files:
# [*.{cmake,qss}]
# Rules missing
Summary
During the two pull requests I created for the documentation, I noticed that the documentation files have mixed formatting and contain unnecessary trailing whitespace among other things. Additionally, there is no clear guidance in the Coding Styleguide concerning e.g. line endings of files, BOM/no BOM, file encoding (ASCII, UTF-8, …), max line length. Some effort, especially for code styling appears to be available via
clang-format
. This requires additional tooling/running additional commands, though.I propose that an EditorConfig file be added to the repository that enforces such technical details across a wide variety IDEs and editors, making future contributions easier and reduce noise during diffs.
Examples
An example editor config could look like the following and would be added to the root of the repository:
Checking and enforcing could be done initially with e.g. eclint or editorconfig-tools.
Context
Contributors would no longer need to configure their IDE/editor manually to be able to contribute without breaking existing formatting.
Additionally, this would make formatting across the project uniform and enforceable easily. In particular running
find . -type f -exec bash -c 'file "${0}"' {} \; | cut -d ':' -f2 | sort | uniq
on the project yields output containing the following output:As you can see … there's lots of variety in there that may cause confusion and issues.
After adding such a config file the project probably needs to be carefully reformatted according to prevent future churn.
If there's enough support for this I would be willing to spend some time on preparing a pull request + subsequent reformatting.