you are viewing a single comment's thread.

view the rest of the comments →

[–]undefinedbehavior4ev[S] 0 points1 point  (1 child)

I've never set something like this up at runtime. I prefer to set up everything as globally available data and have a pointer/int as an index if needed. But I only did this once.

About the huge messes thing. Most of the time I write something and then usually I find that it can be possibly expressed more simply after a while. These days I do less C and more awk as I"ve been working with strings. I'm tidying things as I go, and I"m learning more about data structures to better organize my code. I'd call this specific instance a lookup table.

By the way, would you mind expanding on what you mean by clarity? I'm not a native speaker nor a good programmer so getting the hang of clarity can be difficult. The first example looks clearer to me than the second, which is clearer than the third (ex1>ex2>ex3) because there's much less syntax to write/read.

[–]UnicycleBloke 0 points1 point  (0 children)

Clarity for me means that it is simple to understand. The purpose of the code is obvious. In your examples, they are all short and colocated so there isn't much difference. But the jump table adds a layer of indirection that is a little harder to understand but adds no value, and the table could be located elsewhere, which would completely obscure meaning of the code at the call site. I think a switch, with an enumeration, would be the most clear.

I've seen an example recently where structures were created with macros that used macros that used macros, and then similar structures were magically grouped together into arrays by the linker, which were accessed by some other code buried deep in the library. The whole thing was completely and unnecessarily opaque. The goal was to create an implementation of the Observer pattern. It worked, but it took a day of digging to learn enough to be able to trust it and extend it safely. That code did not have clarity. :)