Egon Willighagen schrieb:
> On Wednesday 17 May 2006 09:22, Kai Hartmann wrote:
>>>> As soon as we reach CDK 1.0, which should only be a question of a few
>>>> month, doing changes like this the way we did it so far is over.
>>> Either the CDK 1.0 is further away, or we will have more changes like
>>> this from version to version: the reason is that the current interface is
>>> not consistent enough. I don't think I can fix this in the next two/three
>> Maybe this can be a good reason for another workshop. On the other hand,
>> to get the interface consistent over all classes, you have to examine
>> each and every one of them to get a full overview. That doesn't sound
>> like a job for a large team to me. However, I volunteer to spend one or
>> two full days with 2-3 other people to go through all *kernel* classes
>> for this task. I think it would be a major step forward if the
>> interfaces of these classes were consistent.
> Count me in. Two down, 1-2 to go... who else?
Well, to get a feeling for the current code status, I went through some
classes and cleaned it here and there. Some things occurred more often,
- Treatment of Serializable classes
I think we should give a serialVersionID to every serializable class:
"If a serializable class does not explicitly declare a serialVersionUID,
then the serialization runtime will calculate a default serialVersionUID
value for that class based on various aspects of the class, as described
in the Java(TM) Object Serialization Specification. However, it is
strongly recommended that all serializable classes explicitly declare
serialVersionUID values, since the default serialVersionUID computation
is highly sensitive to class details that may vary depending on compiler
implementations, and can thus result in unexpected
InvalidClassExceptions during deserialization. Therefore, to guarantee a
consistent serialVersionUID value across different java compiler
implementations, a serializable class must declare an explicit
serialVersionUID value. It is also strongly advised that explicit
serialVersionUID declarations use the private modifier where possible,
since such declarations apply only to the immediately declaring
class--serialVersionUID fields are not useful as inherited members."
- Improper documentation
Automatically assigned documentation should IMHO never occur in the
source code (like "Description of the field"). Either leave it or - much
better - document it properly. (Though I think almost every software
project has a documentation problem ...)
- Test cases that don't test anything
In a number of cases, tests have been written, deactivated and
forgotten. I think a test case that cannot be resolved at the moment
(due to lack of time or whatever reason) should have Assert.fail() in
- Unused variables, unused import statements etc.
Easy to detect and resolve, e.g. with Eclipse.
Summing up, I think there should be a minimal set of important coding
style conventions that should be written and distributed to every new
developer joining the project (and every old one). Maybe this has been
addressed by the qa team already?
I think the whole project is in a very good overall shape. A good and
even more consistent kernel interface would address a few issues of the
past, while a coding style convention would give rise to - well, not
automatically - a better quality for new code.