Re: Coding style etc
[ Resending this because it got lost last time? ] Jochen Hoenicke wrote: If there is a code-formatting tool I don't see a reason why we shouldn't convert. We should make sure that nobody has pending changes to that class before converting them, though. Great - I will experiment with the various code formatting tools and report back what I come up with. There is currently no document describing the libgcj coding style, but I think it would be good to have one. If I get time I'll see if I cant put something together. Another thing to consider are the copyright notices at the beginning of the file. We should probably make a template of how they should look now and use that for all files. Currently classpath has several different styles of copyright headers. Personally those huge page-long GPL copyright headers also bug me a bit. Its a safety issue, they put stress on my mouse-wheel finger ;-). It would be great if we could just stick to something like: /* Copyright (C) 1999, 2000 Free Software Foundation, Inc. This file is part of Classpath. This software is copyrighted work licensed under the terms of the Classpath License. Please consult the file "CLASSPATH_LICENSE" for details. */ (this is modelled on the Cygnus libgcj header). I don't think that the comments make the code more difficult to read! The only case comments might disturb you, is for simple methods, where the implementation consists of a single line. But if you want to get a overview of the whole class, its much nicer to look at the javadoc generated documentation, than to look at the code. Thats true, but from my perspective when I'm looking at source code I usually want to know HOW something is implemented, or to establish why I'm seeing a particular erronous behaviour. Its easier and quicker to get a nice overview of how a class is implemented by not having to wade through a few screens of javadoc that is only a reproduction of what I already have open in Netscape in a different window, or in a java book in front of me. Javadoc comments also draw my attention away from the *important* comments - those which document particular implementation details, known problems, etc. AFAIK, Classpath wants to generate its own documentation. The comments are also useful to document special things (e.g, that the Vector.copyInto() can throw an ArrayIndexOutOfBoundsException, even if that isn't made explicit in the code). It's of course a lot of work to write comments, and so they sometimes were omitted. Yes - while I *do* see the value in having such documentation (so it can be distributed wherever classpath is distributed without requiring end users to obtain the API documentation from elsewhere), I for one would rather spend my time writing quality code than rehashing API documentation which already exists in five zillion java books and endless free-as-in-beer html documentation. There is also a copyright issue here - how can we write clean-room javadoc comments when the original javadoc was what we based out implentation on in the first place?? regards [ bryce ]
Classpath Volunteer
Greetings, I would like to know if there is any need for volunteers to help test Classpath. I am very interested in contributing to the Classpath project, but my only talent with programming lies in Perl, Python and Java. I would be willing to write test code in Java to verify VM compatibility and weed out bugs, and I would also be willing to write some API documentation for Classpath. Please let me know if you think I can be useful in any of these areas. Sincerely, Jason Burke
Re: Coding style etc
Mark Wielaard [EMAIL PROTECTED] writes: Yes I would very much like to see one coding style use. It would be nice if old code could be automatically reformatted. And it would probably help the coders if there where syntax files for this style for popular editors. If no one else does, Paul can probably write a lisp reformatter which works within emacs in batch mode to automatically reformat everything. Unless there is a mode in emacs to automatically format my code that way I probably won't do it while writing code but I'll gladly run a program to do it for me when I'm done. This is a much more flexible approach than enforcing any arbitrary, no matter how good, coding style on another person. Brian -- Brian Jones [EMAIL PROTECTED]
Re: Classpath Volunteer
"Jason" == Burke, Jason [EMAIL PROTECTED] writes: Jason I would like to know if there is any need for volunteers to Jason help test Classpath. I am very interested in contributing to Jason the Classpath project, but my only talent with programming lies Jason in Perl, Python and Java. I would be willing to write test code Jason in Java to verify VM compatibility and weed out bugs, and I Jason would also be willing to write some API documentation for Jason Classpath. Please let me know if you think I can be useful in Jason any of these areas. Are you aware of the Mauve project? http://sourceware.cygnus.com/mauve/ Mauve is a free Java test suite. It is very far from being complete, and new tests are always welcome. Persistent contributors will be rewarded with direct cvs commit access... Ideally I'd like to see classpath/gcj bug fixes accompanied by a regression test for Mauve. We've been fairly lax about this on the libgcj side of things (we've been ok, but not great, about writing new tests as we write new code). Tom
Re: Coding style etc
"Bryce" == Bryce McKinlay [EMAIL PROTECTED] writes: If there is a code-formatting tool I don't see a reason why we shouldn't convert. We should make sure that nobody has pending changes to that class before converting them, though. Bryce Great - I will experiment with the various code formatting Bryce tools and report back what I come up with. There is currently Bryce no document describing the libgcj coding style, but I think it Bryce would be good to have one. If I get time I'll see if I cant put Bryce something together. It is basically the GNU C style, extended for C++ and Java, with one exception (there is no space before an open paren for a method call; I personally still don't like this exception, but whatever). FWIW I like the GNU-ish style, but then I've used it for years. I don't feel too strongly about it. What I do feel strongly about is using a relatively small indent step, and not an 8-column tab. I find deeply indented code very hard to read, and write. Bryce There is also a copyright issue here - how can we write Bryce clean-room javadoc comments when the original javadoc was what Bryce we based out implentation on in the first place?? I agree. This might have been our rationale for not writing javadoc comments (I don't know for sure). You might try writing the docs based on the code, but then you run into problems if there are bugs. Ideally the doc comments would follow a specification, but there is no real spec... Tom
