Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Goal: reduce overall function complexity
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 14 May 2025 23:28:48 +0200 (CEST)
Hey,
Wouldn't it be cool to set a cap and make a subsequent CI job that turns red
if any single function in product code is too complex? As a way to make sure
we keep the code clean and readable.
I'm thinking this command run on Debian in the source tree:
pmccabe `find src lib -name "*.c"` | sort -rn | head -1 | cut -f1
If this number is 100 or less we are good. If not, one or more functions are
too complex.
Complexity is a weird thing and its hard to objectively say what is, so
therefore I figure we can just use a tool that gives us a number and we use
that as judge. pmccabe does exactly that.
The primary way to reduce complexity is of course to split up huge functions
into multiple sub functions. The challenge is to do it sensibly.
Right now, the top-10 most complex functions in production code according to
this tool are (score, filename, line number, function name):
196 src/tool_operate.c(870): config2setopts
150 lib/vssh/libssh2.c(1639): ssh_statemachine
142 src/tool_getparam.c(1677): getparameter
124 src/tool_operate.c(1785): single_transfer
112 lib/ftplistparser.c(366): Curl_ftp_parselist
110 lib/setopt.c(258): setopt_long
103 lib/formdata.c(205): FormAdd
100 lib/vssh/libssh.c(1081): myssh_statemach_act
100 lib/mprintf.c(639): formatf
99 src/tool_operate.c(437): post_per_transfer
Anyway. I plan to have this as a goal of mine to fiddle with over the year
going forward.
Date: Wed, 14 May 2025 23:28:48 +0200 (CEST)
Hey,
Wouldn't it be cool to set a cap and make a subsequent CI job that turns red
if any single function in product code is too complex? As a way to make sure
we keep the code clean and readable.
I'm thinking this command run on Debian in the source tree:
pmccabe `find src lib -name "*.c"` | sort -rn | head -1 | cut -f1
If this number is 100 or less we are good. If not, one or more functions are
too complex.
Complexity is a weird thing and its hard to objectively say what is, so
therefore I figure we can just use a tool that gives us a number and we use
that as judge. pmccabe does exactly that.
The primary way to reduce complexity is of course to split up huge functions
into multiple sub functions. The challenge is to do it sensibly.
Right now, the top-10 most complex functions in production code according to
this tool are (score, filename, line number, function name):
196 src/tool_operate.c(870): config2setopts
150 lib/vssh/libssh2.c(1639): ssh_statemachine
142 src/tool_getparam.c(1677): getparameter
124 src/tool_operate.c(1785): single_transfer
112 lib/ftplistparser.c(366): Curl_ftp_parselist
110 lib/setopt.c(258): setopt_long
103 lib/formdata.c(205): FormAdd
100 lib/vssh/libssh.c(1081): myssh_statemach_act
100 lib/mprintf.c(639): formatf
99 src/tool_operate.c(437): post_per_transfer
Anyway. I plan to have this as a goal of mine to fiddle with over the year
going forward.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-05-14