Programming Leftovers
-
AWK Delimiters - Invidious
awk is a great tool that can help with all sorts of parsing, processing and summarizing cleartext data.
-
How to categorize C programs by behavior | Red Hat Developer
Most of us who write C and C++ code intuitively understand why some programs might behave differently when compiled with different compilers or different compiler options, or when running under particular conditions. We're also aware of the dangers of undefined behavior and usually try to avoid it in our code. But not all of us appreciate the many useful (and often unavoidable) aspects of undefined behavior. This article explains the kinds of behavior the C standard uses to categorize programs and their subtle, sometimes unexpected, impacts on compilers, libraries, other standards, and programmers themselves.
Programmers are rarely familiar with the subtle nuances of undefined behavior. Nor do programmers pay as close attention to the other kinds of behavior that C programs are subject to, or when that behavior might occur. In our discussions, we often use terms like "valid code" or "correct program" without having a shared understanding of their meanings.
I'm sometimes surprised that not even expert programmers, including C committee members, always agree on what the terms mean. Some don't know why the basic categorizations of program behavior were introduced into C in the first place, or their purpose.
-
LLMs for Code
I've always found training models on code to be interesting – there's large amounts of structured data and text is a fairly simple input/output interface that can be automatically be checked for syntax correctness.
-
80/20 Refactoring | [bobulate]
I have found a new bugbear. Something to be creatively annoyed about. I’m going to call it 80/20 refactoring, to express the idea that a refactoring is started, but then not finished. Probably because doing all of the edge cases in a refactoring is hard.
-
Nibble Stew: If you don't tolerate it in new code you should not tolerate it in old code either
Let's assume that you are working on a code base and notice that it has some minor issue. For argument's sake we'll say that it has some self written functionality and that the language's standard library has added identical functionality recently. Let's further assume that that said implementation behaves exactly the same as the self written one. At this point you might decide to clean up the code base, make it use the stdlib implementation and delete the custom code. This seems like a nice cleanup so you then file merge request to get the thing changed.
[...]
Getting blocked like this is a bit unfortunate, but these things happen. The important thing, however, is that all these are solid technical reason for not doing the cleanup (or at least not do it immediately). Things get bad when you get blocked by some other reason, such by your reviewer asking "why are you even doing this at all". This is a reasonable question, so let's examine it in detail.
Suppose that instead of submitting a cleanup commit you are instead submitting a piece of completely new functionality. In this MR you have chosen to reimplement a piece of standard library code (for no actual gain, just because you were not aware of its existence). The review comment that you should get is "You are reimplementing stdlib functionality, delete that code here and use the standard library instead". This is a valid review comment and something that should be heeded.
The weird thing here is that this is in a way the exact same change, but it is either not acceptable or absolutely necessary depending on whether parts of the code are already inside your repo or not. This is weird and should not be the case, but human beings are strangely irrational and their "value functions" are highly asymmetric. This can lead to lots of review fighting if one person really wants to fix the issue whereas some other one does not see the value in it. The only real solution is to have a policy on this, specifically that submitting a change that fixes an issue that would be unacceptable in new code is, by itself, a sufficient reason to do the work but not to merge it without technical review. This shifts the discussion from "should this be done at all" to "what are the technical risks and merits of this change", which is the way reviews should be done.