Limit number of columns to 160

[asuessenbach]

Description

Every now and then, I'm surprised about the length of some code lines. I would suggest to limit that to, say, 160.
The only manual change in this PR is in .clang-format, setting ColumnLimit : 160. Then all *.cpp and *.h files are formatted accordingly.

In addition to the column limit I changed the following option:
BinPackParameters: false

Build tested on Win11 with VS2022. Run tested on Win11 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

• I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• I have tested the sample on at least one compliant Vulkan implementation
• If the sample is vendor-specific, I have tagged it appropriately
• I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• Any dependent assets have been merged and published in downstream modules
• For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
• For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
• For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

[gpx1000]

It looks like we're gonna need to fix all the instances where the columns are long or limit it from CI being the cause of failing. But I'm all for the idea!

[asuessenbach]

... and it seems, I'm using a different clang-format version (21.1.0) than the CI. Is version to use specified, somewhere?

[SaschaWillems]

clang-format version is listed here. Not sure if that's up-to-date though.

[SaschaWillems]

Looking at the numerous changes: Increasing the column limit might make sense, but some of the changes make code harder to read. Not sure if this is something we want to apply across the board to all samples.

[asuessenbach]

Increasing the column limit might make sense

You mean, even more than 160 columns?

some of the changes make code harder to read.

Could you point me at some of those places? Maybe with some additional clang-format settings, it looks better, again.

Not sure if this is something we want to apply across the board to all samples.

I think, it should either be done for the complete repository, or not at all.

[asuessenbach]

clang-format version is listed here. Not sure if that's up-to-date though.clang-format version is listed here. Not sure if that's up-to-date though.

It's up-to-date. In check.yml, you'll find
container: ghcr.io/khronosgroupactions/clang-tools:15.0.0

[asuessenbach]

Well, in fact it's clang-format 15.0.6, that is used. And for some unknown reasons, it required a few manual adjustments.
But at least, the CI accepts the formatting now.

But I definitely won't crank up the copyright of all those formatted files.

[SaschaWillems]

I'm not really sure if this improves readability. I actually prefer the way it was written before this change.

[SaschaWillems]

Any way to fix this? There are several spots that have had their wrapping changed in a way that at least IMO hurts code readabilit.

[asuessenbach]

With BinPackParameters: false, that looks better again.

[asuessenbach]

Apparently, neither the copyright.py fixes such Copyright strings, nor the copyright check of the CI catches them?

[asuessenbach]

Well, no matter what clang-format version (15.0.x, 0 <= x <= 7 ), win64, I tried, there are four files that needs some manual adjustments to keep the format check happy.
Could someone extent the check.yml in a way that the actually used clang-format version is displayed? I don't even know where the clang-format.exe lives in that context.