Future of teamwork plugin
apaku at gmx.de
Fri Jul 6 12:02:13 UTC 2007
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
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
> 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
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.
You will have long and healthy life.
More information about the KDevelop-devel