Here's my 2c worth. I agree that we shouldn't reqire a standard which is onerous for developers that aren't using a particular IDE.
I also agree that the curly brace position issue is not worth wasting time over. Much better to spend the time doing better Javadoc. Variable naming is also probably not such a big deal. Naming of methods, classes and packages is more visible (in increasing importance) - articulating some policies here might be helpful. As for the import statements, personally I *like* using "*", since it seems faster and cleaner to me. I've never ever had a problem with namespace pollution - and if you do, just don't use * for that package. I personally don't like huge lists of imports, since I think they are much harder to manage and keep clean (especially if you're not using a tool like Eclipse). Sunburned Surveyor wrote: > One of the topics discussed in an earlier thread today was code format > standards or code style standards.Using tools that will allow us to > automatically enforce a coding standard was suggested. Using these > tools to convert existing source code from other JUMP "brands" to our > style for OpenJUMP was also a suggestion. > > I'm really excited that others would be interested in this type of > consistency and quality for our source code of OpenJUMP. I don't want > us to loose that momentum! > However, I'm concerned about implementing such a code style standard > for a couple of reasons: > > [1] I don't think we want to get into a situation where we are > dictating what IDE, if any, our contributing developers use. I would > want to make sure that any tools and/or plug-ins that we use for > automatic code formatting were free from dependencies on a particular > IDE. > > [2] Do we really need to have our contributing developers worry about > where they put the curly brace in the code? As was mentioned in the > discussion, I think there are other more important things we can do to > improve the quality and usability of our code. I'm thinking of things > like Javadoc comments, other source code comments, change logs, unit > tests and the like. I'd much rather fight for a requirement that all > public methods have an intelligent Javadoc comment or something > similar to that, than push for a standard variable naming convention > or rules geverning the placement of parentheses and curly braces. > > [3] How on Earth would we ever get our developers to agree on a common > coding standard? I can just imagine the discussions: > "Should all interfaces and exceptions should share a common prefix in > their class name?" "Should we ever allow passing a method call as a > parameter to a method call?" > > I just don't think we could all agree on this stuff, do you? I don't > think it would be worth the bickering to me. Maybe we could just adopt > an existing standard, but then we would all have to read an learn it, > and it would probably be different from what we used at work, and > we're probably to lazy to do it, and… > > In summary, if the source code a developer contributes is functional, > and I can understand what it does when I read it, I am happy. > Everything else is gravy. I know a lot of open source projects have a > code style standard, but I think our community is too diverse and > lacks the strong central authority necessary to make this level of > control successful. > > I am still open to further discussion on this topic. :] If we can > address some of these basic concerns I am more than willing to learn a > new tool or coding style. When I say this I speak only for myself, not > for the other developers or for the project iteself. > > The Sunburned Surveyor > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
