Re: Checkstyle as style contract for Cassandra

I agree with you for all these two points. I think you should open a ticket to solve this if you want to add a rule to checkstyle, as I know there are many old codes that do not comply with this rule. For point 2, this really feels like personal preference, but I'd probably listen to the reviewer'

Re: Checkstyle as style contract for Cassandra

Reading back https://issues.apache.org/jira/browse/CASSANDRA-19276 a bit more, I think I *was* able to make checkstyle bend to the "Code Style" definition by ignoring lambda tokens. It's just that there were a lot of "violations" which defined a method on one line: public int getActiveTaskCount(

Re: Checkstyle as style contract for Cassandra

Hi Bernardo, Thanks for bringing this up! Last year I was looking into enforcing curly braces as defined in Code Style and had some thoughts on how to make this work but hit a bit of a brick wall: https://issues.apache.org/jira/browse/

Re: Checkstyle as style contract for Cassandra

Even something as simple as the curly brace rule has sensible exceptions. I’m pretty hard -1 on letting a linter make all our editing decisions. Formatting is a contextual choice about how to best represent information to the reader, and we should not abdicate responsibility. The style guide is

Re: Checkstyle as style contract for Cassandra

I agree with you on the second one that it seems more like a preference. The first one is indeed a rule and I appreciate it that you want to add a rule and fix any places where we already fail it. I think the more we automate such kind of things the better. Thanks again for bringing it in. Best

Checkstyle as style contract for Cassandra

Hi everyone! I wanted to raise a question about code style for the project. I've been receiving some feedback on PRs about the need to: - Have curly braces start on a new line - Remove curly braces if the condition or loop has only one expression Taking a look at the official Code Style stated i