[Tutor] this group and one liners

[dn]

On 08/07/2022 10.59, Alan Gauld via Tutor wrote:
> On 07/07/2022 16:38, Mats Wichmann wrote:
> 
>> background was in languages that didn't have these, I now use simple
>> one-liners extensively - comprehensions and ternary expressions.  
> 
> Let me clarify. When I'm talking about one-liners I mean the practice
> of putting multiple language expressions into a single line. I don't
> include language features like comprehensions, generators or ternary
> operators. These are all valid language features.

+1


> But when a comprehension is used for its sidfe effects, or
> ternary operators are used with multiple comprehensions and
> so on, that's when it becomes a problem. Maintenance is the
> most expensive part of any piece of long lived softrware,
> making maintenance cheap is the responsibility of any programmer.
> Complex one-liners are the antithesis of cheap. But use of
> regular idiomatic expressions are fine.

+1


> It's also worth noting that comprehensions can be written
> on multiple lines too, although that still loses debug
> potential...
> 
>  var = [expr
>         for item in seq
>         if condition]
> 
> So if you do have to use more complex expressions or conditions
> you can at least make them more readable.

Many texts introduce comprehensions with comments like "shorter" and
"more efficient".

In this example, the comprehension will run at C-speed, whereas the
long-form for-loop will run at interpreter-speed. Thus, one definition
of "efficient".

Yes, it would *appear* shorter if written on a single line. However, is
not, when formatted for reading. Here's the long-form:

seq = list()
for item in seq:
    if condition:
        var = expr

NB I have a muscle-memory that inserts a blank-line before (and after) a
for-loop (for readability). However, in this example, the 'declaration'
of the seq[ence] would become physically/vertically-separated from the
loop which has the sole purpose of initialising same. Negative readability!

Also, my IDE will prefer to format a multi-line comprehension such as
this, by placing the last square-bracket on the following line (and
probably inserting a line-break after the opening bracket). Accordingly,
there is no 'shorter' because the 'length' of each alternative becomes
exactly the same, or the comprehension is 'longer' (counting as 'lines
of code')!


> The same applies to regex. They can be cryptic or readable. If
> they must be complex (and sometimes they must) they can be built
> up in stages with each group clearly commented.

+1
I've seen people tying themselves in knots to explain a complex RegEx.
Even to the point of trying to fit each 'operation' on its own line,
followed by a # explanation.


>> My take on these is you can write a more compact function this way -
>> you're more likely to have the meat of what's going on right there
>> together in a few lines, rather than building mountain ranges of
>> indentation
> 
> True to an extent, although recent studies suggest that functions can be
> up to 100 lines long before they become hard to maintain (they used to
> say 25!) But if we are getting to 4 or more levels of indentation its
> usually a sign that some refactoring needs to be done.

Didn't we used to say ~60 lines - the number of lines on a page of
green-striped, continuous, line-flo[w], stationery?

Those were the days!


>> anyone in a position to maintain my code at a later date) should have no
>> trouble recognizing the intent of simple ones.
> 
> That's true, although in many organisations the maintence team is the
> first assignment for new recruits. So they may have limited experience.
> But that usually affects their ability to deal with lots of code rather
> than the code within a single function. (And it's to learn that skill
> that they get assigned to maintenance first! - Along with learning the
> house style, if such exists) Of course, much software maintenance is now
> off-shored rather than kept in-house and the issue there is that the
> cheapest programmers are used and these also tend to be the least
> experienced or those with "limited career prospects" - aka old or mediocre.

OK, so now we're not just observing the grey in my beard?

Doesn't the root meaning of mediocrity come from observations of how
standards in professional journalism are steadily and markedly declining?


Jokes(?) aside, the observation is all-too correct though. Thus, the
added-virtue of providing tests alongside any code - or code not being
'complete' unless there is also a related test suite.

The problem is that many maintenance-fixes are performed under
time-pressure. Worst case: the company is at a standstill until you find
this bug...

The contention then, is that these 'learners-of-their-trade' should be
given *more* time. Time to look-up the docs and the reference books, to
see how various constructs work, eg list comprehensions. Time to learn!


Although when off-shoring, one is (imagines that you are) paying for
competence. So, the above scenario should not exist...

Oops!


>> Sometimes thinking about how to write a concise one-liner exposes a
>> failure to have thought through what you're doing completely
> 
> That's true too and many pieces of good quality code start of as
> one-liners. But in the interests of maintenance should be deconstructed
> and/or refactored once the solution is understood. Good engineering
> is all about cost reduction, so reducing maintenance cost is the
> primary objective of good software engineering because maintenance
> is by far the biggest cost of most software projects.

+1
Sadly an observation that is seldom experienced by students and
hobbyists, and only becomes apparent - indeed relevant - when the
complexity of one's projects increases.

Such (only) 'in your own head' behavior is philosophically-discouraged
in the practice of TDD. (just sayin'...)

-- 
Regards,
=dn