Return-Path: X-Original-To: apmail-stratos-dev-archive@minotaur.apache.org Delivered-To: apmail-stratos-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1A05A174F1 for ; Wed, 1 Oct 2014 11:17:35 +0000 (UTC) Received: (qmail 89830 invoked by uid 500); 1 Oct 2014 11:17:34 -0000 Delivered-To: apmail-stratos-dev-archive@stratos.apache.org Received: (qmail 89781 invoked by uid 500); 1 Oct 2014 11:17:34 -0000 Mailing-List: contact dev-help@stratos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stratos.apache.org Delivered-To: mailing list dev@stratos.apache.org Received: (qmail 89771 invoked by uid 99); 1 Oct 2014 11:17:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 11:17:34 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nirmal070125@gmail.com designates 74.125.82.48 as permitted sender) Received: from [74.125.82.48] (HELO mail-wg0-f48.google.com) (74.125.82.48) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 11:17:30 +0000 Received: by mail-wg0-f48.google.com with SMTP id n12so99339wgh.31 for ; Wed, 01 Oct 2014 04:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PUllajiOYu6slGc8eN7+53COKN5LNzR9pLohBDFxtqw=; b=nFRnY8lB0u674cVyqQgKLwKAqwvT1OQx/8q6qAqk++q0YWMKr0L7HJM4u1uYIor+kc TuxgMBcN/T+RgTmTmraoioUwq1Xj6xGXD3r3aPZNLFhjhi/ZniXGIpxh1NhBrEIluKSS ZZK1pknaeAMXazXCkhqQFaphJTIh/es0U/94ykeLc2kRV78BpZjDYqHLfVIOjXzJlwth mb5nlyD7q9H9ZNkfPFIFs4PTTMMDoGAYhrNeT1hFRS9kezkldiAL/XIUC6JlW2jEKyjl PsDbyZycw866uMc+gFF1IQdMCczCkd1zfw+DCFsL2B/sP/UE/vcVAvkrORtl6wBHlI7o h/1w== MIME-Version: 1.0 X-Received: by 10.194.81.101 with SMTP id z5mr61403141wjx.17.1412162228625; Wed, 01 Oct 2014 04:17:08 -0700 (PDT) Received: by 10.194.61.211 with HTTP; Wed, 1 Oct 2014 04:17:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 16:47:08 +0530 Message-ID: Subject: Re: [Discuss] Coding Standards & Best Practices Guidelines From: Nirmal Fernando To: dev , Isuru Perera Content-Type: multipart/alternative; boundary=047d7bea405600a7d105045aa40a X-Virus-Checked: Checked by ClamAV on apache.org --047d7bea405600a7d105045aa40a Content-Type: text/plain; charset=UTF-8 Guys, Did you all manage to create the formatter profiles? On Tue, Sep 23, 2014 at 11:59 AM, Nirmal Fernando wrote: > Thanks for the reminder Imesh. I've created a Jira for this > https://issues.apache.org/jira/browse/STRATOS-813 > > On Tue, Sep 23, 2014 at 10:31 AM, Imesh Gunaratne > wrote: > >> It's nice to see everyone is focusing on $subject. I just went through >> the latest Sonar findings and seems like there are nearly 270 critical >> issues: >> >> >> https://analysis.apache.org/drilldown/issues/org.apache.stratos:stratos-parent?severity=CRITICAL >> >> We can go through the list and fix these issues, on the next build Sonar >> listing will get updated. >> >> On Mon, Sep 22, 2014 at 7:32 AM, Akila Ravihansa Perera < >> ravihansa@wso2.com> wrote: >> >>> On Mon, Sep 22, 2014 at 4:39 PM, Isuru Perera wrote: >>> > Hi everyone, >>> > >>> > I think we should agree on whether we should use tabs or spaces for the >>> > indentation. >>> > >>> > I'm suggesting that we should use 4 spaces for the indentation and >>> > completely avoid tabs in our code. >>> >>> +1 >>> >>> Tabs can mess up the code when working with different developer >>> environments. >>> >>> >>> > >>> > I can help to come up with an Eclipse Formatter profile. We should also >>> > format the entire code base in a single commit after we agree on our >>> coding >>> > standards. >>> >>> Great! I can work on a IntelliJ Idea Formatting profile. >>> >>> > >>> > WDYT? >>> > >>> > Thanks! >>> > >>> > Best Regards, >>> > >>> > >>> > On Tue, Sep 16, 2014 at 11:52 AM, Lakmal Warusawithana < >>> lakmal@wso2.com> >>> > wrote: >>> >> >>> >> Hi, >>> >> >>> >> This is the guideline we used in WSO2, shall we have a look and see >>> >> whether we can use the same. Please share your thoughts. After we >>> finalised >>> >> will put this into wiki and make it as common guide line. >>> >> >>> >> Comments >>> >> >>> >> Doc comments >>> >> >>> >> All classes and all methods/functions MUST have doc comments >>> >> >>> >> Explain each parameter, return type and assumptions made >>> >> >>> >> Line comments >>> >> >>> >> In case you have complex logic, explain any genius logic, rationale >>> for >>> >> doing something >>> >> >>> >> >>> >> Logging >>> >> >>> >> Log then and there >>> >> >>> >> With ample local information and context >>> >> >>> >> Remember logs are for users. Make them meaningful, readable and also >>> make >>> >> sure you spell check (ispell) >>> >> >>> >> Use correct log level, e.g do not log errors as warnings or vice versa >>> >> >>> >> Remember to log the error before throwing an exception >>> >> >>> >> >>> >> Logic >>> >> >>> >> Make your genius code readable >>> >> >>> >> Use meaningful variable names. Remember, compilers can handle long >>> >> variable names >>> >> >>> >> ________________________________ >>> >> >>> >> Variables declared in locality, as an when required >>> >> >>> >> The underscore character should be used only when declaring >>> constants, and >>> >> should not be used anywhere else in Java code >>> >> >>> >> Make sure the function/method names are self descriptive >>> >> >>> >> One should be able explain a function/method using a single sentence >>> >> without conjunctions (that is no and/or in description) >>> >> >>> >> Have proper separation of concerns >>> >> >>> >> Check if you do multiple things in a function >>> >> >>> >> Too many parameters are smelly, indicates that something is wrong >>> >> >>> >> Use variables to capture status and return at the end whenever >>> possible >>> >> >>> >> Avoid status returning from multiple places, that makes code less >>> readable >>> >> >>> >> Be consistent in managing state e.g. Initialize to FALSE and set to >>> TRUE >>> >> everywhere else >>> >> >>> >> Where does that if block end, or what block did you end right now? >>> Have a >>> >> comment at end of a block at } >>> >> >>> >> Use if statements rationally, ensure the behavior is homogeneous >>> >> >>> >> In case of returning a collection, must return an empty collection >>> and not >>> >> null (or NULL) >>> >> >>> >> Do not use interfaces to declare constants. Use a final class with >>> public >>> >> static final attributes and a private constructor. >>> >> >>> >> Always use braces to surround code blocks ({}) even if it is a single >>> >> line. >>> >> >>> >> Break code into multiple lines if it exceeds 100 columns >>> >> >>> >> Align method parameters, exception etc. in order to improve >>> readability. >>> >> Use the settings in your IDE to do this. >>> >> >>> >> Be sure to define, who should catch an exception when throwing one >>> >> >>> >> Be sure to catch those exceptions that you can handle >>> >> >>> >> Do not use string literals in the code, instead declare constants and >>> use >>> >> them, constant names should be self descriptive >>> >> >>> >> Use constants already defined whenever possible, check to see if >>> someone >>> >> already declared one, specially in base libs, like Axis2 >>> >> >>> >> >>> >> Java Specific >>> >> >>> >> Coding conventions - >>> >> http://www.oracle.com/technetwork/java/codeconv-138413.html >>> >> >>> >> Only exception is line length, we use 100 >>> >> >>> >> Run FindBugs on your code - http://findbugs.sourceforge.net/ >>> >> >>> >> Use CONSTANT_VALUE.equals(variable_name) to avoid null pointer >>> exceptions >>> >> >>> >> IMPORTANT >>> >> >>> >> You should run FindBugs on your new code or modified code, and commit >>> only >>> >> after fixing any bugs reported by FindBugs. It is recommended to use >>> the >>> >> IntellijIDEA (FindBugs-IDEA) or Eclipse FindBugs plugin to do this. >>> >> >>> >> >>> >> >>> >> -- >>> >> Lakmal Warusawithana >>> >> Vice President, Apache Stratos >>> >> Director - Cloud Architecture; WSO2 Inc. >>> >> Mobile : +94714289692 >>> >> Blog : http://lakmalsview.blogspot.com/ >>> >> >>> > >>> > >>> > >>> > -- >>> > Isuru Perera >>> > Senior Software Engineer | WSO2, Inc. | http://wso2.com/ >>> > Lean . Enterprise . Middleware >>> > >>> > about.me/chrishantha >>> >>> >>> >>> -- >>> Akila Ravihansa Perera >>> Software Engineer, WSO2 >>> >>> Blog: http://ravihansa3000.blogspot.com >>> >> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Best Regards, > Nirmal > > Nirmal Fernando. > PPMC Member & Committer of Apache Stratos, > Senior Software Engineer, WSO2 Inc. > > Blog: http://nirmalfdo.blogspot.com/ > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/ --047d7bea405600a7d105045aa40a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Guys,

