You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hate to be the guy opening an issue about code style in a project with maintainership issues, but it's really bugging me so here goes.
The automated formatting script in this project currently invokes astyle with the -d flag, which inserts space padding around parenthesis on the "outside" only. Presumably this option was specified in this instance to allow for conditional and iteration statements written as if (condition) and while (condition), but it also seems to be generating lines like assert ( (radix > 1) && (radix < 6)); and tw += ( (out_step >> 1) - 1);. Why? I don't know. It seems like the right side of the bracket should count as "outside" too, but apparently it doesn't.
There's another option, -xd, that's like -d but inserts padding only around the first parenthesis in a series. This fixes the previous cases, but still results in oddities such as twiddles[ (radix - 1) * j + k - 1]. Argh! And these are hardly the only examples of astyle formatting issues present within the codebase. All things considered, I'm not of the opinion that astyle is doing a good job of keeping Ne10 formatted well, and that's sort of the only thing that formatting tools are supposed to be for.
Given that it may be doing more harm than good in this sense, is it worth considering the removal of this tool from the project? Code formatting should be properly reviewed as new patches get merged, and some flexibility in how things should look can make the code more rather than less readable. Running cformatter.sh against the current master branch, I'm finding that around 1400 lines aren't currently formatted in the way that astyle wants anyway, so the current formatting rules aren't even being kept. Or, rather than no automated formatting aid, perhaps a better option here would be to have a checkpatch script similar to that of the Linux kernel, which aims to detect and report errors rather than to explicitly manipulate code to enforce strict styling rules.
Thoughts?
The text was updated successfully, but these errors were encountered:
I hate to be the guy opening an issue about code style in a project with maintainership issues, but it's really bugging me so here goes.
The automated formatting script in this project currently invokes
astyle
with the-d
flag, which inserts space padding around parenthesis on the "outside" only. Presumably this option was specified in this instance to allow for conditional and iteration statements written asif (condition)
andwhile (condition)
, but it also seems to be generating lines likeassert ( (radix > 1) && (radix < 6));
andtw += ( (out_step >> 1) - 1);
. Why? I don't know. It seems like the right side of the bracket should count as "outside" too, but apparently it doesn't.There's another option,
-xd
, that's like-d
but inserts padding only around the first parenthesis in a series. This fixes the previous cases, but still results in oddities such astwiddles[ (radix - 1) * j + k - 1]
. Argh! And these are hardly the only examples ofastyle
formatting issues present within the codebase. All things considered, I'm not of the opinion thatastyle
is doing a good job of keeping Ne10 formatted well, and that's sort of the only thing that formatting tools are supposed to be for.Given that it may be doing more harm than good in this sense, is it worth considering the removal of this tool from the project? Code formatting should be properly reviewed as new patches get merged, and some flexibility in how things should look can make the code more rather than less readable. Running
cformatter.sh
against the current master branch, I'm finding that around 1400 lines aren't currently formatted in the way thatastyle
wants anyway, so the current formatting rules aren't even being kept. Or, rather than no automated formatting aid, perhaps a better option here would be to have acheckpatch
script similar to that of the Linux kernel, which aims to detect and report errors rather than to explicitly manipulate code to enforce strict styling rules.Thoughts?
The text was updated successfully, but these errors were encountered: