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 <im...@apache.org> 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 < > raviha...@wso2.com> wrote: > >> On Mon, Sep 22, 2014 at 4:39 PM, Isuru Perera <isu...@wso2.com> 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 <lak...@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/
