rokath / trice

🟒 super fast πŸš€ and tiny πŸ₯ embedded device 𝘾 printf-like trace ✍ code, works also inside ⚑ interrupts ⚑ and real-time PC πŸ’» logging (trace ID visualization πŸ‘€)
MIT License
517 stars 46 forks source link

Add style formatter #487

Closed Sazerac4 closed 2 months ago

Sazerac4 commented 2 months ago

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 have created a default syle :
clang-format -style=llvm -dump-config > .clang-format
# Then format the code:
find ./src  -name '*.c' -o  -name '*.h'| xargs clang-format-18 -style=file -i

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

int formatted_code;
// clang-format off
    void    unformatted_code  ;
// clang-format on
void formatted_code_again;
Sazerac4 commented 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 
rokath commented 2 months ago

Thank you very much for the proposals, Sazerac4! I really like them. Some questions:

Sazerac4 commented 2 months ago

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.