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?

[vincent_grenet]

@CSharpinoYou are kind of confirming my point.
You don’t start from scratch; instead, you disable one extension and add another, so VSCode always sees only one active formatter and uses it.

Yes, we are aware that the C/C++ extension is common, valuable, and appreciated, so we take care to:

• Not force clangd usage—you can disable it as part of our offer.
• Promote help to get the best experience, whether using clangd or the C/C++ extension.

 Unfortunately, because of VSCode marketplace limitations, we cannot conditionally promote extensions or prevent an extension from being installed if another is already present. Extension packs cannot control this. I wish life were as simple as you say!

The fact is, nothing is forced. At a point you are confirming you're getting notification to ask you to make a choice—so you can select the best option for yourself.

To conclude, our promotion of clangd is based on its open-source origin. This allows us to act and improve it over time, unlike the C/C++ extension, which is a closed solution.

[CSharpino]

Making me click on a notification isn't a solution...
The message in that notification mentions disabling intellisense, but the formatter IS NOT intellisense.

I don't see it written anywhere: "WARNING: If you disable C/C++ intellisense, your default formatter will become STM Clang, and you may end up with differently formatted code."
These three lines in the documentation would have been enough to solve all the problems and allow users to make informed choices.

It won't be possible to prevent installation if another extension is already present, but since you recommend installing the full package of all extensions at once if the goal wasn't to force the use of your extension once installed, when you run the conflict check, instead of asking me to disable the C/C++ extension with misleading messages, you could have disabled STM Clang.

Finally, the default format used by the STM Clang formatter is not even the one you use for your libraries or in the code generated by CubeMX. If you really want to have your extension used by the user, disabling one of the most used extensions in the store, at least ensure that you are consistent with yourself.

[Adam Hamilton · Accepted solution]

Good day @CSharpino I am assuming the attached clang-format.txt file was renamed to clang-format.txt so that it could be attached to the comment. Please note that if you used the file as is, clangd would default to the LLVM style, which formats braces on the same line. Also note that I used your clang-format file and encountered an error. I believe it was AlignFunctionDeclarations. This is not supported by the starm-clangd executable and clangd is very unforgiving to non-recognised keys. This will result in it defaulting to LLVM style, which may be the case for you.

If you have generated a clang-format file using a later version using a style, it will use every key available in its arsenal. My advice to you would be to make your own .clang-format file and copy out options from here Clang-Format Style Options — Clang 22.0.0git documentation based on what you want. Each option will have a version associated with it and if you ensure you only use options that are version 18 and less, you will be ok. This is time consuming, but it allows complete customisation of how you want things styled.

I have attached a clang-format file that I generated based on Microsoft style using clang-format version 18.1.3 and this correctly formats my files when I tested it. Please download this, rename to .clang-format and copy it to the root of your project. You can always tweak the options as you see fit.

Anyway, one thing that I do that prevents headaches like the one you encounter with conflicting extensions is to create profiles and only install extensions that are required so my best advice is to create a new profile, name it STM32 and only install the stm32cubeide extension pack.

[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.

[CSharpino]

Thanks @Adam Hamilton , yes, the file I generated is called .clang-format, but I had to rename it because it wouldn't let me attach it with that name.
Regarding the unsupported function, I generated that file using the latest version of clang-format (21.1.5), installing it manually because the ST extension doesn't seem to contain this tool.
Should I use version 18 or lower because the LLVM fork made for STM32Cube clang is stuck at that version? (I also couldn't find any information about this in the documentation.)

In any case, I tried your file and it seems to work, so thank you for your help.

[Adam Hamilton]

@CSharpino The clangd version I believe that the ST fork uses is 19.1 so you could use options at version 19 and below, but you will know if it doesn't work when your formatting fails and reverts to the LLVM style.

Alternatively, you can check the output of the clangd tool by selecting the STM32Cube clangd as in the screenshot below.

It can tell you exactly why the formatter failed.

Suffice it to say, you should be ok using that file I gave you. Look through those options and tweak them that suits you.

[Adam Hamilton]

@vincent_grenet I don't quite understand the rationale of providing yet another formatting tool. When you say "This would improve user experience without reformatting everything" Can you give an example or an indication of when your proposed formatting tool would format some code but not others.

People are very particular about formatting; they want to see code laid out in a particular way so that it is easier for them to understand the code.

I suppose I can see the logic where there is a mix of template code and user code, for example the main.c file where regenerating code would completely undo the formatting outside of the user code tags, or conversely, format the templated code in the user's style. I see a couple of options for you

1. Rewrite the clangd tool (formatting part of it) so that formatting only occurs within the user code tags. For non-templated files, the formatting tool should reformat the entire file (or a selection of code)
2. When generating templated code, reformat it based on the user's .clang-format file before writing the template code to disk

Option 1 would be the safest, but perhaps the most difficult as you would need to rewrite part of the clangd formatting engine to only format code within user tags. If the source file doesn't contain any user code tags, you could assume the file is a user source file and format as per normal.

If using option 2, you could run into issues if the formatter decides to mess up the user code tags and then people would lose all of their code. This could be somewhat mitigated because you can modify the clangd source to completely ignore the user code tag comments so that CubeMX will be able to correctly keep the user code blocks.

To be honest, don't create a separate formatting tool, use what is already available and because you already fork clangd, the user's clang-format style will be applied to their code.

[vincent_grenet]

@Adam Hamilton 

I'm not planning to provide another new formatting tool; we prefer using Clang utilities.

Instead, I'm proposing we offer our internal .clang-format rule set as a default configuration proposal. This wouldn't be mandatory—users are free to adopt it or not.

Why offer a default?
It helps end-users who may struggle with or lack the time for proper initial setup. As this post demonstrates, setting up formatting rules isn't always obvious (your helpfulness here is evidence of that).

By promoting the exact rules we apply to our drivers, middleware, and application reference code, we can proactively prevent unnecessary re-formatting that can occur due to unmastered local setups.
As an extra measure to encourage rule sharing, I'm considering providing utilities to allow users to run a mass format across all project sources. While file-based formatting is simple, a utility for iterating efficiently over all source files is not always readily available.

Note: @CSharpino these are just initial thoughts and, in any case, this initiative has a very low priority.