Loop with else clause

[DL Neil]

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