you'll see that the suggestions made by Radiolistener do make sense
That is a very generous interpretation from words like "However, it is important to understand that by [using goto], you are introducing poor quality shitty-code, and you should be aware of the potential consequences that may arise from it."
That, and its numerous repetitions using slightly different wording, is what I object. As useful as some of Radiolistener's posts are to learners, I am seriously unhappy about how they utterly reject any rational criticisms of their opinions stated as facts. I am unhappy,
because it leads others astray. The opinion itself is based on a logical fallacy –– that all uses of
goto leads to "poor quality shitty-code" ––, as provably true and easier to maintain patterns with lower occurrence of bugs have already been shown and explained. You can disagree however much you want, but that is an observable fact. Just because you insist on calling the sky yellow doesn't make it so.
And telling someone not very experienced in C to
avoid preprocessor macros is just sheer stupidity. They are a very useful tool that when correctly used, makes project maintenance much easier. Before C23, the only actual constants there are are literal constants and preprocessor macros (that preprocess to literal constants), for fucks sake!
const does not declare a constant; it is simply a promise by the programmer to the compiler that the code will not try to modify this variable in the current scope, that's all. And if you want to do polymorphism (using e.g. C11
_Generic), like say
signbit(x), you
have to use preprocessor macros.
Claiming absolute rules like that apply is idiotic and counter to observable reality, and shows that the person hasn't had sufficient experience in diverse software projects, because otherwise they'd know from experience such rules always have their exceptions. Doubling down, and not admitting it, is obnoxious social gaming that I detest, and is why I called radiolistener full of shit.
I compared the Linux kernel to other similar
enterprise projects. At the rate it is developed –– so rapid that even the largest companies have trouble keeping up –– its bug density is lower than in any enterprise projects I've seen.
The code you have in projects complying with MISRA-C or DO178B is not so because it is better written from the get go: it is so because it has gone through a rigorous review, test, and verification cycles. Those standards are not
coding standards, they are development process standards.
For minimal bug density C code, I did tell you to go look at Dan J. Bernstein's C code; and 5U4GB added Wietse Venema.
This thread went to shit the moment radiolistener told metertech58761 to not use
goto and preprocessor macros. It was just utter shit advice, stemming from misunderstanding process-based choices as axiomatic universal truths. The "bad example" in #13 is just laughable: the exact same pattern is extremely useful if you just rename the macro from
true to say
enable_print.
Instead, we should have told metertech58761 and others reading the thread trying to convert assembly to C without that much experience in C that this intermediate form is not maintainable in long term, and needs to be refactored or rewritten to a more maintainable form without changing the functionality. In fact, that was exactly what metertech58761 was asking: how to go on from here.
All of the patterns shown in the assembly code can be converted to easily maintained
while or
do..while loops and inlineable/
static sub-functions. (In C, "
static" and "
static inline" have the exact same effect on a function: it will only be accessible from the current compilation unit (typically current
.c source file), and the compiler is free to inline the function to its caller, and not generate a callable function for it at all. I use the distinction to help us humans distinguish between
internal functions and
accessor/helper functions.)
Instead of
what not to do, radiolistener and others should have suggested
what to do instead. And that applies to you too, Picuino: instead of claiming "
X is harmful", you should show that "
Y is better than X, because Z".
This is a technical discussion. Telling others "don't do that!" is useless –– no,
trolling! –– when better alternatives are not shown.
I have now repeatedly tried to show better patterns, to no avail. In
#100, I recap the timeline. In
#110, I tried to go back to the interesting stuff, although I was still a bit too emotionally invested to have much thought in the patterns themselves; with
#123 showing a better one (splitting the Repeat/Next into a separate function, then combining the rest of the loops into while loops and subfunction calls). No bites. You guys are more interested in nitpicking on what degree of "goto" and preprocessor macros in C can be considered "harmful", than actually looking at the actual code. Nctnico claims to have decades of Linux kernel experience, but still complains how hard it is to fix things with it, especially because things change –– I bet they find the lack of stable internal APIs also a sign of "low quality code", even though the actual reasons are well known. I've done similar work, even just to help other members here, and I just don't find it difficult to work with the Linux kernel code. Perhaps it is because I've worked with all sorts of stuff, and not just regimented centrally-controlled codebases, so I've learned to understand better? In any case, I just cannot take such complaints seriously, because they rationally simplify to "the code is horrible, because any modification I make causes bugs", which is not an indication of the code per se, but one of the programmer at hand.
I keep telling you, making arguments from authority –– be it your work experience or whatever else –– just does not cut it. You need to show the actual better patterns, instead of claim they exist, or worse, just tell others to avoid some patterns without suggesting any replacements. It is not just silly, it makes it very difficult for learners to discern which suggestions to follow. Essentially, you're shittifying the entire thread with your crap.
Stop it. Do like I've done, and suggest something better instead.
Home
Help
Search
Login
Register
