Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add style formatter #487

Merged
merged 5 commits into from
Aug 29, 2024
Merged

Add style formatter #487

merged 5 commits into from
Aug 29, 2024

Conversation

Sazerac4
Copy link
Contributor

@Sazerac4 Sazerac4 commented Aug 28, 2024

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;

- LLVM style
- IndentWidth: 4
- ColumnLimit: 0
@Sazerac4
Copy link
Contributor Author

Sazerac4 commented Aug 29, 2024

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
Copy link
Owner

rokath commented Aug 29, 2024

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

  • Should *.svg files treated as binary files too inside .gitattributes?
  • I personally think, that a tabulator is the best for indent. Everybody can config its editor tab size. Should that be changed?
  • For my taste indented compiler switches improve code readability. May be that is a change worth to do?

@rokath rokath merged commit 84fc77e into rokath:master Aug 29, 2024
@Sazerac4
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants