On Sun, 18 Mar 2007, Andre Poenitz wrote:
did this for the NSIS stuff): assuming 70 lines per page, those 2608
lines would become about 40 pages. Personally I think that'd be too
much as a single document, but I assume you're not suggesting it all go
into a single file, but rather a small set of files?
Do you really see this less desirable as having a 2600 lines file lying
around somewhere in a corner you never work on?
My only concern is with the question of how difficult it is to
understand and maintain the code. (Having everything split up into a
gazillion files isn't good either from this point of view.)
As for your question, I don't know which is worth most. But... if we never
work on that code, could it be placed in a library? And could that
somehow be used to reduce build times?
Anyway, the question is really about how to partition the code. So let's
consider the extreme case: Let's put _all_ of the code in a single huge
C-file? Wouldn't that make building at least a little bit faster?
(I'm not serious of course, but I'd like to hear what your arguments
_against_ this idea would be)
Currently, for the eleven .C-files, each file would on average print to
about three pages.
Do you really print out .C files?
I do on occastion, e.g. I recently printed the code of a commercial driver
that I had to understand. (The so called "real-time" code was awful - it
did a malloc() and free() in each time step among other things...)
Even if so, you should be able to print put parts of a file if that's
what you need.
As long as the "stand alone" parts of the big file are separately marked I
don't have any objection. For a new developer, I think files of a normal
size might make it easier to get into the code. OTOH, I guess the
important point then is that stuff that belong together go into a single
file.
I start failing to see the advantages of small files. Maybe you can tell
me again..
To me it's a matter of divide and conquer applied to understanding the
code base. With files in reasonable chunks, I think it's easier to
understand code you've never seen before. This assumes that the stuff that
belongs together has gone into one file, and that the file doesn't contain
lots of other stuff.
However, as I said above. If the file has clear separation between
different parts (and perhaps an overview or "table of content" in the
beginning), then it's not so much of a problem.
I'm not sure if bug fixes / changes would be affected by putting
everything in one file though. If the code is spread out to many files,
then you get some information about what part of the code is modified by a
change through the name of the modified file. If all the code is in a
single file, you don't know this anymore.
As for this particular case, I have no idea if it'd work well or not.
However, we aren't just discussing this particular case but doing the same
to most of the LyX code, right?
Hmm... guess I do have an opinon then... I think 2600 lines in one file
is a bit much...
Why? Just because LyX usually does not do it?
No, I just felt that the equivalent of 40 pages of code is a bit much in a
single chunk. It's just my opinion.
Btw, from this 2600 lines roughly 300 vanish as they are duplicated
#include and using lines (so far for maintanance...). Moreover, most of
the pimpls can go as most of the classes _are_ already implementation
details which do not need to hide their implementation details further.
I wouldn't be surprised if that bought another 300 lines, resulting in a
file with less than 2000 lines.
I suspect additional lines with comments would be needed, but perhaps not
so many. This other stuff you're talking about (pimpls - implementation
details), won't that be much more work than just pasting the files
together?
PS: For some strange reason I have the impression that whenever LyX
development get the choice between two options, it chooses the one that
hurt most.
I'm only concerned that it'll make the code base more difficult to
understand and maintain.
Regards,
Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
