Future of teamwork plugin

[Andreas Pakulat]

On 06.07.07 13:21:16, David Nolden wrote:
> Am Freitag, 6. Juli 2007 11:28:56 schrieb Andreas Pakulat:
> > I think you got the wrong impression, at least for me its not solely
> > about the advanced C++ stuff, its about unreadable code files, with
> > #include's in the middle of a .cpp, with multiple classes in the same
> > files (yes this might be judged as a personal preference, but I think
> > its making it easier to understand code). On top of that the code will
> > be unmaintained in the upcoming months and so far David said he will
> > probably maintain it after SoC.
> 
> I don't think there is any includes in the middle of .cpp files. If you've 
> seen it, then an individual case, and as such does not make the whole plugin 
> unmaintainable.

I hope I didn't say unmaintainable anywhere. What I said was hard to
maintain, which is a difference, at least to me. Also IIRC I saw the
include-in-the-middle of files more than just once or twice, but of
course that may have changed and/or I may misremember.

> There is only multiple classes in the same file when:
> A) It is a few small helper-classes

I'd split that up nonetheless (see vcs interfaces).

> B) It is a few classes that logically belong together and are not too big

I'd split up the implementation, depending on how large it is (see qmake
parser's AST classes, 1 header as the AST nodes have pretty simple API,
but multiple implementations, because I found it a hassle to navigate in
them)

> C) It is a few small helper-classes plus one big main-class

I'd split that up into two parts: helper + main class file (or even more
according to a) and b).

> In C++ you should ideally split the code into as many classes as it logically 
> makes sense to keep things separate, and it's extremely unpractical to create 
> a new file for each such class.

Personally I don't think thats unpractical, its not that hard to have a
few dozen files open and easily switch between them in any editor I've
tried until now (that includes kdevelop,vim and emacs). 

> So that's a tradeoff between easy to read and easy to write, but I don't 
> understand where this is a problem with features like code-navigation and 
> jump-to-class at hand.

And I don't understand what the problem is with having multiple classes
when you use these features.

> By forcing a coder to create a new file for each class, you encourage
> him to create less classes, thereby you encourage him to less split
> his code into logical units, thereby you encourage him to write worse
> code.

Sorry, thats broken logic to me. Creating a new class is as easy as
Ctrl+N -> headername, Ctrl+N -> source name (plus selecting the right
type so that kdevelop uses its templates and fills copyright header,
include guards and basic include's). Or if you use the new-class-wizard
its just 1 click + filling out a lineedit for the class name.

Granted if you create new classes in a different directory all the time
its a bit harder, because you've got to make the directory active but I
think this is seldom the case as you normally work on 1 module at a time
and we don't split our files yet that much across directories.

Andreas

-- 
You will have long and healthy life.