Possibly the final contribution:-
On 9/02/19 1:30 AM, Adriaan Renting wrote:
Wow, you dug deep.
=Thank you. It started to 'bug' me, so I really was 'scratching an itch'!
My example was the reverse of the "toy example"'s you mention as I find
that often code becomes much clearer if you order it such that
specific cases, sanity checking and exceptions go first, and then the
default case at the end.
=we have also had this discussion during code reviews. Do you think that
choice/code sequence/prioritisation is related to one's facility with TDD?
(some might claim it is to do with experience and/or professionalism)
=My observation is that the TDD-people tend to do it 'your way', but
those who 'first get it working' and then 'go looking for potential
trouble' do the action-first, and exceptions-later.
=presumption: that the TDD people have thought more about definitions of
'working' and 'failing' and like to implement all the 'fails' (get them
'out of the way') in order to leave the 'pure' solution.
(no, let's not disappear too deeply down another 'rabbit hole'!)
So my general suggestion would be to handle your empty list/no valid
candidates cases first,
and then do the for loop at the end.
If you style this with if/elif/else, or put return statements in
certain places, I have no opinion about and will depend on the specific
problem.
...
=I offered the three ideas to the original coder of the actual application:-
Today, kicking ideas around, I coded three other possible 'solutions'
for the review team's discussions:
One of these involves coding three functions: the decision (yielding
a
boolean), the expected-case, and the unusual-case. The satisfaction
in
this was readability factors with a simple if statement..
Somewhat more complex, and I feel a bit OTT, was to sub-class list()
and
write a method which would indicate an empty list, plus include much
of
both the expected-case and the empty-list methods therein. Somehow
"class ListShouldNotBeEmpty" doesn't seem a catchy (if descriptive)
title - however, it works! The decision 'function' could also/then be
made @property and (perhaps) thus contribute to readability.
Lastly, I 'remembered' conditional expressions. Thus, furthering the
idea of two/three functions:
process_list() if list_has_contents() \
else process_empty_list()
=she has grabbed the class construct and started to 'run with it'. At
first I feared that I had 'created a monster'. However, once she'd
improved my outline all manner of other code was filling-in the class.
It turns-out that the zero-data consideration was not the only way in
which this data/list varies from the standard. So, she is now monitoring
how many entries are expected on the list, cf how many have been
captured, and is planning to evaluate them with a sort & key=.
=Thus my solution, to sub-class from list and (only) modify
__getitem__(), ie the "lazy" approach, has been changed to monitor the
creation of the list. She no longer uses anything obvious such as len()
but is keeping track with several booleans:
1 that there is actually some data,
2 how many elements are in the list,
3 how many elements are required for the application.
(perhaps someone who favored semaphores is going to say "ahah!"?)
=Using the 'toy' example of the film Oscar awards:
1. is exactly as discussed 'here'
2. the traditional use of len()
3. only the top four nominees are mentioned (thus the sort, enables a
'cursor' featuring only the first four elements), before moving into the
grand "and the winner is..." (the film receiving the most votes ie
element[ 0 ] )
=Am almost looking forward to the follow-up code review...
Many thanks (to all) for contributing ideas and advice!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
