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?

 

[Adam Hamilton]

Have you tried using clang-format?

I would imagine if you don't have a .clang-format file then your formatting might just take on a default LLVM style which uses inline braces.

If you have clang format installed, you can generate an appropriate clang-format file using the following command in the root of your project.

clang-format --style=Microsoft --dump-config > .clang-format

You can then customise this file. There are of course other styles you can use, see this link ClangFormat — Clang 22.0.0git documentation

This should allow the clangd extension that is installed by STM32CubeIDE extension to format the code when you trigger the formatting command

[t_j_l]

Yes, I have also encountered this situation and felt extremely uncomfortable.

[CSharpino]

Have you found a solution to this problem?
I managed to get back the formatting I used before by simply removing the STM clangd extension and re-enabling the intellisense and formatting features of the Microsoft C/C++ extension.

[vincent_grenet]

STM32CubeIDE for Visual Studio Code does not force any formatting features.

We promote clangd to support code indexing, enabling code navigation and enhancing the VSCode editor experience. Clangd is a utility toolbox capable of static code checking and code formatting. However, we do not provide any settings that enforce its usage but it may be used.

Please check your local VSCode setup via the command palette:

Try "Format Document With..." while a .c file is active:

You control which formatter to use.

PS: Without any third-party formatting extensions (like Prettier or others from the marketplace), VSCode defaults to the only available formatter.
 
 

I’m taking this opportunity to ask you about formatting features. We are considering promoting some optional formatting tools. Please don’t worry; we don’t want to force anyone but simply offer an additional optional service.

The rationale would be to provide formatting capabilities aligned with the style we apply internally to our drivers, middleware, and example code bases delivered as part of the STM32Cube ecosystem. This would improve the user experience without reformatting everything in case local setups that most end users may not focus on, which often causes surprising source control diffs. What do you think? Would this be valuable?

[CSharpino]

If STM32CubeIDE doesn't enforce any formatting features, why am I faced with files formatted differently after updating this extension?
And why does the formatting work correctly again when I remove all STM32 extensions?
And why does it not work correctly again when I reinstall STM32CubeIDE extensions?

[vincent_grenet]

@CSharpino as shared Thanks my very first answer VSCode takes itself formatter contribution if any.
If you start from none VSCode has nothing to take.
Then you add STM32CubeIDE for Visual Studio Code which is serving a formatter engine solution (without forcing it) so VSCode is able to take one .. this one.
Uninstalling then VSCode is back to initial state ie. nothing to take. 
Here is rational according to my understanding.

[CSharpino]

I installed LLVM and used the clang-format command to generate the .clang-format file in the root of my application, but nothing changed. The brackets still move inline.
I also tried uninstalling the STM extensions, and the formatting works correctly again. The incorrect style starts to appear when I install the STM extensions and disable the C/C++ extension's intellisense, as required by the STM extension.

The format file I'm using is the one attached.

 

[vincent_grenet]

@CSharpino to "help" you in the short term, please be aware that the clangd extension promoted as part of the STM32CubeIDE for Visual Studio Code extension pack is optional. You can easily disable or remove it. For more details, see: https://community.st.com/t5/stm32cubeide-for-visual-studio/quot-stm32cube-for-visual-studio-code-quot-extension-pack/td-p/836206

I’m convinced you can still get everything working locally while keeping it enabled, but the choice is yours.

[vincent_grenet]

@Adam Hamilton , thank you very much for this valuable contribution!

I hope @CSharpino  is now receiving proper answers. I would like to take this opportunity to ask again about formatting features, as the question got a bit lost within the previous discussion.

We are considering promoting some optional formatting tools—not to force anyone, but to offer an additional service. The goal is to provide formatting aligned with the style we use internally for drivers, middleware, and example code in the STM32Cube ecosystem. This would improve user experience without reformatting everything, which often causes unexpected source control diffs, especially given local setups that many end users may not adjust.

What do you think? Would this be valuable?

[CSharpino]

I think ST should prioritize development and debugging tools and leave code formatting to tools already available and widely used by developers.

To date, your extensions still don't support SWO for debugging!
You've added a button to flash an LED on the STLinkV3Pwr, but it would be much more useful to be able to turn the power on and off or send a reset command without having to constantly switch to STM32CubeMonitor-Power, which also crashes and needs to be reset very frequently.

 

[brucegong]

I tested this topic with a 900KB header file (a character library header file for a stm32 project), and the results are as follows:
1. On the Ubuntu platform, using VSCode + STM32 plugin group, code formatting failed, regardless of whether clang-format was used. Both VSCode and the ST plugin are the latest versions.
2. On the same Ubuntu platform, using nvim + clangd, formatting also failed, regardless of whether clang-format was used. Both nvim and clangd are the latest versions.
3. On Windows 11, using VSCode with Microsoft's C++ plugin, formatting succeeded.
4. Once the file was successfully formatted, any slight modifications to it in any of the combinations above could be formatted successfully.
So, this issue might be due to limitations in clangd itself.

[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