[Tutor] Fwd: Re: How to refactor a simple, straightforward script into a "proper" program?

[DL Neil]

On 6/01/20 1:30 PM, Alan Gauld via Tutor wrote:
> On 05/01/2020 05:40, boB Stepp wrote:

>> presented in the "simple" script.  I have quickly looked over D. L.
>> Neil's comments, and, combined with yours, wonder if I should redesign
>> the whole shebang from the ground up?  Maybe this problem does need an
>> OO approach.
> 
> You shouldn't need an OO approach for something this small.

You're just baiting me, right?

Which comes first: the chicken or the egg? the data-objects or the 
algorithm? (Alan and I will argue this, just for fun...)


On a personal note, I usually find that organising the data - the 
"entities" involved in a problem, is the?my best way of understanding 
the problem and peeling-back the onion-skin process of moderating one 
large 'problem' into a number of smaller, and more easily-solved 
challenges. YMMV!

Accordingly, I keep separate the process of gathering input, from the 
calculation, from the niceties of presentation...

As the divided-problems become single tasks, the can be implemented as 
Python methods/functions without much thought.

Surely it is also much easier, at this single-task level, to analyse 
what might 'go wrong', and to test or to code precautions accordingly?

In the case of the input, once the 'problem' of collecting one integer 
value from the user has been 'solved', it also becomes possible to see 
how that routine could be re-used to collect the other integer value(s)...
(thus addressing the single-use/re-use discussion, below)


> But you do need a bit of a rethink in tems of splitting out the
> functions cleanly. And exactly what is published API and what
> is just internal utility code.

+1


>> I grudgingly concede your point.  Grudgingly because now I have to
>> figure out how to accomplish this.  ~(:>))
> 
> I think exceptions are the way to go.

+1
Have a function return ONE data-type/meaning, and only one! Thus if the 
function is to collect a (valid) integer from user-input, return that 
integer. If it ALSO is to interpret a null-entry or perhaps a 
negative-number as a "sentinel value" to cease execution, then code that 
condition to raise an Exception.
(in Python exceptions are not necessarily "errors"!)


>> But I thought the great preference was for function and method names
>> to be verbs not nouns?
> 
> Hmmm, yes. OK I'll give you that one :-)

I wasn't going to raise this unexpected utterance - thinking myself too 
polite.

(oh forget it - who am I trying to convince?)...


>>> Would you really say page if it was 0.5 pages per day?
>>
>> Actually, yes.  Just as I would say a half page per day.  OTOH, I
>> would say zero pages per day.  Maybe I need to dust off a grammar
>> book...
> 
> a half page is not the same as 0,5 pages.
> The a forces it to single. So in your code you need to add
> an 'a' before the value to make it grammatical.
> Thats more work, but doable, but what would you say
> for a value like 0.82? What kind of fraction is that?
> Are you going to convert it to say
> 
> a 82 hundredth of a page?
> 
> Good luck with that...

We used to spend quite a bit of time and effort worrying about correct 
grammar. However, these days, such politesse seems more honored in the 
breach, than the observance!


>>> I'd only use 'page' if it was exactly 1.
>>>
>>> But since its a float you need to use an epsilon value.

The points about floating-point's lack of accuracy in using binary to 
portray decimal values is worth noting. Few bother to teach/learn 
numerical analysis these days!

That said, as someone who often has to 'budget' reading (either to 
finish, or to limit myself in order to 'do' things), I already 'round' 
my calculations. Thus, if I have five days before a book is due back to 
the library, a similar calculation galvanises/motivates me to read (say) 
at least three chapters per day. Pages/day would be a more precise 
measure but may not fit with the material! Sections of chapters? Also, 
if I end-up with only one chapter to read (remainder to integer 
division!) then that's a 'bonus' or even an additional measure of 
success - I don't complain about having worked 'too hard' during 
previous days.

What might the added precision of page-fractions add - in the user's mind?


>> I originally in my code did not use mixed quotes.  But when I saved
>> the file my new code formatting tyrant, Black, changed my consistent
>> quoting style to mixed quotes.  Apparently it insists on all double
>> quotes unless there are embedded quotes within when it converts those
>> to single quotes.
> 
> Yukkkk!

"Tyrant". Tools that are not your friends are what? Things growing in my 
garden which will not end-up 'in the pot' or on my table are called what?

Yes, recommend using 'advisory' linters - you may then choose what to 
learn, when! and why!


>>> 2) if a function isn't generally reusable make it obvious
>>>     by putting an underscore in front of the name. (or
>>>     make it generally reusable...usually much harder :-)
>>
>> This is where I was hoping for some concrete, helpful examples.  I do
>> indeed find this "much harder".
> 
> Everyone does. Management routinely ask devs to create reusable code,
> but studies show that writing reusable code is from 3-5 times more
> expensive than writing single-use code. Some studies say more like 10
> times if you factor in maintenance costs too.
> 
> And there is no easy answer, it takes painful lessons and
> experience, and you'll still mess it up!

YAGNI applies!

NB OOP is not (necessarily) "reusable", nor does "reusable" imply OOP!

Tested/testable code, over 'it seems to work', *every* time!


Conversely to the above, management equally-routinely take stuff which 
we were initially told would only be used once or for a short period, 
and re-define those words to mean 'every day' and/or for decades...

Elsewhere I threw in my 2c/2.5p ("tuppence ha'penny" in £old-money) 
about "tests"...

If the code has been written so that its intent and method are clear, 
then faced with the need, 'single-use' code could be re-worked and 
generalised into reusable code. Whereas a 'mess' might work for 
single-use, but is rapidly rated as 'disposable' should the situation 
'develop'!

Important message: you can't win!
(but what made you think you could???)


>>> 3) separate presentation and logic.
>> Again, I find this not so easy.
> This is easier and just takes a little practice to get used to it.
> Basically every function should either do display or logic. If its
> doing logic then return values that the caller can use/display.

+1
See also, "Separation of Concerns"

answer = process( validated_input, validated_input, ... )
report( answer )


>> FEATURE CREEP!  Actually sounds like an interesting addition.  But I
>> don't much like eReaders myself.
> 
> I didn't used to but, on holiday, I save a ton of weight by taking a
> Kindle. And having got used to them I now occasionally even read
> tech books on it. Although code formatting often gets messed up.
> But I'm currently reading a book on curses programming in C and
> converting it to python - maybe to become a page in my tutor
> someday - and that's a Kindle book.

I prefer a book. Recent studies have show that, given a choice of 
text-presentations, the majority of even today's, screen-native, 
tertiary-students will choose a book over an eBook.

I live in a country famed for its bright sunlight* (I can never believe 
the difference between here and London or Washington, for example). 
Accordingly, it can be very difficult to read iPads, portable computer 
screens, smart-phones, etc. However, a Kindle works with reflective light!
* and the highest rates of skin-cancers, which just goes to show: life's 
a beach, and then you...
-- 
Regards =dn