source code may be getting a bit intimidating
Lubomir I. Ivanov
neolit123 at gmail.com
Mon Jan 7 06:38:42 PST 2013
On 7 January 2013 08:28, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>> things are always getting messy when large files have to be maintained
>> and edited in a code base, down the road.
>> rules of thumb on my end for implementation files is "keep them under
>> 1k LOC" and its better to have more files that a couple of bigger
>> even if no major issues pop out, in C, at least function names would
>> start making less sense as more are added.
>> "add_button_to_something()", will have to be prefixed to
>> but inevitably more and more features will be added to subsurface
>> which will increase the code base and will affect files like gtk-gui.c
>> and divelist.c (which are two of the bigger ones).
>> what do you think can be done to improve the code base? how can we
>> start organizing the code base into a better structure?
>> i'm quite interested in the opinion of people who wan't to contribute
>> but are getting lost and potentially give up (if there are such of
>> is this nonsense talk at this point...?
> No, it's not nonsense. I just pushed another largish commit for the dive
> planning stuff and gtk-gui.c is now approaching 3kloc.
> I had been thinking of splitting gtk-gui.c into the shared main UI code
> and breaking out the different dialogs into their own files.
> Linus has done great work on making profile.c easier to understand (and
> I agree with him that monster functions are far worse than monster
> files), but profile.c now also weighs in at a massive 2.2kloc. I am less
> clear about what to do about that one - or about divelist.c (which is
> approaching 3kloc as well).
> The problem that massive code restructuring always has side effects.
> git blame becomes semi-useless (which in our case isn't too bad as most
> of the code is from only two authors). Sometimes the separations are
> simply artificial and you pay the price with massive .h file and
> call trees that go all over the place. Hard when reading the code and
> trying to chase down bugs.
> So what I'm trying to say is: yes, I think we are approaching a point
> where we might want to do something about this. no, I'm not ready to rip
> everything apart and enforce a hard 1kloc rule or something because
> these rules are always just arbitrary.
> I'm willing to consider patches that make sense. That make things more
> structured, easier to understand and to follow. And that
> DO NOT INCLUDE ANY OTHER MODIFICATIONS.
of course, this thread is technically just a reminder in the case of
lead developers and maintainers, yet still would be interesting to see
after all, often the complains is what forces a maintainer to flip a
if there are none, i guess we're good for now...
what i can't really avoid mentioning, is the fact that spending 5-10
(or more) minutes, often when planning a new feature, thinking about
physical structure (files and folders) and how said feature will
become a modular or integral part of the code base can pretty much be
the most satisfying aspect of source code project development... and
actually everything in this aspect is a function of good naming - good
naming of folders, files, functions etc; it can lead to a healthy code
i'm not some sort of evangelist about these things or have some sort
of a OCD. so, at the same time i don't find this to be the most
important part of project development. i've just learned to respect
More information about the subsurface