Hi David, I din't mean to propose some hard constraints or major refactoring activity. Problems I have noticed are very natural in an open/large development environment. Having some guidelines, discussions on such topics will help every one to come to the same page and minimize the pain in the future (IMO).
Please find my comments below. Regards, Sanjaya Note: BTW, I forgot to put the prefix [AXIS2] in the subject earlier. Sorry about that. On Tuesday 13 February 2007 17:40, David Illsley wrote: > Hi Sanjaya, > If you're suggesting a mass change based on a set of rules, I'm not > enthusiastic (and quite likely to -1 it)... it's quite likely that > some of the seemingly extraneous checks are there because there have > been problems in the past. > Not at all. But when we do defect fixes and other improvements if we can fix up some of these without having to modify lot of code, is I am proposing. Last thing you want is some nice looking code with broken functionality. > Please list the methods which you believe are being over-cautious and > we can address them individually with a little thought. > I will add the areas I came across as improvements to JIRA and where possible a patch as well. So that you all can make the call. > If you're looking for guidelines for future contributions then I'm > open to developing them (I'm not aware that they exist now) but don't > wish to be tightly constrained to them. I tend to write cautious code, > and unless there's a clear, specific performance problem, that's how > I'd like to continue. > I think we are on the same page here. > David > > On 13/02/07, Sanjaya Karunasena <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > After going through some of the Axis2 code, I have noticed many > > instances of duplicate input parameter validations leading to redundant > > code. This has negative impact on performance as well. Also the error and > > exception handling policy is not clear, or may be not consistent. > > > > What are the typical guidelines followed in the project? > > > > > > Few suggestions on input parameter validation are; > > * An instance of a class which make use of an input parameter for the > > first time should validate the parameter > > * A instance of a interface class (Actor interface) should assume > > default values for required (mandatory) parameters where possible (Could > > be due to a flexibility provided in a specification) > > * If there are optional parameters for an interface, that should be > > handled through method overloading (not by allowing null inputs) > > * Any exceptions to this can be discussed and come to some logical > > agreement based on the specific scenario (80, 20 rule) > > > > > > Thanks > > Sanjaya > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
