Automatic code formatting #574

rettichschnidi · 2021-04-02T18:21:24Z

Historically, the Wakaama code base did not use any kind of code formatting tools. Therefore, every file looks slightly different, making it more hard than necessary to read the code, figuring out and sticking to the predominant style.

Therefore, for C code I propose to pick clang-format (version 10 for now), using a code style close to the one LLVM, the creators of clang-format, use. Foreseeable adaptions might be:

IndentWidth: 4 (instead of 2)
ColumnLimit: 120 (instead of 80; current often oversteps the 80 characters boundary)

For CMake files, https://github.com/cheshirekow/cmake_format seems to be the tool to pick.

Acceptance criteria:

Changes must be done in commits which are limited exclusively to cosmetic/style changes
Above commit id(s) can be stored in a --ignore-revs-file file (supported since Git 2.23).
GitHub Action in place to prevent merging of non-formatted code
Tools and exact versions to use defined
Files in coap/er-coap-13 (and examples/shared/tinydtls) should not be touched
~~Code and comments checked for being garbled, exceptions in place where sensible~~ did not format the whole code base

Please note:

This is issue complements Define code styling rules #513

Any opinions on this?

sbernard31 · 2021-04-06T10:04:41Z

I guess we definitely need something like this. 👍

About tools to use and format rules, I let the team decide what best fits.

tuve · 2021-04-12T09:15:39Z

I am really in favor of picking a standard like clang-format as suggested, as I do not see any real advantage in relation to the effort to maintain our own standard (or deviation from an existing standard).

qleisan · 2021-04-13T09:25:18Z

I'm in favor of adopting a code standard. No strong opinions on the specifics, what is suggested above works for me. Before any decision is made we should get input from @sbertin-telular also.

sbertin-telular · 2021-04-19T15:54:32Z

I'm also in favor of a code standard with no strong opinions on the specifics. If it can easily be automated and enforced even better.

The er-coap-13 is exempt as we might want to get upstream changes merged at some point.

Used command: find coap core data examples include tests -type f -not \ -path 'examples/shared/tinydtls/*' $ -name '*.c' -or -name '*.h' $ \ -exec clang-format-10 --style=file -i "{}" \;

All future cosmetic only commits should be appended to this list. This allows "git blame" to ignore them: git config blame.ignoreRevsFile .git-blame-ignore-revs

The er-coap-13 is exempt as we might want to get upstream changes merged at some point.

Used command: find coap core data examples include tests -type f -not \ -path 'examples/shared/tinydtls/*' $ -name '*.c' -or -name '*.h' $ \ -exec clang-format-10 --style=file -i "{}" \;

All future cosmetic only commits should be appended to this list. This allows "git blame" to ignore them: git config blame.ignoreRevsFile .git-blame-ignore-revs

The er-coap-13 is exempt as we might want to get upstream changes merged at some point.

This ensures that all code being submitted adheres to the format dictated by clang-format. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

git-clang-format ensures that all code being submitted adheres to the format dictated by clang-format. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

git-clang-format ensures that all code being submitted adheres to the format dictated by clang-format. The code style is based on LLVM (the creator of clang-format), but with 4 instead of 2 spaces indent width and a maximum of 120 instead of 80 characters per line. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

rettichschnidi · 2021-04-23T22:23:08Z

I tried different clang-format style definitions to approximate the style being used most often. However, always ended up with man thousands of line changes. And while using --ignore-revs-file would work for Git itself, many 3rd-party-tools (like SonarQube) do not support it, blaming me for all the issues... :/

Therefore, I implemented a partial solution for this issue: #595

It enforces the code style on new code, which is far less intrusive than formatting all existing code. Would like to get some feedback on it.

git-clang-format ensures that all *new* code being submitted adheres to the format dictated by clang-format. The code style is based on LLVM (the creator of clang-format), but with 4 instead of 2 spaces indent width and a maximum of 120 instead of 80 characters per line. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

git-clang-format ensures that all *new* code being submitted adheres to the format dictated by clang-format. The code style is based on LLVM (the creator of clang-format), but with 4 instead of 2 spaces indent width and a maximum of 120 instead of 80 characters per line in order to blend well with existing code. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

git-clang-format ensures that all *new* code being submitted adheres to the format dictated by clang-format. The code style is based on LLVM (the creator of clang-format), but with 4 instead of 2 spaces indent width and a maximum of 120 instead of 80 characters per line in order to blend in well with existing code. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

I used the following script: for f in $(find . -type f $ -name '*.c' -or -name '*.h' $ \ -not -path '*/examples/shared/tinydtls/*' \ -not -path '*/coap/er-coap-13/*'); do end="$(grep --line-number --extended-regexp "\\*{70}/" "${f}" | awk -F: '{print $1}')" echo "Formatting ${f}, line 1 to ${end}" clang-format-10 -i --lines="1:${end}" "${f}" done

The last commit was purely cosmetic. Therefore, adding it to .git-blame-ignore-revs.

git-clang-format ensures that all *new* code being submitted adheres to the format dictated by clang-format. The code style is based on LLVM (the creator of clang-format), but with 4 instead of 2 spaces indent width and a maximum of 120 instead of 80 characters per line in order to blend in well with existing code. Please note: - The er-coap-13 code gets exempt, as at some point, we probably want to to interact with whatever upstream there might be. For those files, just do what existing code does (which varies every few lines). - Default is clang-format-10, which is available in the Ubuntu 20.04 GitHub runner.

I used the following script: for f in $(find . -type f $ -name '*.c' -or -name '*.h' $ \ -not -path '*/examples/shared/tinydtls/*' \ -not -path '*/coap/er-coap-13/*'); do end="$(grep --line-number --extended-regexp "\\*{70}/" "${f}" | awk -F: '{print $1}')" echo "Formatting ${f}, line 1 to ${end}" clang-format-10 -i --lines="1:${end}" "${f}" done

The last commit was purely cosmetic. Therefore, adding it to .git-blame-ignore-revs.

rettichschnidi · 2021-04-27T12:47:58Z

With #595 merged, only the CMake formatting capabilities are missing.

sbertin-telular · 2021-05-10T14:44:01Z

This is in reference to #602 (comment). It seems off topic there.

A pure cosmetic patch which reformats just the portion of code changed creates a burden on the developer. They need to make their changes to find out what needs reformatting, reformat, commit, and re-apply their changes. Repeat if more changes are requested in the pull request. Meanwhile unchanged code doesn't get the formatting updated. This could lead to a real mess. I'd rather see the code reformatted entirely (maybe 1 file per pull request to be more manageable) and move forward from there.

cmake-format ensures that our CMake code adheres to the format dictated by cmake-format. The code style is based on default one, with some minor adjustments.

cmake-format ensures that our CMake code adheres to the format accepted by cmake-format. The code style is based on default one, with some minor adjustments.

rettichschnidi · 2022-01-30T15:48:42Z

Took a stab at the remaining linting/formatting of CMake code in ##653.

Since most of the CMake code got changed for #653, I went on to reformat all files, and therefore it will be possible to just run cmake-format on all CMake files like this:

git ls-files '*CMakeLists.txt' '*.cmake' | xargs cmake-lint

This is in reference to #602 (comment). It seems off topic there.

A pure cosmetic patch which reformats just the portion of code changed creates a burden on the developer. They need to make their changes to find out what needs reformatting, reformat, commit, and re-apply their changes. Repeat if more changes are requested in the pull request. Meanwhile unchanged code doesn't get the formatting updated. This could lead to a real mess. I'd rather see the code reformatted entirely (maybe 1 file per pull request to be more manageable) and move forward from there.

@sbertin-telular This will not happen for the CMake files.

cmake-format ensures that our CMake code adheres to the format accepted by cmake-format. The code style is based on default one, with some minor adjustments.

This ensures we can always run cmake-format on our CMake files.

rettichschnidi · 2022-02-08T21:34:07Z

With #655 merged, this should be done for good. If the partial formatting of C code turns out to be too much of an issue, please reopen or create a new issue.

rettichschnidi · 2023-04-13T12:31:04Z

The current method (require new code do be properly formatted) actually requires (cosmetic) changes quite far apart from the actual code change. This either results in (too) noisy commits (a) or, when striving for separation of functional and cosmetic changes, requires a follow-up commit (b):

(a) makes it hard to reason about and reviews contributions and (b) is not something we can seriously ask from any contributors IMHO.

Therefore, I can also to the conclusion that reformatting the entire code base is the way to go. I will create a PR shortly.

rettichschnidi added a commit to rettichschnidi/wakaama that referenced this issue Apr 2, 2021

[eclipse-wakaamaGH-574] .clang-format: Add and format code

3414082

rettichschnidi changed the title ~~Automatic code formatting~~ Automatical code formatting Apr 5, 2021

sbernard31 added the discussion label Apr 6, 2021

rettichschnidi changed the title ~~Automatical code formatting~~ Automatic code formatting Apr 22, 2021

