Modifiers should be declared in the correct order use `private/public static` not `static private/public` for methods

[stbischof]

Where: https://github.com/congo-cc/congo-parser-generator/search?p=1&q=%22static+private%22

Why: https://rules.sonarsource.com/java/RSPEC-1124

[revusky]

Well, look, I've thought about this "problem" and I have come to the conclusion that the "solution" to this is to turn off the warning.

Because... well... quite frankly, this is just bullshit. You can write private static or static private and it's just the same thing. There is no practical reason that I can see to prefer one over the other -- and certainly no reason to think that one of the two is more "correct" than the other.

So, surely, you can just turn this off, right?

[stbischof]

It works but its Not complient with the java spec.

I pushed the code to Sonarcloud so see where is could be improved.

Is this more then just to switch the words in the Templates?

[revusky]

It works but its Not complient with the java spec.

Well, that's not really true. The java spec says that you can write the modifiers in any order, it doesn't matter. (And that actually includes annotations, by the way.) What this is is just a stylistic recommendation, comparable to indenting your code 4 spaces or something like that. The compiler certainly doesn't care what order the modifiers are in, any more than it cares about how the code is formatted. The only issue is human readability.

I was trying to make make sense of this, because it seems like such self-evident nonsense that it is better to write "private static" than to write "static private", possibly akin to the war in Gulliver's Travels over whether to break open a boiled egg on the big end or the little end. (That is actually where the big-endian vs little-endian data encoding gets that from. It's a literary reference.)

But look, as best I can figure, it could be of some value to be consistent about the order of the modifiers, but only if you have a certain number, beyond some threshold. Like if you regularly had 6 or more modifiers, say 3 keyword modifiers and 3 annotations. Then there could be some (though not a lot!) of value in always writing them in a consistent order, but when all you have is 2 modifiers, so it boils down to writing "private static" instead of "static private", the case to be made for one being clearer than the other just doesn't seem to be there.

Is this more then just to switch the words in the Templates?

No. It's nothing more than that!

But look, I don't really mind you bringing up things like this, but something of this nature, these warnings about which order to write modifiers in or whether to delare two variables on the same line or separate lines, and stuff like this... well, the fact remains that there is no real genuine value to be got from these things.

So, look, would you be interested in sinking your teeth into something that I really need to get done? Here is something. Consider this class is used here. You might notice that, in that FilesGenerator class, there is no similar code for pretty-printing CSharp. And, in fact, there is no analogous CSharpFormatter class. (Not for Python either, but Python is a bit of a different case.)

Well, the reason for that basically is that, throughout the JavaCC21 period, we only had internally the AST for Java. But now we actually are generating the AST classes for Python and Java internally. And we have both CSharp and Python grammars internally. So, in principle, we should be dealing with the output in a similar way to the Java output. The Java output goes through a Reaper (dead code eliminator) and a pretty-printing pass.

Do you think you are up to writing a CSharpFormatter.java analogous to JavaFormatter? Basically, it's just the same tree-walking, but you need to use the AST generated in org.congocc.parser.ast. Oh, and by the way, the other useful thing would be to have a Reaper class but for CSharp. The reaper is being invoked here but again, we only have that for Java, not for CSharp or Python.

What do you think?