You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by PradeeP AgrawaL <pr...@gmail.com> on 2020/02/04 05:46:58 UTC

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 <ve...@apache.org> 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 <la...@gmail.com>
> 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 <
> pradeepagrawal8184@gmail.com <ma...@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 <lars.francke@gmail.com
> <ma...@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
> > >
> >