rettichschnidi added a commit that referenced this issue Apr 22, 2021

[GH-574] .clang-format: Add configuration

048b727

The er-coap-13 is exempt as we might want to get upstream changes merged at some point.

rettichschnidi added a commit that referenced this issue Apr 22, 2021

[GH-574] Add initial .git-blame-ignore-revs

f329a1f

All future cosmetic only commits should be appended to this list. This allows "git blame" to ignore them: git config blame.ignoreRevsFile .git-blame-ignore-revs

rettichschnidi added a commit that referenced this issue Apr 22, 2021

[GH-574] .clang-format: Add configuration

d5cf9c3

The er-coap-13 is exempt as we might want to get upstream changes merged at some point.

rettichschnidi added a commit that referenced this issue Apr 22, 2021

[GH-574] Add initial .git-blame-ignore-revs

dcbe5e2

All future cosmetic only commits should be appended to this list. This allows "git blame" to ignore them: git config blame.ignoreRevsFile .git-blame-ignore-revs

rettichschnidi added a commit to rettichschnidi/wakaama that referenced this issue Apr 23, 2021

[eclipse-wakaamaGH-574] .clang-format: Add configuration

1fc8e1e

The er-coap-13 is exempt as we might want to get upstream changes merged at some point.

rettichschnidi added a commit to husqvarnagroup/wakaama that referenced this issue Apr 26, 2021

[eclipse-wakaamaGH-574] blame: Declare Eclipse header cleanup

6ea3d16

The last commit was purely cosmetic. Therefore, adding it to .git-blame-ignore-revs.

rettichschnidi added a commit that referenced this issue Apr 27, 2021

[GH-574] blame: Declare Eclipse header cleanup

c82a022

The last commit was purely cosmetic. Therefore, adding it to .git-blame-ignore-revs.

rettichschnidi mentioned this issue Nov 12, 2021

Integration of Mbed TLS for lwm2mclient example #626

Open

rettichschnidi mentioned this issue Jan 30, 2022

Modernize CMake #653

Merged

rettichschnidi added the easy label Jan 30, 2022

rettichschnidi added a commit that referenced this issue Feb 4, 2022

[GH-574] ci: Configure and integrate cmake-format

d57d547

cmake-format ensures that our CMake code adheres to the format accepted by cmake-format. The code style is based on default one, with some minor adjustments.

rettichschnidi added a commit to husqvarnagroup/wakaama that referenced this issue Feb 4, 2022

[eclipse-wakaamaGH-574] ci: Enforce CMake formatting

5d8af60

This ensures we can always run cmake-format on our CMake files.

rettichschnidi added a commit to husqvarnagroup/wakaama that referenced this issue Feb 4, 2022

[eclipse-wakaamaGH-574] ci: Enforce CMake formatting

2526f21

This ensures we can always run cmake-format on our CMake files.

rettichschnidi added a commit that referenced this issue Feb 8, 2022

[GH-574] ci: Enforce CMake formatting

6eaeea2

This ensures we can always run cmake-format on our CMake files.

rettichschnidi closed this as completed Feb 8, 2022

rettichschnidi reopened this Apr 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Automatic code formatting #574

Automatic code formatting #574

rettichschnidi commented Apr 2, 2021 •

edited

Loading

sbernard31 commented Apr 6, 2021

tuve commented Apr 12, 2021

qleisan commented Apr 13, 2021

sbertin-telular commented Apr 19, 2021

rettichschnidi commented Apr 23, 2021 •

edited

Loading

rettichschnidi commented Apr 27, 2021

sbertin-telular commented May 10, 2021

rettichschnidi commented Jan 30, 2022

rettichschnidi commented Feb 8, 2022

rettichschnidi commented Apr 13, 2023

Automatic code formatting #574

Automatic code formatting #574

Comments

rettichschnidi commented Apr 2, 2021 • edited Loading

sbernard31 commented Apr 6, 2021

tuve commented Apr 12, 2021

qleisan commented Apr 13, 2021

sbertin-telular commented Apr 19, 2021

rettichschnidi commented Apr 23, 2021 • edited Loading

rettichschnidi commented Apr 27, 2021

sbertin-telular commented May 10, 2021

rettichschnidi commented Jan 30, 2022

rettichschnidi commented Feb 8, 2022

rettichschnidi commented Apr 13, 2023

rettichschnidi commented Apr 2, 2021 •

edited

Loading

rettichschnidi commented Apr 23, 2021 •

edited

Loading