You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by Lars Francke <la...@gmail.com> on 2020/01/21 10:18:34 UTC

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

Re: Code conventions

Posted by Lars Francke <la...@gmail.com>.
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 <
pradeepagrawal8184@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 <la...@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

Posted by PradeeP AgrawaL <pr...@gmail.com>.
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 <la...@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
>