I don't feel strongly about the specific proposal that started this thread. I could see why someone might find it easier to skim the code; I don't feel it impacts my reading personally. If there are folks with differing opinions over it; my preference would be that we stick with whatever style is already more prevalent in the codebase.
I do feel strongly that we need _some_ consistently enforced standards. I also think we've been paying a sort of tax as a community for a long time because our existing code base does not currently follow our stated standards, so it's confusing. Our section on code conventions[1] doesn't really give any background beyond "common feedback" as to how we came to our current formatting rules, but it does tell folks that the relevant starting point is the sun java conventions[2]. IIRC our current style guidelines grew out of our time in the Apache Hadoop project which also follows the sun java conventions except with 2 spaces per indent level instead of 4[3]. It's been modified a bit over time as things didn't work for us. the biggest difference that comes to mind is our longer max line length. and maybe the import ordering? I don't think we should adopt some alternate coding standard all at once without a good summary of how it compares to our current formatting standards. I would be in favor of paying the one-time cost of bringing our active release lines into compliance with our stated code format standards. This could be done, for example, by module to break up the reviewing. [1]: https://hbase.apache.org/book.html#common.patch.feedback [2]: https://www.oracle.com/java/technologies/javase/codeconventions-contents.html [3]: https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute#HowToContribute-MakingChanges On Sat, Jan 15, 2022 at 3:07 AM 张铎(Duo Zhang) <[email protected]> wrote: > What about just switching to use google java style? > > Nick Dimiduk <[email protected]> 于2022年1月13日周四 03:22写道： > > > Hey all. > > > > Discussion on the PR has resulted in an impasse of opinion, but also > > renewed interest in improvements to static analysis in general > > (HBASE-26617). > > > > I think that this kind of code hygiene is very important for the > long-term > > maintenance of a large project like ours and especially one that accepts > > contributions from a broad audience. I would really appreciate it if some > > more folks would chime into these discussions on PRs, or bring your > > concerns back up to this thread. I'm game to help see the work done, but > we > > need more voices to participate in defining what is required by the > > community. > > > > Thanks in advance, > > Nick > > > > On Thu, Dec 9, 2021 at 3:58 PM Nick Dimiduk <[email protected]> wrote: > > > > > Heya, > > > > > > I have posted a small change to our checkstyle configuration on > > > HBASE-26536. This change will relax the whitespace rules regarding the > > > left-curly-bracket ('{') character. Specifically, I intend this change > to > > > allow short expressions that include a nested scope that fits entirely > on > > > one line. The example I provide is: > > > > > > if (foo == null) { return null; } > > > > > > This whitespace style is already present (though I think not in popular > > > usage) within the codebase. Please take a look and let me know if you > > have > > > any concerns about making this change. > > > > > > Thanks, > > > Nick > > > > > > https://issues.apache.org/jira/browse/HBASE-26536 > > > https://github.com/apache/hbase/pull/3913 > > > > > >
