Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: C naming conventions Date: Wed, 14 Sep 2022 08:05:02 -0700 Organization: A noiseless patient Spider Lines: 79 Message-ID: <86h71am1y9.fsf@linuxsc.com> References: <3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com> <86edwgptqk.fsf@linuxsc.com> <86a673piw4.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="e4a07c6eb40a7dcf36ed28254bbf399a"; logging-data="3167559"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gBt9AUS33keBcM8s+mpkx2tTJrHfs7hw=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:bka5UYZpbJy1LUjXx8eLRG1Ci5E= sha1:QjgwPjjp65fy9O4ti/3ncoOIkQ8= Xref: csiph.com comp.lang.c:167720 kegs@provalid.com (Kent Dickey) writes: > In article <86a673piw4.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> kegs@provalid.com (Kent Dickey) writes: >> [...] >>> I'm trying to put some protective pads on to avoid C's many >>> pitfalls, and make it easy to browse code, even without complex >>> tools. [...] >> >> I'm not sure what kinds of tools you count as "complex tools". >> Do you mean to avoid using any of the standard utilities that >> were part of Unix 40+ years ago? To me it seems silly to design >> rules assuming such a primitive environment (that is, one where >> the common Unix utilities of circa 1980 were not present). >> >> One question for you: looking over your own code, what would >> you say is a rough distribution of function lengths? What is the >> range of lengths, what is the average length, what is the median >> length? If you can get exact numbers, so much the better, but >> rough guesses (assuming they are informed guesses) are fine. > > Unix 1980's stuff is fine, but I don't want to rely on cscope, > syntax highlighting and other IDE stuff if I don't need it. Same here. > You can see code that mostly meets my style definitions at: > http://kegs.sourceforge.net/kegs.1.16.tar.gz (some was written > almost 30 years ago and doesn't meet the style guidelines and I > have not fixed all the problems yet, mostly function and global > variable naming issues). Thank you, it's good to have this example. I should look at it more closely but perusing it lightly it looks like your layout choices are close to my own. > All my functions look like: > > return_type > function_name(arguments here) > { > ... > } Same here, except I put the open brace immediately after the close parenthesis of the function line. > (Primarily to make [[ and ]] work in vi, but it also makes many > code grep's easier, the definition of serial_init is /^serial_init > in vi). Right. I use emacs but the idea is the same. > So I can find the number of functions with: > grep '^}$' *.c | wc > and the total lines: > wc *.c > > and I get 36747/756 = 48.6 lines per function (counting all > overhead outside the functions as well). ts=8. Some time ago I wrote a short awk script to tabulate function statistics. Running that on your .c sources gives an average of about 39 lines per function (this measure counts only those lines inside the outer function braces), with about 9.5% blank lines (again inside function braces). To give some ranges, individual files range from about 5% to just over 18% blank lines (there is one outlier at 3%), and these number match my own rule of thumb of between 5% and 20% blank lines. The range of average lines per function goes from about 15 lines/function to about 66 lines/function, with one outlier of about 86 lines/function. For contrast, my own code typically falls in the range of 10-15 lines/function average; anything over 20 (average; individual functions can be longer) or so indicates a need to look at refactoring.