Code convention discussions can get pretty heated/religious in nature, which we should seek to avoid. I'm largely in alignment with Hugo on this: Start with a good base like the Google or Sun/Oracle style guides, and establish consensus on where we feel a desire to differ.
Rather than haggle over certain individual conventions, I propose we choose an existing style guide to base ours on and tweak it as we see fit. I have definite opinions about java code style, but I'll hold off on sharing them for now. Let's pick a starting point first. I believe the google and sun/oracle guides are both good starting points. Let's also try not to drag this out too much. I've seen similar conversations absorb more time and effort than it would take to update the associated codebase. -Taylor > On Apr 25, 2017, at 7:13 PM, Hugo Da Cruz Louro <hlo...@hortonworks.com> > wrote: > > Hi, > > We should just follow the Google Java Style > Guide<https://google.github.io/styleguide/javaguide.html>. There are many > opinions on this subject, but I conjecture that this guide, which is very > similar to the original Sun Java Code > Conventions<http://www.oracle.com/technetwork/java/codeconventions-150003.pdf> > has a lot of research and reasoning behind it. It’s widely adopted, and I > think that we should just follow it. The only exception I would really make > is the column limit. I would change 100 to 120 or 130, but not longer than > that. Very long lines makes the code really hard to read. > > There are already existing check style, IntelliJ, and even Git hooks > enforcing/validating this style, so adopting it would make it easier to > incorporate it in the dev tools. > > Regardless of the variants to the aforementioned style, I do not think that > we should use names starting with underscore _ in any circumstance. Not only > it is not a Java convention, as it does not add anything to the code. The > reason behind using _ was before the widespread uses of IDE’s, to mark class > fields. IDEs do that with smart coloring. > > Thanks, > Hugo > > On Apr 25, 2017, at 3:50 PM, Jungtaek Lim > <kabh...@gmail.com<mailto:kabh...@gmail.com>> wrote: > > I would like to review the style guide of other projects, like HBase, and > so. > > Btw, IMHO, I don't like using underscore as prefix for fields. We're using > Java and the expression "class member variable" is from C++, and also > underscore style came from C++. We need to avoid mixing other languages' > style as well. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > 2017년 4월 26일 (수) 오전 7:10, Kyle Nusbaum > <knusb...@yahoo-inc.com.invalid<mailto:knusb...@yahoo-inc.com.invalid>>님이 > 작성: > > Now that most of our code is in Java, I think it might be time to revisit > the issue of having some official and enforced code style. > I don't have very strong feelings about most of it, but here is what I was > thinking as a start, since I've seen this style quite a bit, and I've found > it makes code pretty easy to read: > 1. Indentation is 4 spaces per level (no tabs) > 2. All class member variables begin with underscore3. No wildcard > imports4. if / else / for / etc. always get curly braces. > There are obviously tons of other things, and we can get as picky as we > want, but I think enforcing at least these rules would go a long way to > making the code more consistent. > > Thoughts? > > Thanks, > -- Kyle >
