Closed Sazerac4 closed 2 months ago
I added the .editorconfig
file which allows to better identify the basic style for every files. (endline, charset, ...). It is a file accepted by a wide list of IDEs and editors : link
This addition is motivated by forgetting the end of line in the .gitattributes
file.
I have tuned some settings for clang-format :
- IndentWidth: 4 // original code size indentation
- ColumnLimit: 0 // avoid breaking long line (like macros)
- PointerAlignment: Left // like original files (mostly)
I'm not a fan of preprocessor indentation, the result is a bit strange in some cases. It's possible with the option IndentPPDirectives
doc
I don't have much of an opinion on the rest of the options. Staying as close as possible to a default version (LLVM in this case) makes it easier to regenerate the style if necessary.
Note : to fill the gitattributes, I used the command below to view all the extensions currently used.
git ls-tree -r HEAD --name-only | perl -ne 'print $1 if m/\.([^.\/]+)$/' | sort -u
Thank you very much for the proposals, Sazerac4! I really like them. Some questions:
.gitattributes
?Should *.svg files treated as binary files too inside .gitattributes?
This is a text file format but i guess yes. Because we don't want to see text diff on a file that is which is basically an image.
For my taste indented compiler switches improve code readability. May be that is a change worth to do?
Yes, why not. In general I don't use it because my IDE obscures the non-activated part (vscode). However, this library uses a lot of preprocessor conditions, this can be useful. I think that may involve disabling indentation in certain places.
I personally think, that a tabulator is the best for indent. Everybody can config its editor tab size. Should that be changed?
The perpetual debate :D . Developers argue between choosing tabs or spaces.
What matters to me is uniformity across all the sources of a language. What some modern languages ββare trying to solve with commands go fmt
or zig fmt
. (Zig reason).
In C, with the libraries and the generated code. It's difficult to maintain this uniformity.
For STM32, I use CubeMX to generate code. They use spaces of size 2. I would tend to use this for my application code. It is avoid diff problem if I forgot to format the code.
For library, it seems impossible to standardize: FreeRTOS use Tab, littlefs use space and so on....
You are the creator of trice, you use it most often. If you prefer tabs for indentation, it's a good idea to put it like that.
You must put a default indendation size in clang-format (I leave it at 4)
I will commit the changes.
Hello,
I'm trying the "trice" library for a project and I found some fixes. I have a code formatter when I make changes to my application but I would like to keep the style of the library when modifying. I couldn't find a code formatter, is there a tool used ? If not, I propose this pull-request to provide one as an example by using clang-format.
I also added a
.gitattributes
file to avoid problems with "diff" and end of lines. Here is an article that presents the problem.The style of the example does not correspond to the original one. Configurations are necessary for this to be the case. Tags can be placed to prevent certain macros from being formatted