Re: Top 10 most common hard skills listed on resumes...

On 08.09.2024 23:01, Bart wrote:

On 08/09/2024 19:13, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

 

Like being able define anonymous structs always anywhere, or allowing
multiple declarations of the same module-level variables and functions.

>
Look at this C code:
>
[ snip code ]

(Quite an unreadable mess. Needs character-wise code-inspection
to be sure it does what is intended. And needs a description in
the first place to be able to analyze it and make sure that it
works as intended.)

>
I claim that is is better than what could be done in early Pascal.

Have you tried? (It's not straightforward if you're approaching
it from the low level.) In Pascal I'd start with the data type I
intend to process, define an integral type. Implement bit-shifts
etc. in terms of simple operations (like 'div' and 'mod'). Then
identify the functional building blocks for the operations. Etc.

Temporary variables are declared exactly in scopes where they are
needed, I reuse the same name for 'pp' but scoping makes clear
that different 'pp' are different variables.  All variables
are initialised at declaration time with sensible values.  Only
parameters, 'i' and 'c' are common to various stages, they have
to.  Note that 'xext' and 'yext' are declared at point where I
can compute initial value.  Also note that among ordinary
variables only 'i' and 'c' are reassigned (I need to swap parameters
to simplify logic and 'dst' array entries are assigned as part of
function contract).  Fact that variables are not reassigned could
be made clearer by declaring them as 'const'.

I had a problem with this code because it was so verbose. [...]

My first impetus was as well to start refactoring that "C" code.
But I noticed that it's IMO not a sensible example to demonstrate
HLLs in the first place! The code is full of low-level stuff where
you need, for example, to consider lengths of various word types,
use of tons of casts, bit-operations, and whatnot. The temporary
variables, at least, is not what makes this code more legible in
any way. It's also arguable whether it makes sense to introduce
temporaries to swap variables; instead of adding to legibility
by hiding that in a 'swap' function (with the temporary then not
littering the name-space of the already overloaded function block).
And so on.

[ snip try of a refactoring ]

Janis