I don't want to be insensitive to the concern, particularly since both Giovanni and you raised it, but I just don't get it? Navigating within a file seems at least as easy as navigating between files, and files on the order of ~2k lines in case of d3dbc.c and ~5k lines in case of tpf.c don't seem particularly unusual in either vkd3d or Wine. (I had been thinking we might as well merge hlsl.c, hlsl_codegen.c and hlsl_constant_ops.c, but I guess not then...)
I suppose it depends a lot on one's own thought processes and habits, so I don't claim that what's better for me is intrinsecally better for everybody. Also, as you say, Wine's standards are much worse than what we're discussing here, so, while I don't think they are good standards, I had to come to terms with them.
I agree with Zeb that having smaller files helps segregation of code, and if code is segregated properly with reasonable interfaces between the segregated parts it is easier (for me at least) to understand and change, because I can study each of the segregated parts somewhat independently. In theory it is not the number of lines or functions that counts, but in practice, with some exceptions, once a file has grown past a few thousands lines of code it's hard for me not to think that it would make good use of some splitting.
Something like this. I find it hard to give an objective rationalization of *why* I want to split things up, but I think to a degree it comes down to the same reasons that large functions should be split up. It communicates to the reader that a piece of code is self-contained and should make sense by itself. On the other hand, when I see a large file, much like a large function, I can't help but think "can this be split up into a coherent set of pieces?" To a degree I guess it also is an intuitive judgement, and that can be poor.
The cost of compiling large files shouldn't be discarded either, I don't think. E.g. our d3d12.c test file (or d3d11.c, and so on) doesn't really need to be split from an architectural standpoint—yes, the tests *can* stand alone, but there's no common thread segregating any one group of tests from another, and splitting *every* test into its own file seems excessive. No, if something makes me want to split up that file, it's that it takes multiple seconds to compile (depending on machine).
I don't think there's any concern regarding navigation, at least on my part.
That said, it's also something that feels like a waste of time to argue a lot about. I didn't feel like hlsl_constant_ops.c was particularly necessary, and would probably have just kept it in hlsl_codegen.c if it was just me, but it also doesn't feel like it's worth bikeshedding at all. Nor do I really intend to argue about splitting up the backend readers and writers here, just make a vague comment about code organization and move on.
-
Zebediah Figura (＠zfigura)