>>106200675
>oftentimes you want a wrapper around your internals to package the spaghetti
why would you "package the spaghetti" in the first place? it does not make any sense
>in extended C you can force inline so this comes at zero runtime costs. pure syntactical sugar
wrong, inline does not always work as you would expect as it's just a hint to the compiler.
>>106200728
>but this is the kind of shit you might want to hide behind an interface for legibility and maintenance sake
no you don't, wtf. linus explained why and he is 100% right, read his message again, alos hiding stuff is always a bad reason to extract code into a function or another file, that's yet another reading indirection and add complexity to the mental model of the code.
10 000 lines functions are perfectly fine for this exact reason, code flow is very important and has 0 negative impact (in fact quite the opposite as no inline guessing required) on the generated machine code.
>also duplicate code is always bad.
this is absolutely wrong, why do you have opinions on things when you're clearly a student or an actual nocoder?
duplicating code is very fine and dramatically simplify the code sometimes and more importantly remove ambiguities and allow similar code to diverge with time.
good code is code you can remove easily, your fucntion has a very high chance to see its prototype changes wtih time, taht's a maintainance nightmare introduced for no fucking reason, it's especially true the closer to the machine you are like in these patches.
>yes you can use refactoring tools but even if youre nigh-certain you wont make a mistake, the probability is never 0
don't rely on these things.
why do you reason in absolutes? code duplication is good or bad depending on context, same for obfuscating (yes that's what functions do) code inside functions or macros
