|
Re^3: why not listed foreach and if?
by GrandFather (Saint) on Jun 17, 2024 at 23:31 UTC
|
Because for readability and thus understandability and maintainability the important stuff should come first. A trailing if that determines if anything is performed at all makes the code much harder to understand because when you reach the if you have to revise your entire mental model of the statement to that point.
Somewhat like the infamous instructions for disarming a bomb:
- ...
- Cut the blue wire
- But first cut the red wire
- ...
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply] |
|
|
When it comes to my codebase, the main result of unreadable code is that i would refuse to merge a coworkers change into the main branch and send them back to their desks. With a long todo list on what to fix in their code.
It's important to understand that i don't shout. Looking sad and slightly shaking my head in disappointment seems to be way more effective when it comes to improving code quality, especially when they come back with still unreadable code. This seldomly fails, my coworkers know the next step up is the dreaded re-run of my one-hour "how to write maintainable code" eye-to-eye lecture while they sit at my desk, watching me refactor their code, commenting on every single mistake and showing how its done correctly.
It sounds harsh, but it isn't. It's never "you are too stupid to do this right". It's always "You need to learn how to do this to my coding standards. We pay you for it, so take the time and do it. And this is how it's done: ..." (And yes, if a coworker has a good argument on why his way of doing something is the better way, i am not above spending a weekend or two to adapt my whole codebase to the new way of doing things).
| [reply] |
|
|
It's important to understand that i don't shout. Looking sad and slightly shaking my head in disappointment seems to be way more effective...
I'm feeling a bit uneasy about what appears to be your dictatorial approach.
For background on where I'm coming from, please take a look at:
- Psychological Safety (a belief that you will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes)
- Working Solo and in a Team (Google gTeams study - tips on how to create harmonious, high performing teams)
- Five Whys (the purpose of Five Whys isn't to place blame, but to uncover the root cause of a problem)
I'm curious how you would rate your teammates in each of
the five keys to a successful team, identified in the Google gTeams study:
- Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
- Dependability: Can we count on each other to do high quality work on time?
- Structure & clarity: Are goals, roles, and execution plans on our team clear? Do we have an effective decision-making process?
- Meaning of work: Are we working on something that is personally important for each of us?
- Impact of work: Do we fundamentally believe that the work we're doing matters?
References Added Later
Updated: Added Five Whys link and descriptions of the three primary bullet points. Minor changes to wording.
| [reply] |
|
|
You are making working with you sound like a nightmare (browbeating, emotional manipulativeness). Perhaps that's not the case.
| [reply] |
Re^3: why not listed foreach and if?
by syphilis (Archbishop) on Jun 17, 2024 at 23:50 UTC
|
why the restriction?
It's just that perl's parsing does not handle these types of constructs.
It interprets:
foreach @a if $a
as
foreach(@a if $a)
foreach takes a list as its argument, and I guess perl just doesn't see (@a if $a) as being a valid list.
You know what you mean, and I know what you mean, but perl doesn't.
I don't know exactly why perl doesn't understand these constructs ... but I suspect there are good reasons.
Cheers,
Rob
| [reply]
[d/l]
[select] |
|
|
I'm also not sure why perl doesn't understand them. I suspect they must lead to parsing ambiguities - that usually seems to be the reason for such restrictions.
In any case, Perl does not have a history of disallowing things on the grounds of "readability" (that seems much more Python's style). What a person finds readable is very much determined by what they are used to, there really is no single perfect style.
Around 25 years ago I was working at Elsevier in Amsterdam, and once had a very heated discussion with the project lead when in code review he wanted to turn my mix of loops and map/grep pipelines (carefully curated so that no single construct was overly complex) into a single much more complex map/grep pipeline that to me seemed totally illegible. My line manager eventually explained that the lead had a functional programming background, and that I should look at the proposed change in that light. It took me a while, but eventually I got my head around it, and I'm now much more comfortable with that style (and find it perfectly legible when done right).
| [reply] |
|
|
Perl does not have a history of disallowing things on the grounds of "readability"
Yeah, so it's odd that it's done here. But that was the reason given by Larry Wall (as I remember things).
I suspect they must lead to parsing ambiguities
Well yeah. Is X MODA Y MODB Z equiv to ( X MODA Y ) MODB Z or X MODA ( Y MODB Z )? But that the same applies to every binary operator. These ambiguities are resolved using associativity and precedence.
| [reply]
[d/l]
[select] |
|
|
Hi,
How you know that perl interprets as foreach(@a if $A) but not (foreach @a) if $A?
I see any of constructs if/for/while can be written inside of parentheses, e.g. a simple ($A if $A) is a syntax error.
'and' and 'if' internally, as I understand, branch equivalently, only the direction differs. And the result of 'if' becomes not an expression, when the result of 'and' becomes an expression.
| [reply]
[d/l]
[select] |
Re^3: why not listed foreach and if?
by ikegami (Patriarch) on Jun 18, 2024 at 13:19 UTC
|
perl feed subs from right to left,
I don't know what that means? Both sub definitions and sub calls read from left to right.
Perl do checks if tail-loaded,
No, that's not the case for either the do function or the do block. Both start with do. They read from left to right.
Are you talking about do ... if ...;, do ... for ...; and , do ... while ...;? Those are just statement modifiers on a expression. No different than next if ...;, etc.
And again, you keep giving examples that defy your point. do ... while ...; is rarely used, I've never seen the others used, and I actively avoid them all.
| [reply]
[d/l]
[select] |
|
|
"perl feed subs from right to left"
refers code like
print join ':', sort qw( b g a)
as haskell '$' do;
I do not like 'do {...}' at all, I wish perl accept more structures when if tailed. | [reply]
[d/l] |
|
|
In open source, if you want something, the best way to get it is to write it yourself, especially if the idea doesn't seem to get much interest in others.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply]
[d/l] |
|
|
|
|
|
|
| [reply]
[d/l]
[select] |