Re: Code conventions
Lars,
Can you review https://reviews.apache.org/r/72057/ and add your inputs.
Regards,
Pradeep
On Wed, 22 Jan 2020 at 18:07, Velmurugan Periasamy wrote:
> Hi:
>
> It is a good idea. I have added suggested guidelines to wiki.
> https://cwiki.apache.org/confluence/display/RANGER/Coding+guidelines <
> https://cwiki.apache.org/confluence/display/RANGER/Coding+guidelines>
>
> Thanks for your interest in contributing.
> Vel
>
>
>
> On Wed, Jan 22, 2020 at 2:13 AM Lars Francke
> wrote:
> Hi Pradeep,
>
> thank you for getting back to me and pointing me at your issue.
> As a newcomer to a project, I agree that it'd be a tremendous help if
> things were a bit more consistent.
>
> Cheers,
> Lars
>
> On Wed, Jan 22, 2020 at 6:15 AM PradeeP AgrawaL <
> pradeepagrawal8...@gmail.com <mailto:pradeepagrawal8...@gmail.com>> wrote:
>
> > Hi Lars,
> >
> > There is no specific code conventions and checkstyle being followed
> > currently, but important reviews are given during patch review process. I
> > created one JIRA RANGER-2588 to implement checkstyle. I might need
> > suggestion on that from community.
> > This might force me to make changes in all the files if I would do so
> then
> > it might affect other developers as well.
> >
> > Below are few guidelines which I received earlier from a community
> member.
> > I accept that I also don't follow all of them always.
> >
> >
> >1. Indentation: suggest to use 4 spaces; 2 spaces works as well – but
> be
> >consistent! No tabs please!
> >2. Spaces:
> > 1. a single space before “(“, “{“
> > 2. a single space after “)”
> > 3. a single space around operators
> > 4. Example: “if (a == b && x != y) {“; avoid “if(a==b&&x!=y){“
> >3. Blocks: “{“, at the end of the line that starts the block, end the
> >block with “}” in a separate line
> >4. Statements: earlier restrictions on line length (of 80/132) were
> >likely for printing of the code on paper. Most of us shouldn’t be
> > printing
> >source code on paper now. So, a statement need not be broken into
> > multiple
> >lines – even if it is few hundred characters long.
> >5. Class member declaration in the following order:
> >
> >
> >1. static members: public, protected, private; within each accessor,
> > ‘final’ members precede non-final
> > 2. instance members: public, protected, private; within each
> > accessor, ‘final’ members precede non-final
> > 3. Vertically align start of: typeName, variableName, assignment
> > operator
> > 4. methods: public, protected, private; within each accessor,
> static
> > methods precede non-static
> > 5. methods: all constructors immediately after ‘public static’
> > methods
> > 6. methods: all getters/setters immediately after constructors
> > 7. methods: all @Override methods immediately after getter/setters
> > 8. methods: use a consistent name for variable holding the return
> > value. Suggested name ‘ret’
> > 9. methods: use a single return for each method (as much as
> possible)
> > 10. methods: avoid methods with large number of lines; suggested
> > length 24 (from good old days!)
> > 11. Blank line before and after each ‘for/while/do/if-else’ block
> > 12. Blank line after each variable declaration block
> > 13. Separate assignment lines from the rest
> >
> >
> > On Tue, 21 Jan 2020 at 15:49, Lars Francke <mailto:lars.fran...@gmail.com>> wrote:
> >
> > > Hi Ranger devs,
> > >
> > > I've stumbled through the Ranger code base in the last few days and
> might
> > > have a few things to contribute but I'm wondering if you have any kind
> of
> > > code conventions?
> > >
> > > I'm asking because there's tabs being used as well as spaces and that's
> > > just one of the things that struck me. It seems to be "all over the
> > place"
> > > which doesn't make it easier to get started. I see some references to
> > > checkstyle but no config for it.
> > >
> > > So, two questions:
> > > 1) Do you have any code conventions?
> > >
> > > 2) Would you accept whitespace/style only patches to "clean" it up a
> bit?
> > > At least to be consistent within a single file.
> > >
> > > Cheers,
> > > Lars
> > >
> >
Re: Code conventions
Hi:
It is a good idea. I have added suggested guidelines to wiki.
https://cwiki.apache.org/confluence/display/RANGER/Coding+guidelines
<https://cwiki.apache.org/confluence/display/RANGER/Coding+guidelines>
Thanks for your interest in contributing.
Vel
On Wed, Jan 22, 2020 at 2:13 AM Lars Francke wrote:
Hi Pradeep,
thank you for getting back to me and pointing me at your issue.
As a newcomer to a project, I agree that it'd be a tremendous help if
things were a bit more consistent.
Cheers,
Lars
On Wed, Jan 22, 2020 at 6:15 AM PradeeP AgrawaL <
pradeepagrawal8...@gmail.com <mailto:pradeepagrawal8...@gmail.com>> wrote:
> Hi Lars,
>
> There is no specific code conventions and checkstyle being followed
> currently, but important reviews are given during patch review process. I
> created one JIRA RANGER-2588 to implement checkstyle. I might need
> suggestion on that from community.
> This might force me to make changes in all the files if I would do so then
> it might affect other developers as well.
>
> Below are few guidelines which I received earlier from a community member.
> I accept that I also don't follow all of them always.
>
>
>1. Indentation: suggest to use 4 spaces; 2 spaces works as well – but be
>consistent! No tabs please!
>2. Spaces:
> 1. a single space before “(“, “{“
> 2. a single space after “)”
> 3. a single space around operators
> 4. Example: “if (a == b && x != y) {“; avoid “if(a==b&&x!=y){“
>3. Blocks: “{“, at the end of the line that starts the block, end the
>block with “}” in a separate line
>4. Statements: earlier restrictions on line length (of 80/132) were
>likely for printing of the code on paper. Most of us shouldn’t be
> printing
>source code on paper now. So, a statement need not be broken into
> multiple
>lines – even if it is few hundred characters long.
>5. Class member declaration in the following order:
>
>
>1. static members: public, protected, private; within each accessor,
> ‘final’ members precede non-final
> 2. instance members: public, protected, private; within each
> accessor, ‘final’ members precede non-final
> 3. Vertically align start of: typeName, variableName, assignment
> operator
> 4. methods: public, protected, private; within each accessor, static
> methods precede non-static
> 5. methods: all constructors immediately after ‘public static’
> methods
> 6. methods: all getters/setters immediately after constructors
> 7. methods: all @Override methods immediately after getter/setters
> 8. methods: use a consistent name for variable holding the return
> value. Suggested name ‘ret’
> 9. methods: use a single return for each method (as much as possible)
> 10. methods: avoid methods with large number of lines; suggested
> length 24 (from good old days!)
> 11. Blank line before and after each ‘for/while/do/if-else’ block
> 12. Blank line after each variable declaration block
> 13. Separate assignment lines from the rest
>
>
> On Tue, 21 Jan 2020 at 15:49, Lars Francke <mailto:lars.fran...@gmail.com>> wrote:
>
> > Hi Ranger devs,
> >
> > I've stumbled through the Ranger code base in the last few days and might
> > have a few things to contribute but I'm wondering if you have any kind of
> > code conventions?
> >
> > I'm asking because there's tabs being used as well as spaces and that's
> > just one of the things that struck me. It seems to be "all over the
> place"
> > which doesn't make it easier to get started. I see some references to
> > checkstyle but no config for it.
> >
> > So, two questions:
> > 1) Do you have any code conventions?
> >
> > 2) Would you accept whitespace/style only patches to "clean" it up a bit?
> > At least to be consistent within a single file.
> >
> > Cheers,
> > Lars
> >
>
Re: Code conventions
Hi Pradeep,
thank you for getting back to me and pointing me at your issue.
As a newcomer to a project, I agree that it'd be a tremendous help if
things were a bit more consistent.
Cheers,
Lars
On Wed, Jan 22, 2020 at 6:15 AM PradeeP AgrawaL <
pradeepagrawal8...@gmail.com> wrote:
> Hi Lars,
>
> There is no specific code conventions and checkstyle being followed
> currently, but important reviews are given during patch review process. I
> created one JIRA RANGER-2588 to implement checkstyle. I might need
> suggestion on that from community.
> This might force me to make changes in all the files if I would do so then
> it might affect other developers as well.
>
> Below are few guidelines which I received earlier from a community member.
> I accept that I also don't follow all of them always.
>
>
>1. Indentation: suggest to use 4 spaces; 2 spaces works as well – but be
>consistent! No tabs please!
>2. Spaces:
> 1. a single space before “(“, “{“
> 2. a single space after “)”
> 3. a single space around operators
> 4. Example: “if (a == b && x != y) {“; avoid “if(a==b&&x!=y){“
>3. Blocks: “{“, at the end of the line that starts the block, end the
>block with “}” in a separate line
>4. Statements: earlier restrictions on line length (of 80/132) were
>likely for printing of the code on paper. Most of us shouldn’t be
> printing
>source code on paper now. So, a statement need not be broken into
> multiple
>lines – even if it is few hundred characters long.
>5. Class member declaration in the following order:
>
>
>1. static members: public, protected, private; within each accessor,
> ‘final’ members precede non-final
> 2. instance members: public, protected, private; within each
> accessor, ‘final’ members precede non-final
> 3. Vertically align start of: typeName, variableName, assignment
> operator
> 4. methods: public, protected, private; within each accessor, static
> methods precede non-static
> 5. methods: all constructors immediately after ‘public static’
> methods
> 6. methods: all getters/setters immediately after constructors
> 7. methods: all @Override methods immediately after getter/setters
> 8. methods: use a consistent name for variable holding the return
> value. Suggested name ‘ret’
> 9. methods: use a single return for each method (as much as possible)
> 10. methods: avoid methods with large number of lines; suggested
> length 24 (from good old days!)
> 11. Blank line before and after each ‘for/while/do/if-else’ block
> 12. Blank line after each variable declaration block
> 13. Separate assignment lines from the rest
>
>
> On Tue, 21 Jan 2020 at 15:49, Lars Francke wrote:
>
> > Hi Ranger devs,
> >
> > I've stumbled through the Ranger code base in the last few days and might
> > have a few things to contribute but I'm wondering if you have any kind of
> > code conventions?
> >
> > I'm asking because there's tabs being used as well as spaces and that's
> > just one of the things that struck me. It seems to be "all over the
> place"
> > which doesn't make it easier to get started. I see some references to
> > checkstyle but no config for it.
> >
> > So, two questions:
> > 1) Do you have any code conventions?
> >
> > 2) Would you accept whitespace/style only patches to "clean" it up a bit?
> > At least to be consistent within a single file.
> >
> > Cheers,
> > Lars
> >
>
Re: Code conventions
Hi Lars,
There is no specific code conventions and checkstyle being followed
currently, but important reviews are given during patch review process. I
created one JIRA RANGER-2588 to implement checkstyle. I might need
suggestion on that from community.
This might force me to make changes in all the files if I would do so then
it might affect other developers as well.
Below are few guidelines which I received earlier from a community member.
I accept that I also don't follow all of them always.
1. Indentation: suggest to use 4 spaces; 2 spaces works as well – but be
consistent! No tabs please!
2. Spaces:
1. a single space before “(“, “{“
2. a single space after “)”
3. a single space around operators
4. Example: “if (a == b && x != y) {“; avoid “if(a==b&&x!=y){“
3. Blocks: “{“, at the end of the line that starts the block, end the
block with “}” in a separate line
4. Statements: earlier restrictions on line length (of 80/132) were
likely for printing of the code on paper. Most of us shouldn’t be printing
source code on paper now. So, a statement need not be broken into multiple
lines – even if it is few hundred characters long.
5. Class member declaration in the following order:
1. static members: public, protected, private; within each accessor,
‘final’ members precede non-final
2. instance members: public, protected, private; within each
accessor, ‘final’ members precede non-final
3. Vertically align start of: typeName, variableName, assignment
operator
4. methods: public, protected, private; within each accessor, static
methods precede non-static
5. methods: all constructors immediately after ‘public static’ methods
6. methods: all getters/setters immediately after constructors
7. methods: all @Override methods immediately after getter/setters
8. methods: use a consistent name for variable holding the return
value. Suggested name ‘ret’
9. methods: use a single return for each method (as much as possible)
10. methods: avoid methods with large number of lines; suggested
length 24 (from good old days!)
11. Blank line before and after each ‘for/while/do/if-else’ block
12. Blank line after each variable declaration block
13. Separate assignment lines from the rest
On Tue, 21 Jan 2020 at 15:49, Lars Francke wrote:
> Hi Ranger devs,
>
> I've stumbled through the Ranger code base in the last few days and might
> have a few things to contribute but I'm wondering if you have any kind of
> code conventions?
>
> I'm asking because there's tabs being used as well as spaces and that's
> just one of the things that struck me. It seems to be "all over the place"
> which doesn't make it easier to get started. I see some references to
> checkstyle but no config for it.
>
> So, two questions:
> 1) Do you have any code conventions?
>
> 2) Would you accept whitespace/style only patches to "clean" it up a bit?
> At least to be consistent within a single file.
>
> Cheers,
> Lars
>
Code conventions
Hi Ranger devs, I've stumbled through the Ranger code base in the last few days and might have a few things to contribute but I'm wondering if you have any kind of code conventions? I'm asking because there's tabs being used as well as spaces and that's just one of the things that struck me. It seems to be "all over the place" which doesn't make it easier to get started. I see some references to checkstyle but no config for it. So, two questions: 1) Do you have any code conventions? 2) Would you accept whitespace/style only patches to "clean" it up a bit? At least to be consistent within a single file. Cheers, Lars
