Few things to note; see whether everybody is in the same page: 1. if we can use 'axis2_env_t' instead of 'axis2_environment_t', seems simple and short, and nothing loose in understanding the name. And the variable name as 'env', since axis2_env_t pass on the stack there should not be any problem with name conflicts. (This is a suggestion not only for the style guide is also for the code in ".../modules/common/src/axis2_environment.c)
2. If we plan to use GNU indent it should be part of the build. Since in all systems we do not have it, we may be needing to either expand indent rules in this doc, so ppl can see them in detail and they can follow them, or we need to bundle GNU indent with distribution tarball (since it is GPL I guess it is impossible - and asking ppl to download it and compile it on their system is not seems nice, well, maybe) 3. Since you are suggesting GNU style indent, it is better all examples in this page follow that rule. Or we use slightly modified version of both GNU and K&R style. Few minor changes were done on the file, please check. But not included any of the above suggestions. Thanks -Lilantha -----Original Message----- From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Monday, October 10, 2005 12:36 PM To: Apache AXIS C Developers List Subject: Re: [Axis2] Coding Style for Axis2/C Coding style is now in a seperate doc. It is short but it is supposed to cover everything. https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/xdocs/axis2_c oding_convention.html Plese comment. Thanks, Samisa... Paul Fremantle wrote: > Samisa > > Nice work... > > When you reference: > > http://httpd.apache.org/dev/styleguide.html > http://www.gnu.org/prep/standards/standards.html > > > > > Are there any particular standards in there you think we should use. I > would prefer if we had a single master guide with the aspects we care > about listed. > > Coding standards in C projects are very important because it is such a > flexible language. > > Paul > > On 9/29/05, *nandika jayawardana* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi, > I am also ok with axis2c prefix , > > Nandika > > > > On 9/28/05, *Damitha Kumarage* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi, > Samisa Abeysinghe wrote: > >> Sanjiva Weerawarana wrote: >> >>> On Wed, 2005-09-28 at 21:44 -0600, Lilantha Darshana wrote: >>> >>> >>>> IMHO, I would suggest prefixing all names with 'axis2c' > makes difficult >>>> to read names. It should be easy to read and find names by > their >>>> own. Sometime >>>> searching names by enabling "find whole word only" makes > difficult on >>>> having these prefixes. Since we know these code are from > axis2c we >>>> might >>>> want to drop the prefix, if you do not have a strong reason > to use it. >>>> >>> >>> >>> Going back to my old C programming days, it is absolutely > critical to >>> prefix all names with a unique constant .. the pain of link > errors is >>> simply not worth it. >>> >>> I'd suggest s/axis2c/axis2/g though. >>> >>> >> Yes, the obvious rationale for the prefix was the namespace > conflicts, >> again going along with Axis C++ experiance, where at one point we >> really had to go back and introduce namespaces. >> >> I am OK to change axis2c to axis2 :) > > Remember we have named our files also with axis2c prefix like in > axis2c_om_container.h. > So I think keeping all names with prefix axis2c is ok to be > consistent > with file names as well. > Changing files names is not a good idea because I think what > we gain is > not worth the effort(again > checkin to svn repo with different name) > > cheers > damitha > >> >>> >>> >>>> Further of using underscores ('_') with often used names > needing us >>>> typing two keys in key board very often :-). >>> >>> >>> Yeah but again its a reasonably widely used model. The other > option is >>> of course almost Java-like CamelCase: Axis2cFoo Axis2cBar etc.. >>> >>> >>> >> We used the APR source as out master guide, when it came to > selecting >> style. >> >>> Sanjiva. >>> >>> >>> >>> >>> >> >> > > > _______________ Siebel IT'S ALL ABOUT THE CUSTOMER Visit www.siebel.com This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners. Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited. If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation.
