On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar <de...@adacore.com> wrote: > On 4/13/2012 9:15 PM, Chiheng Xu wrote: > >> So, I can say, most of the GCC source code is in large files. >> >> And this also hold for language front-ends. > > > I see nothing inherently desirable about having all small files. > For example, in GNAT, yes, some files are large, sem_ch3 (semantic > analysis for chapter 3 stuff which includes all of type handling) > is large (over 20,000 lines 750KB, but nothing would be gained > (and something would be lost) by trying to split this file up. > > As long as all your tools can handle large files nicely, and > as long as the internal organization of the large file is > clean and clear, I see no problem. >> >> >
Actually, I only partially agree with you on this. And I didn't say smaller is necessarily better. But normally, high cohesion and low coupling code tend not be large. Normally large files tend to export only few highly related entry points. Most of the functions in large file are sub-routines(directly or indirectly) of the entry points. The functions can be divided into several groups or layers, each group or layer can form a conceptual sub-module. I often see GCC developer divide functions in large file into sub-modules by prefix them with sub-module specific prefix and group them together. This is good, but not enough. If the functions in sub-modules are put in separate files, then the code will be more manageable than not doing so. This is because the interfaces/boundaries between sub-modules are more clear, and the code have higher cohesion and lower coupling. -- Chiheng Xu
