Code formatting style

[CSharpino]

Since I upgraded to version 3.6.4 of STM32CubeIDE for Visual Studio Code, the style used for automatic code formatting has changed. For example, curly braces are now inlined, not wrapped as they were before.
How can I revert to the old style?

[Cartu38 OpenDev]

@brucegong 

What about clang-format usage ? https://marketplace.visualstudio.com/items?itemName=xaver.clang-format

cllangd is out of LLV project like clang-format. Clang-format is dedicqted to while clangd is in real language server LLVM project has kept pieces of clang-format into. Maybe pieces are not rocking enough ?

Same FYI clangd integrates pieces of clang-tidy which is about linter feature .... but another story

[Adam Hamilton]

With your testing on the 900kb header. How did you generate the .clang-format file for the STM32 fork of clangd to use.

And when you say it failed, what do you mean exactly? Did it format it incorrectly or not at all? Or did you notice an error in the output window?

The LLVM tools for formatting are very picky about what style options are present in the .clang-format file. Any wrong key would just throw an internal error and might format using a fallback style, which is LLVM, or it not do anything at all.

I tried a test on a 200kb file as I couldn't find a larger one and using clangd-22, it was able to format the header file correctly.

[dariyvelychk]

That would be great! I often struggle with the fact that regenerated project files formatting gets messed up with my own clang ruleset.

[Cartu38 OpenDev]

@dariyvelychk unclear to me about "what would be great" ... could you explicit a bit more ?

[dariyvelychk]

I mean that if STM provided the official .clang-format file that would 100% match LL/HAL/CubeMX generated code - that would be great. As of now I either disable auto formatting, or manually reformat each generated file and leave HAL/LL untouched. 

[TDJ]

Today, after installing CubeIDE for VS Code, I spent about two hours trying to restore the code formatting I prefer.

Eventually, after finding this thread, I disabled AllowShortIfStatementsOnASingleLine in the .clang-format file and formatting started working again. It seems that when this option is enabled, the formatter fails and silently falls back to its default settings.

But this made me wonder: why does CubeIDE try to format my source code at all? There are already many well-tested and widely used formatters available. Wouldn’t it be better for ST to spend that development effort where it is more needed? I could suggest a few areas - in fact, the list would be quite long.

To be fair, aside from the code formatting issue, I have to say that my initial impression of CubeIDE for VS Code is positive.

[vincent_grenet]

@TDJ 

Thank you for sharing your feedback.

Although there are several ways to bypass the formatting process, the next update of the STM32CubeIDE for Visual Studio Code extensions will disable formatting and linting processes by default. These processes are currently enabled by default by clangd services. The update is expected in a few weeks.

A formatting feature may be included in the long-term roadmap but for now, we do not want to contribute here because the marketplace already provides facilities about.

Regarding your suggestions, please share any areas for improvement. We are eager to receive feedback - even if long list -. The upcoming update is Thanks this post feedback we have received. We cannot commit to serving all requests because supporting a collection of profiles requires making choices. However, we want to be driven by end user needs.

[Adam Hamilton]

Hi @TDJ 

I addressed a similar problem with another user on this thread and clang-format will default to its default style which I believe is LLVM if there is anything in the formatting file ".clang-format" that it doesn't recognise. It is silent and I believe the LLVM team needs to address this in their extension, such as displaying the error in a prominent way with the error detail. I have lost quite a bit of time on day when the clang-format file was saved in UTF-16 as I had generated this in Windows and was scratching my head as to why it wasn't working in Linux.

The option AllowShortIfStatementsOnASingleLine is a clang-format 3.3 option which should not have failed unless it is typed incorrectly or has a value that is not recognised.

This link Clang-Format Style Options — Clang 23.0.0git documentation takes you to that option and the supported values are

• Never
• WithoutElse
• OnlyFirstIf
• AllIfsAndElse

Don't worry too much about the version 23 page. Each style option has a version associated with it.

If you can get the clangd version that is used, this should also correspond to the version of clang-format style.

For @vincent_grenet I think it might be better to follow the user formatting and not impose ST's clang-format style options. This could probably be achieved when you generate the .c file from CubeMX, that is run it through the clang-formatter

[TDJ]

@Adam Hamilton, @vincent_grenet Thank you for the hints, the problem was AllowShortIfStatementsOnASingleLine value. I used "All" while it should be "AllIfsAndElse".
I'm glad clang-formatting can be turned off. In general, as I'm sure you know, code formatting is a sensitive topic, and even subtle rule differences can cause massive Git diffs that clutter the project’s version history.
I meant that the list of much needed improvements/fixes in ST’s code (especially HAL) would be long, but I understand that’s a completely different story and handled by different team(s).