[Tutor] this group and one liners

[Alan Gauld]

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.

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.

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.

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.

> 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.

> 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.

> 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.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos