+1 to what Hugo and Taylor said. Lets go with google java style guide for now and modify any of those rules if it is really required.
On Wed, Apr 26, 2017 at 5:23 AM, P. Taylor Goetz <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]<mailto:kabh > [email protected]>> 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 <[email protected]. > invalid<mailto:[email protected]>>님이 > > 작성: > > > > 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 > > >