Did you all manage to create the = formatter profiles?=C2=A0

On Tue, Sep 23, 2014 at 11:59 AM, Nirmal Fernando <nirmal070125@gmail.com> wrote:
Thanks for the reminder Imesh. I've created a Ji= ra for this=C2=A0https://issues.apache.org/jira/browse/STRATOS-813=

On Tue, Sep 23, 2014 at 10:31 AM, Imesh Gunaratne <imesh@apache= .org> wrote:
It's nice to see everyone is focusing on $subject. I just went throu= gh the latest Sonar findings and seems like there are nearly 270 critical i= ssues:


We can go thr= ough the list and fix these issues, on the next build Sonar listing will ge= t updated.

On Mon, Sep 22, 2014 at 7:32 AM, Akila Ravihansa Perera <ravihansa@wso2.com> wrote:
On Mon, Sep 22, 2014 at 4:39 PM, Isuru Perera <isurup@wso2.com> wrote:
> Hi everyone,
>
> I think we should agree on whether we should use tabs or spaces for th= e
> indentation.
>
> I'm suggesting that we should use 4 spaces for the indentation and=
> completely avoid tabs in our code.

+1

Tabs can mess up the code when working with different developer environment= s.


>
> I can help to come up with an Eclipse Formatter profile. We should als= o
> format the entire code base in a single commit after we agree on our c= oding
> standards.

