[Tutor] Feedback on coding style

[dn]

On 27/06/2022 12.12, Leam Hall wrote:
> No apologies needed! Your input is habitually useful and welcome.
> 
> It has taken me years, literally (I'm a bit slow), to figure out my

This is not at all unusual. The phenomenon experienced (largely
unknowingly) by most of us, is that we start in a course (which only
requires short coding examples, and it is only sometime later that we
realise the virtue of some of this 'other stuff', like "style", after
we've some miles under our belts and the size of our tasks has increased
(markedly), 'complexity' has raised its ugly head...
(see also 'structure', 'objects', 'testing', ...)


> coding style. While Python is adept in a lot of markets, I'm more of a
> tools person than an application programmer. My best work is usually to
> write something, make sure it's documented, train the gaining team on
> how it works, and then hand it off. In that environment, third-party
> libraries, venvs, and external application overhead (like MongoDB) don't
> really fit well. Plan text rules, and there's little reason for complex
> features.

IMHO the opposite applies! The tools I build are used by trainers and
educators. There is no such thing as 'one size fits all', and we are
constantly innovating. A tool is discarded/replaced before anyone says
"it's done"!

Accordingly, a need to keep things tidy and 'professional'. Admittedly
one reason is that someone else might pick-up the tool and code the
extension - so the more 'help' they have, the better our team will perform.
(see also earlier wisdom (not mine) about "habits"...)

This is also a very good argument for SCM. Whilst it might seem like an
"overhead" (and yes, there is bound to be some learning to do), it adds
extra layers of flexibility (as well as coping with version-numbering
for you). For example, your first version involved a flat-file; then
someone else came-along and suggested SQLite. What if you had delivered
the first version to some 'client' and (s)he was perfectly happy -
perhaps doesn't have SQLite on his/her PC (as if). Now you have two
distinct versions to track. Just as you thought it was safe to get back
into the water, I come along with MongoDB. Then there were three!

SCMs offer features such as "branches" which will help to manage this.
Building upon the earlier 'structure' conversation, the SCM will also
help when upgrading some 'process' code, and creates a situation where
that can be "shipped" to every user, of every 'version' (because the
'process' code has been structured to be "independent" of the
storage-method!). This sort of thing requires all-manner of
mental-gymnastics to perform manually (or more likely, certainly in my
experience of this business, 'we' will keep-quiet and the 'other users'
will simply miss-out...).

The other handy side-effect is that documentation associated with
"branches" will enable you to keep-track of which users/groups use which
branch, and when they come to you with a problem/proposal (as they
inevitably will), you 'know' (can reproduce) their exact system, ie what
they think of as "the system"!

I guess it all depends upon one's experience of "hand it off"?

Yes, "features" should be countered by YAGNI. However, much of what was
discussed has the ultimate aim of making life easier for me, oh wait a
minute: it's for you!

Something I find helpful, you may not. Fair enough - there's that other
'principle': YMMV!


> For the record, I passed one of the MongoDB U Python developer's
> classes. Fun stuff, and I've been considering doing more. Sadly, MongoDB
> v5 needs a CPU flag that my old Dell doesn't have. So I'm on the
> obsolescence track already.

Warning: this comment may contain heresy!

Who says that we have to use the latest version? (can you hear the
collective sucking-in of breath? A little frisson of excitement?)


Often we don't use the latest version until 'they' have had time to make
sure it works properly, and then, only after we've gone through and
checked our various 'versions' of things to make sure that our stuff
still works as-advertised.
(it's not just 'our code' that should be 'tested'!)

An alternative (which may be in the "it's OK for you" category*) is to
use a cloud service. The likes of AWS, IBM, Oracle, etc, usually offer a
'free tier' and offer a range of RDBMS or NoSQL options.

* such outfits are generally keen to gain our business, and 'can be
persuaded' to throw freebies our way. Whilst some see Oracle as 'the
death star', etc, etc, I think their free-stuff might be the most
generous of the bunch. Again, sadly, some learning to be done first...


> Of course, us tools folks are often tasked to write in different
> languages. The "#" symbol is a common, if not universal comment
> designator, and that's why I use it vice language specific things like
> "__author__". Keeping the interpreter and those lines up top really
> makes life easy when I have to sort through a few thousand files to
> track names and the last time it had major modifications.

Once again, an 'advert' for SCM. Such systems offer 'search' facilities,
and certainly track mods, dates, etc! Doing such manually over hundreds
of projects is too much like hard work for this little boy!


As to trying to make one language look like another: nope, not going
there - what is the saying about the British and the Americans being
"divided by the use of a common language"?

My philosophy (such as it is): if you're going to use a tool (language),
then use it - don't play with your food!
(compare Python with JavaScript and 'comments' translate, now the rest
of HTML5 (HTML and CSS)? What about SQL, from earlier discussion 'here'?
It ain't goin' to fly, Wilbur!)

The OP asked about "style". Is there such a thing as a multi-lingual style?


> Some years ago my brother, a better programmer than I, told me about
> "input-output-process" and I try to stick to that. In this case, the
> input is technically just three items, BP, pulse, and timestamp. Usually
> we talk about the two BP numbers as a single unit, and the only reason
> they are separate here is to make parsing easier. The pulse is almost
> ancillary, and the timestamp is for sorting if I ever get to "last X
> number of days", or maybe chart across morning, midday, and evening.
> Because the data is stored in a text file, I can edit (vim, thank you.
> None of that pretty stuff) the timestamp if it needs changing.
> 
> I'm on the fence about f-strings. Ruby has been doing that for years,
> and I usually prefer something that's common-ish between languages.
> Using printf or format() is less visually noisy, for me, than f-strings.
> f-strings have added a lot of usefulness, like Ruby, but much of what I
> do can be done before the print statement.
> 
> Does that make sense?

Perfectly! What is right for you, may not be for me - and vice-versa.

When introducing organisations/teams/colleagues to new tools (or when it
is me being the introduce-ee), my motto is: "nothing succeeds like
success". Thus, if I can show you something working - and working well,
and you say "hey, there's something in that for me", then you'll
adopt/adapt/put-in whatever effort may be necessary. Until then, we're
just having a good time talking...

-- 
Regards,
=dn