Completing C code with D style

[Ali Çehreli]

On 11/11/21 11:34 AM, Stanislav Blinov wrote:

 > Pessimization, though, is laughably easy, and
 > should be avoided at all costs.

I am not passionate about this topic at all and I am here mostly because 
I have fun in this forum. So, I am fine in general.

However, I don't agree that pessimization should be avoided at all 
costs. I like D because it allows me to be as sloppy as I want to fix my 
code later on when it really matters.

 > Not caring about *that* is just bad engineering.

There wasn't a problem statement with the original code. So, we 
understood and valued it according to our past experiences. For example, 
most of us assumed the program was about 10 integers but I am pretty 
sure that array was just an example and the program was meant to deal 
with larger number of arrays.

Another example is, you seem to value performance over maintainability 
because you chose to separate the selection letters without getting any 
programmatic help from any tool:

   write("Would you like in list (e=evens, o=odds, b=both)? ");
   readf(" %c", &even);

   if ((negativity == 'b') && (even == 'b'))

For example, the 'b's in that last line may be left behind unmodified if 
someone changes the help text alone. Someone may find that kind of 
coding "bad engineering" that shoul be avoided at all cost. (Not to 
defend myself but my associative array was exactly because I could not 
bring myself to separate those selection letters from the help text. I 
simply could not show unmaintainable code to a beginner.)

I don't think there is much more to see here: A simple C program, 
liberties taken for fun in D, pessimization is bad, unmaintainability is 
bad, yes.

Ali