On Mon, 13 Oct 2014 08:18:57 +0100 Jonathan Dowland <j...@debian.org> wrote:
> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote: > > On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read <zen75...@zen.co.uk> > > wrote: > > > On 12/10/14 18:13, John Hasler wrote: > > > > You have no problem with an 1800 line function? > ... > > > I have a problem with 1800 line functions in general; > ... > > I have no problem with an 1800 line function. > ... > > *What* 1800 line function? The commit URI that was shared was an > 1894-line *file* with a large function definition starting at line > 638 and ending at 1890. That's a 1252-line function. OK, %s/1800/1252/g I have a hunch the guy I replied to would have had as much of a problem with a 1252 line function as an 1800 line one. My Ruby friends disparage functions over 30 lines long. I view function lengths as an implementation detail and don't worry too much about them. The code looked reasonable to me. > > Not only that but you're looking at a commit dating from August last > year. The function doesn't even exist any more in current systemd[1]. > There are no functions of even a 100 lines length in that file now. > > [1] > http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c I'm not that concerned about function lengths anyway. > > > > What I *DO* have a problem with is the guy's welding pam onto his > > new init, and welding other critical and former separate OS > > functionalities onto his "toolset", preventing (either technically > > or by them being removed from the packages) former modules from > > being used. > > Which guy is that? The commit that the URI referenced was written by > Lennart Poettering, so I guess you mean him; Yep. > but that commit didn't > touch the file that was being complained about. Maybe you mean one of > the other 17 people who have contributed to that file? I wasn't talking about that commit, I was talking about what has been done, and what Poettering has stated his goal is. > > > If I were to maintain his code, before reducing the 1800 line > > function, I'd do something about the function with 20 arguments, > > with each argument including a function call. I'd replace all of > > that with a struct pointer. > > I'd start with *reading the code* if I were you; something you guys > clearly aren't doing. OK, nothing in that code was that important. I *did* notice a function with 20 arguments, and I, personally, would substitute a struct pointer for that. But, as I said before, my objection to systemd isn't coding style. > > But if you get past that you'll be pleased to discover that such > clean ups and refactors are happening quite often. See e.g. > df2d202e6ed4001a21c6512c244acad5d4706c87 ("bus: let's simplify things > by getting rid of unnecessary bus parameters"). I'll leave you to > guess the author of that one. I couldn't find that, but once again, I'm not saying anything about the coding style. As a matter of fact, the thrust of my post was basically that I'm not concerned about the referenced code's coding style, I'm concerned about the macro-architecture. SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013141807.27141...@mydesq2.domain.cxm
