>>>>> "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
