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 <[email protected]> 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 < [email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > > >
