Marc Liyanage wrote: > > Hi there, > > I've read the Coding Standards in the Avalon project. > > Most of the things sound very useful, some things > are very hard for me to do, like not using tabs, > but I would even accept that (and I *love* tabs :-). Using several editors, that sometimes insert tabs and sometimes insert spaces, so it is practically a bad thing to mix the two. I am sure we are agreed on this aspect. Anytime that tabs are inserted in code, there is innevitably some spaces that are there as well. It really screws up the readability of the code--and makes the CVS commit messages hard to read in some clients. That decision was a unanimous one for this project, and many other projects (most?) in the Apache Software Foundation java projects. > But there is one thing that I really can not understand: > That brackets *begin* on a new line. My first problem with this > is that it's not my personal style, but that's a minor issue, > I could still accept it. The real issue for me is that it's > against Sun's Java coding standards. Why did you choose it this > way? Wouldn't it be easier to follow Sun's guidelines as close > as possible instead of inventing yet another convention? Is there > some technical reason for this? Remember that this is a group effort. We have hashed this subject out many times on the mailing list. I really don't want to start another long discussion on the subject. I will say that I was one of the main proponents of following Sun's Java coding standards. However, somehow (and I can't remember how) we agreed on the C- style code blocks. I think it was in the interest of peace and just wanting to get something done. I agree that it is difficult to change your personnal style of coding--and the surfacing of sevaral good code formatters aleviates some of the stress. The issue with using code formatters is that CVS erroneously marks changes that are mere format changes, and the _real_ change gets lost. One of the committers here will extol the benefits of the current style of coding citing alot of research that he has personally made into the forum. However, there is little technical regarding the style of code. The real benefit of coding standards is that once your mind is comfortable with one standard, you become efficient with that standard. The more projects that conform to the standard, the lower the learning curve for those projects. > The reason I'm concerned about this is that it's never easy to > convince other developers to change their habits, myself included. > But it's a lot easier if you can point to established guidelines > like the ones from Sun, people can accept that. I agree with your assessment. However, I will point out that Sun's coding standards are minimalist, and do not help prevent errors. There are always additional coding practices that really help in making fewer mistakes--and lets the compiler catch the ones you happen to make. For instance: explicit scoping of variables and methods (using "this" and "super" for class variables/methods), using descriptive names for variables, using additional standards for javadoc formatting. Style is a _very_ personal issue, and many people get very protective of their style--almost to the point of religious ferver. The problem with approaching things like style from that point of view is that it is like straining out gnats while you are getting ready to swallow camels. The style of the code does not affect the runtime of the code. It affects the readability and therefore the maintainability of the code. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
