You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by Kyle Nusbaum <kn...@yahoo-inc.com.INVALID> on 2017/04/25 22:10:23 UTC
[DISCUSS] Code Style
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
Re: [DISCUSS] Code Style
Posted by Kyle Nusbaum <kn...@yahoo-inc.com.INVALID>.
+1 for what Hugo, Taylor and Bobby said.
Thanks,
-- Kyle
On Wednesday, April 26, 2017, 9:45:08 AM CDT, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:I really don't care what style we use so long as we have one and it is enforced. Checkstyle is highly configurable so just about any style we pick we can enforce with it. Most Java IDEs that I know of either use the checkstyle format itself or at least support a checkstyle plugin to let you know if you are off.
I have my own opinions about this but to avoid too much further discussion (aka religious war) I would propose that we have a simple vote on what standard people what. So far I have heard
Google Java Style Guide<https://google.github.io/styleguide/javaguide.html>Sun Java Code Conventions<http://www.oracle.com/technetwork/java/codeconventions-150003.pdf> HBase style<https://github.com/apache/hbase/blob/master/dev-support/hbase_eclipse_formatter.xml> (sorry all I could find was an eclipse XML config)Hadoop style<https://wiki.apache.org/hadoop/CodeReviewChecklist> which is described as java but with 2 spaces instead of 4.
If no one has any objections I will send out a new thread to vote on this. I will probably also include a write in option too.
- Bobby
On Wednesday, April 26, 2017, 2:23:46 AM CDT, Satish Duggana <sa...@gmail.com> wrote:+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 <pt...@gmail.com> 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 <hl...@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 <kabhwan@gmail.com<mailto:kabh
> wan@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 <knusbaum@yahoo-inc.com.
> invalid<ma...@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
> >
>
Re: [DISCUSS] Code Style
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
I really don't care what style we use so long as we have one and it is enforced. Checkstyle is highly configurable so just about any style we pick we can enforce with it. Most Java IDEs that I know of either use the checkstyle format itself or at least support a checkstyle plugin to let you know if you are off.
I have my own opinions about this but to avoid too much further discussion (aka religious war) I would propose that we have a simple vote on what standard people what. So far I have heard
Google Java Style Guide<https://google.github.io/styleguide/javaguide.html>Sun Java Code Conventions<http://www.oracle.com/technetwork/java/codeconventions-150003.pdf> HBase style<https://github.com/apache/hbase/blob/master/dev-support/hbase_eclipse_formatter.xml> (sorry all I could find was an eclipse XML config)Hadoop style<https://wiki.apache.org/hadoop/CodeReviewChecklist> which is described as java but with 2 spaces instead of 4.
If no one has any objections I will send out a new thread to vote on this. I will probably also include a write in option too.
- Bobby
On Wednesday, April 26, 2017, 2:23:46 AM CDT, Satish Duggana <sa...@gmail.com> wrote:+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 <pt...@gmail.com> 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 <hl...@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 <kabhwan@gmail.com<mailto:kabh
> wan@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 <knusbaum@yahoo-inc.com.
> invalid<ma...@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
> >
>
Re: [DISCUSS] Code Style
Posted by Satish Duggana <sa...@gmail.com>.
+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 <pt...@gmail.com> 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 <hl...@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 <kabhwan@gmail.com<mailto:kabh
> wan@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 <knusbaum@yahoo-inc.com.
> invalid<ma...@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
> >
>
Re: [DISCUSS] Code Style
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <hl...@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 <ka...@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 <kn...@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
>
Re: [DISCUSS] Code Style
Posted by Hugo Da Cruz Louro <hl...@hortonworks.com>.
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 <ka...@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 <kn...@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
Re: [DISCUSS] Code Style
Posted by Roshan Naik <ro...@hortonworks.com>.
- Personally not a big fan of _ for members either from the readability standpoint. Also much of the existing code doesn’t follow this.
- Personally I find it is easier to write/read one-liner if/else without the curlys. Always wondered about the rationale behind that.
Would suggest any such a coding convention be very minimalist as a conding convention’s usefulness is inversely proportional to its length (
-roshan
Would be good to keep any such coding convention as minimalistic and
On 4/25/17, 3:50 PM, "Jungtaek Lim" <ka...@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 <kn...@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
Re: [DISCUSS] Code Style
Posted by Jungtaek Lim <ka...@gmail.com>.
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 <kn...@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