source code may be getting a bit intimidating

[Dirk Hohndel]

"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
> ones.
>
> 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
> "something_add_button_to_something()".
>
> 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
> course).
> 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.

/D