Goal: reduce overall function complexity
Daniel Stenberg via curl-library <[email protected]>
| Newsgroups | gmane.comp.web.curl.library |
|---|---|
| Message-ID | <[email protected]> |
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.html