Great! I can work on a IntelliJ Idea Formatting profile.

>
> WDYT?
>
> Thanks!
>
> Best Regards,
>
>
> On Tue, Sep 16, 2014 at 11:52 AM, Lakmal Warusawithana <lakmal@wso2.com>
> wrote:
>>
>> Hi,
>>
>> This is the guideline we used in WSO2, shall we have a look and se= e
>> whether we can use the same.=C2=A0 Please share your thoughts. Aft= er we finalised
>> will put this into wiki and make it as common guide line.
>>
>> Comments
>>
>> Doc comments
>>
>> All classes and all methods/functions MUST have doc comments
>>
>> Explain each parameter, return type and assumptions made
>>
>> Line comments
>>
>> In case you have complex logic, explain any genius logic, rational= e for
>> doing something
>>
>>
>> Logging
>>
>> Log then and there
>>
>> With ample local information and context
>>
>> Remember logs are for users. Make them meaningful, readable and al= so make
>> sure you spell check (ispell)
>>
>> Use correct log level, e.g do not log errors as warnings or vice v= ersa
>>
>> Remember to log the error before throwing an exception
>>
>>
>> Logic
>>
>> Make your genius code readable
>>
>> Use meaningful variable names. Remember, compilers can handle long=
>> variable names
>>
>> ________________________________
>>
>> Variables declared in locality, as an when required
>>
>> The underscore character should be used only when declaring consta= nts, and
>> should not be used anywhere else in Java code
>>
>> Make sure the function/method names are self descriptive
>>
>> One should be able explain a function/method using a single senten= ce
>> without conjunctions (that is no and/or in description)
>>
>> Have proper separation of concerns
>>
>> Check if you do multiple things in a function
>>
>> Too many parameters are smelly, indicates that something is wrong<= br> >>
>> Use=C2=A0 variables to capture status and return at the end whenev= er possible
>>
>> Avoid status returning from multiple places, that makes code less = readable
>>
>> Be consistent in managing state e.g. Initialize to FALSE and set t= o TRUE
>> everywhere else
>>
>> Where does that if block end, or what block did you end right now?= Have a
>> comment at end of a block at }
>>
>> Use if statements rationally, ensure the behavior is homogeneous >>
>> In case of returning a collection, must return an empty collection= and not
>> null (or NULL)
>>
>> Do not use interfaces to declare constants. Use a final class with= public
>> static final attributes and a private constructor.
>>
>> Always use braces to surround code blocks ({}) even if it is a sin= gle
>> line.
>>
>> Break code into multiple lines if it exceeds 100 columns
>>
>> Align method parameters, exception etc. in order to improve readab= ility.
>> Use the settings in your IDE to do this.
>>
>> Be sure to define, who should catch an exception when throwing one=
>>
>> Be sure to catch those exceptions that you can handle
>>
>> Do not use string literals in the code, instead declare constants = and use
>> them, constant names should be self descriptive
>>
>> Use constants already defined whenever possible, check to see if s= omeone
>> already declared one, specially in base libs, like Axis2
>>
>>
>> Java Specific
>>
>> Coding conventions -
>> http://www.oracle.com/technetwork/java/codeconv-138= 413.html
>>
>> Only exception is line length, we use 100
>>
>> Run FindBugs on your code - http://findbugs.sourceforge.net/
>>
>> Use CONSTANT_VALUE.equals(variable_name) to avoid null pointer exc= eptions
>>
>> IMPORTANT
>>
>> You should run FindBugs on your new code or modified code, and com= mit only
>> after fixing any bugs reported by FindBugs. It is recommended to u= se the
>> IntellijIDEA (FindBugs-IDEA) or Eclipse FindBugs plugin to do this= .
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Vice President, Apache Stratos
>> Director - Cloud Architecture; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chr= ishantha



--
Akila Ravihansa Perera
Software Engineer, WSO2

Blog: http:= //ravihansa3000.blogspot.com



<= /div>
--
Imesh Guna= ratne

Technical Lead, WSO2
Commit= ter & PMC Member, Apache Stratos



--
Best Regards,
Nirmal
=
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
S= enior Software Engineer, WSO2 Inc.




--
Best Regards,
Nirmal

Nirmal Fernando.
PPMC Member & C= ommitter of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
=
--047d7bea405600a7d105045aa40a--