Repository navigation
Replies: 3 comments 3 replies
|
cc. @stianst @pedroigor @DGuhr |
|
I like the idea of gradually introducing the change and we should be able to quickly enable on Dist.X. This problem is more impactful now we have more people working on it. For me, the easiest path would be to resurrect/review/improve #7607 if we don't want to discuss tools now. |
|
+1000 from my side :) |
|
Hi @andreaTP - I support a code style that is enforced by GitHub actions. I was wondering if the big reformat could be avoided by putting only the biggest no-nos into Checkstyle rules (for example to avoid star imports or unused imports). I usually prefer to put the line breaks where I want them instead of relying on a automatic code format :-) Would just some Checkstyle help with adoption, or would it rather make it more slowly and painful for the migration? |
|
An alternative approach we are taking here is to enforce the style only on the files that are actually getting changed. On the other hand more "recent" projects like Quarkus or the JOSDK are binding the formatting on the Maybe @stianst would like to weight into this conversation. |
|
Hello, https://github.com/Cosium/git-code-format-maven-plugin has this purpose. |
Uh oh!
There was an error while loading. Please reload this page.
Is a fact that the current codebase does contain a mix of various styles.
There is no style formatting suggested in the contributing guidelines and there is no automation in this direction.
I do believe that having a consistent style across the codebase can increase the readability and improve the collaboration.
There are a few low-hanging fruits that can be easily implemented in this direction:
I don't have any strong preference on the code style to be adopted, as long as it's one 🙂 .
A possible path-forward, after having identified a style, is to apply it to the project, this can be a pretty difficult operation since it will invalidate and need a rebase of all the open PRs.
Hence I suggest a gradual migration:
All reactions