Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Adding .clang-format ?? #433

@lczyk

Description

@lczyk

The project formatting seems a little bit inconsistent between files. I wonder is it worth adding .clang-format to attempt to unify the formatting? After playing around with one for a bit I've arrived at:

---
BasedOnStyle: GNU
IndentWidth: 2
SortIncludes: false
AlignAfterOpenBracket: Align
AllowAllParametersOfDeclarationOnNextLine: false
BreakBeforeBraces: Attach
PointerAlignment: Middle
ColumnLimit: 0
IndentPPDirectives: AfterHash
Cpp11BracedListStyle: true
SpaceBeforeParens: Custom

AlignConsecutiveMacros: Consecutive
AlignOperands: AlignAfterOperator

SpaceBeforeParensOptions:
  AfterControlStatements: false
  AfterFunctionDeclarationName: false
  AfterFunctionDefinitionName: false
  BeforeNonEmptyParentheses: false

StatementMacros: ["TEST_ENTRY", "ASSERT"]

EDIT: Retrospectively added StatementMacros above.

which, seems to cause minimal stress to the codebase. After running clang-format -style=file ./src/**/*.c ./include/**/*.h -i (clang-format version is 19.1.4 from homebrew), i get a pretty minor diff in 140 files. The c files are basically untouched, except for a couple of spaces for param alignment, for example:

diff --git a/src/euler.c b/src/euler.c
index 8749ba5..b093b3d 100644
--- a/src/euler.c
+++ b/src/euler.c
@@ -25 +25 @@ void
-glmc_euler_xyz(vec3 angles,  mat4 dest) {
+glmc_euler_xyz(vec3 angles, mat4 dest) {

The h files are also mostly ok, but a couple of places suffer a tiny bit from clang-format limitations, for example:

@@ -103,3 +103,3 @@ glm_ortho_aabb_p_rh_zo(vec3 box[2], float padding, mat4 dest) {
-  glm_ortho_rh_zo(box[0][0] - padding,    box[1][0] + padding,
-                  box[0][1] - padding,    box[1][1] + padding,
-                -(box[1][2] + padding), -(box[0][2] - padding),
+  glm_ortho_rh_zo(box[0][0] - padding, box[1][0] + padding,
+                  box[0][1] - padding, box[1][1] + padding,
+                  -(box[1][2] + padding), -(box[0][2] - padding),

where it does not understand the alignment of the box.

Also, i've skipped formatting of the tests, for now, since clang-format is a tiny bit confused about the ASSERT macro and, in some cases it messes up the indentation, for example:

diff --git a/test/src/test_mat2.h b/test/src/test_mat2.h
index 6fa622a..a872b56 100644
--- a/test/src/test_mat2.h
+++ b/test/src/test_mat2.h
@@ -38,5 +38,5 @@ TEST_IMPL(MACRO_GLM_MAT2_ZERO_INIT) {
-TEST_IMPL(MACRO_GLM_MAT2_IDENTITY) {
-  ASSERT(test_eq(GLM_MAT2_IDENTITY[0][0], 1.0f))
-  ASSERT(test_eq(GLM_MAT2_IDENTITY[0][1], 0.0f))
-  ASSERT(test_eq(GLM_MAT2_IDENTITY[1][0], 0.0f))
-  ASSERT(test_eq(GLM_MAT2_IDENTITY[1][1], 1.0f))
+TEST_IMPL(MACRO_GLM_MAT2_IDENTITY){
+    ASSERT(test_eq(GLM_MAT2_IDENTITY[0][0], 1.0f))
+        ASSERT(test_eq(GLM_MAT2_IDENTITY[0][1], 0.0f))
+            ASSERT(test_eq(GLM_MAT2_IDENTITY[1][0], 0.0f))
+                ASSERT(test_eq(GLM_MAT2_IDENTITY[1][1], 1.0f))

These work ok though, after adding ; after ASSERT (which is protected by do {...} while (0), so it does not change the functionality.

Edit: Resolved with StatementMacros.


Overall, if we were to add .clang-format, I'd suggest doing it in two commits, 1) adding .clang-format and making any small changes to the codebase in preparation for 2) actually running the formatter. This way the commit with the formatter can be easily skipped in any potential git blame searches or anything of this sort. By the small changes in step 1 i mean things like the ; after assets and any /* clang-format on/off */ blocks we might want to add to preserve the indentation in places like glm_ortho_aabb_p_rh_zo above.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions