This is an alternative, or maybe a temporary replacement, to D2455.
Diff Detail
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Branch
- /ps/trunk
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 12848 Build 25152: Vulcan Build Jenkins Build 25151: Vulcan Build (macOS) Jenkins Build 25150: Vulcan Build (Windows) Jenkins Build 25146: arc lint + arc unit
Event Timeline
Comment Actions
Successful build - Chance fights ever on the side of the prudent.
Link to build: https://jenkins.wildfiregames.com/job/vs2015-differential/814/display/redirect
Comment Actions
Successful build - Chance fights ever on the side of the prudent.
Linter detected issues: Executing section Source... Executing section JS... Executing section cli...
Link to build: https://jenkins.wildfiregames.com/job/docker-differential/1330/display/redirect
Comment Actions
Proposal to use Artistic Style instead of clang-format.
clang-format is better (it has more options and it can enforce a few things astyle doesn't. However, clang-format doesn't allow us to ignore spaces around binary operators.
astyle is less strict, so I believe we should start using astyle to have some linting that is not too intrusive. If we manage to work around the clang-format limitation, we can switch then, and enforce more style conventions.
Note: I rewrote an astyle coala bear because coala-bears has one but it's badly written, it only works with options in the .coafile.
After getting your thoughts I will add the .coafile change here.
Comment Actions
I think @vladislavbelov might have better input.
For my part if it does the trick why not. Why do we need spaces around binary operators?
Also I'm wondering about the weird convention we have for switch cases? Does any of them support it ?
Comment Actions
I think so too. As Vlad told me yesterday, the style linter will not manage to detect enforce everything in our coding conventions (for instance proper naming of variables).
For my part if it does the trick why not. Why do we need spaces around binary operators?
You misunderstood. Sometimes we need to NOT have spaces. For instance, for calculating a 2D distance, x*x + y*y is more readable than x * x + y * y (the relevant binary operator is * in this case). However, clang-format forces the use of spaces, and there is no option to change that, as of today. The detection of missing spaces is optional in astyle.
This is debatable: some people would prefer the linter to force x * x + y * y. The advantage of forcing this is that it also forces stuff like int a = 5; instead of the incorrect int a=5;.
Also I'm wondering about the weird convention we have for switch cases? Does any of them support it ?
- In Astyle, there is an option to go against our convention and force an indent. I did not set the option, so Astyle doesn't force anything. It will accept both our convention and the indented version (just like it will accept both spaces and no spaces around operators)
- In clang-format, it is possible to force our convention (it is the default, so I'd say it's not a weird convention)
This is a good example of the difference between Astyle and clang-format:
- Astyle is permissive by default, but lacks options. It will not bother us if we disagree with a specific change. On the other hand, it cannot always help us to enforce our conventions.
- clang-format is much more enforcing, and has many options where we can force things one way or another. Unfortunately, when an option is missing, we have no choice other than following their defaults.
Hence I would prefer using clang-format, but the binary operators issue is a deal-breaker for me. I think Astyle is a good start while I look for a way to allow unpadded operators in clang-format.