daniel:// stenberg://

3 months ago

daniel:// stenberg://
3 months ago

Decomplexification - making #curl use simpler code

daniel.haxx.se/blog/2025/05/29…

Decomplexification

(Clearly a much better word than simplification.) I believe we generally accept the truth that we should write simple and easy to read code in order to make it harder to create bugs and cause security problems.

^{daniel.haxx.se}

#curl

in reply to daniel:// stenberg://

Mathias Hasselmann

in reply to daniel:// stenberg:// 3 months ago

Awesome idea! Awesome dashboard! These dashboard scripts might deserve a project on its own as it would be awesome to see them widely used.

in reply to Mathias Hasselmann

daniel:// stenberg://

in reply to Mathias Hasselmann 3 months ago

@taschenorakel there has been some initial work in generalizing the scripts so that's something that might happen: github.com/curl/stats/pull/16

Generalize for any repo by jericson · Pull Request #16 · curl/stats

I love the curl dashboard and I want to use some of the stats for other projects. I forked this repository and started generalizing the scripts. For instance, github-cache.pl grabs a copy of issues...

^GitHub

@Mathias Hasselmann

in reply to daniel:// stenberg://

William Salmon

in reply to daniel:// stenberg:// 3 months ago

I don't want to come over too critical as I have a huge amount of appreciation and respect for you & curl.
That said I have found that while having complexity in code is bad, it's also hard to reduce and one way that some people try to reduce it is to "hide" it across many simple looking functions.
I once got my pen and paper out and found that to get from one function at the high level to the low level equivalent the path was through 5 lays of inheritance and 3 different branches

This entry was edited (3 months ago)

in reply to William Salmon

William Salmon

in reply to William Salmon 3 months ago

do you have a strategy for helping avoid such pitfalls these sorts of metrics some times encourage?

in reply to William Salmon

daniel:// stenberg://

in reply to William Salmon 3 months ago

@pointswaves we don't have any specific checks for that, but all our changes are reviewed and we write code to be readable and maintainable. I consider the risk that someone would go overboard in the other direction to be slim.

@William Salmon

in reply to daniel:// stenberg://

poleguy looking for lost tools

in reply to daniel:// stenberg:// 3 months ago

@pointswaves I also had the experience of a developer breaking a long function into four or so shorter functions that called each other in sequence. I'm sure you don't have a high risk of this.
My insight from that experience is that what really matters is that the complexity of the code is as low as possible considering the complexity of the problem. But the complexity metrics do not consider the problem complexity. I would rather see all the code for a complex problem in one place.

@William Salmon