Re: [Rssview-developers] Code Style and Conventions

[Martin <na...@we...>]

Am Fri, den 16.04.2004 schrieb Christoph Walcher um 15:35:

Hi Christoph,

first of all, I don't want to be annoying, but could you please
send plain-text e-mails to the mailing list? I can read HTML,
but you are changing the font size in your mail and it looks
very tiny on my 1600x1200 desktop.

> how do our code style conventions look like? I noticed that Matthias
> is using spaces indentiation I prefer tabs - what's the decision?

I love tabs. Please use them. I don't want to make restrictions on
the variations placing {...}-blocks, but please keep your technique
consistant.

Then I want to recommend the typical stuff:
- restrict the class members as far as possible
- use setters and getters
- don't produce spaghetti-code (e.a. methods which are awfully
  long)
- don't duplicate too much code
- make a note in-place when you are not satisfied with the
  code, using mailing list is not always optimal

>  Could you all use a TODO: or some other defined tag to mark Tasks,
> Considerations? This would ease my live because I can use this tags in
> Eclipse.

VI also highlights TODO-comments. Yeah, that's a nice feature,
but I would recommend that we add problems to the bug database
on SF in the future, if there are bigger problems.

> I started to introduce apache commons logging to replace all
> System.err and exception.printStacktrace() calls - I think using a
> real logging System will make it a lot easier to find bugs reported by
> users (They should attach their log file with a bug report). What's
> your opinion?

I have already worked with log4j. I didn't like it very much,
but I'm flexible and can adapt to it, if you like it.

There is really no problem from my side. But don't forget to ask
the others.

> Should we do some package refactorings - package structure is not
> really perfect?

Yes. But let's keep it now like it is until next release. I don't
like big changes right now, because some people are obviously working
on the project.

Changing the packaging structure should be done by one single
who locks the entire tree. We can talk about it later again,
because I want to say something about it, too.

Do you agree with me on this or do we need it for better coding
right now?

-- 
Martin <na...@we...>