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
