On Tue, Mar 20, 2007 at 02:28:13PM +0100, [EMAIL PROTECTED] wrote:
> >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.)
I don't think there's much difference. I'd rather expect it to be
easier as duplicated line noise from #include and using is avoided
(said 300 out of 2600 lines in the test case)
> 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?
I fail to see how that would work. It currently _is_ in a static
library.
> 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?
It would indeed, but it would hit way behind the break-even point.
> (I'm not serious of course, but I'd like to hear what your arguments
> _against_ this idea would be)
I want to minimize turnaround times for the average development cycle
which usually looks like change a few bits in two or three files,
compile these files, link (the latter conveniently called by 'make').
So let's approximate this:
(a) Right now:
3 * ( 300 lines [real LyX code] + 30000 lines [from includes] )
+ linking time
== 90900 lines + linking.
(b) Proposed solution (assuming that most features will be "local" to
one of the "big files"
1 * (10 files * 300 lines [LyX] + 50000 lines [possibly more complex
includes] ) + linking
== 53000 lines + linking
(c) Your unserious proposal
1 * (135000 lines [LyX] + 90000 lines ["full includes"]) + linking
== 225000 lines + linking
So, no, I would not expect that lumping everything together would help.
Btw, note that
(A) the lines pulled in by #include create the major part of the
compiler work in the "small cases" (a) and (b), and
(B) the paradigm of using lot of li'l files is two or three decades old,
when there was neither enough RAM to have files of n*10k edited nor
#includes where as heavy as they are now. X11/X.h is 942(!) lines
with _all_ dependencies.
> >>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 think navigation in a single file is still easier than within a
directory of 10 files, each 1/10th the size, even if editors have some
sort of 'bulk' capability.
> >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?
We are discussing the general case. src/graphics just serves as an
example because it is fairly isolated and of about the "right" size.
> >>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.
It might be. But the real question is:
Does this feeling outweigh losing 15s each time you run make?
> >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?
De-pimpling is more work than pasting the files together, but it is
a pretty mechanical job. Nothing for the last week before a release,
but nothing likely to introduce errors.
> >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.
It is good that these concerns are expressed. OTOH, maintainability
is is exactly one of the reasons I want that change: Nobody currently
can _quickly_ fix a bug (unless he trusts his abilities and commits
without compiling).
Andre'
