OT Python help?

[GB]

Having seen the question about avahi, and all the knowledgeable replies, would it be reasonable to ask about something bothering me with Python?

[The Natural Philosopher]

Can try, but I for one have never coded in it

[Pancho]

Easily remedied, cut and past the following line into a command window.

$ python3 -c 'print( "Global warming is caused by CO2")'

And Bob's your uncle, you'll be a python programmer.

[Pancho]

Surely such a question is better suited to ulm.

[The Natural Philosopher]

No I wont, I'll be a liar

[GB]

That's whooshed past me, I'm afraid.

[Richard]

Seems that application of a broom handle will solve both problems.

[Brian Gaff]

There does seem to be a lot of it about on github. Indeed the screenreader I'm using now has very large parts written in it. Brian

[Pancho]

Points:

You have taken up our time without telling us the problem, which is always a little irritating.

It is OT for both groups, so why ask here rather than ulm.

ulm probably has more experienced Python programmers as regular posters.

It would be marginally more on topic in uk.comp.homebuilt which is at least a computer related group.

[Pancho]

Superficially, it is a nice language, simple, good standard collections. Most of the time, this is what you want, complex language features just make the code harder to write, understand.

In practice, as a novice, I found it hard to use due to lack of typing, buggy library packages and lack of threading.

[alan_m]

Often the biggest problem is that a lot of hobby software writers don't include any meaningful comments within their code so it is often impossible or difficult to second guess what was intended.

Sometimes even those with good intentions wait until the code is working to their satisfaction but never get a round tuit finishing the job :(

[Bob Eager]

Back in the days when students handed in work on printer paper...

I frequently received program listings where the comments had been added in, in pencil, after the listing had been printed. Despite them being second years students who should have known better by then.

[Pancho]

As a professional programmer, I was always disappointed that graduates were taught to write the most pointless commenting, clutter. Stuff like comment each and every function and parameter.

Generally, for comments, I used to like a little story, giving the initial motivation for creating a class or significant function, but not much more. Sensible naming and functions should make the code understandable.

When my son started his first job, he was told to read a good book called "Clean Code", by Robert Martin. The book outlined good practice from a genuine, experienced software developer, rather than some arbitrary dogma arbitrarily decreed decades ago.

[Rob Morley]

Absolutely - well formatted self documenting code with meaningful variable and function names may take a little longer to type (probably not much in a modern IDE). Who hasn't come back to working code that was thrown together in a hurry, only to wonder WTF is going on, particularly if you did it in a "clever" way with too much coffee and too little sleep?

[Richard]

Question: WTF ulm?

[Pancho]

A newsgroup: uk.legal.moderated

[Richard]

Thanks.

[Bob Eager]

Ours weren't.

1. Don't comment what is obvious.

1. Use a long comment if something is obscure; but, better, change the code.

2. Comment all interfaces.

[Tim Streater]

Or in some cases do it off-line. For an app I've been developing for some time, I've now got 45 pages of internal notes in addition to the 60 page User Guide.

[Bob Eager]

For a current project, I'm considering doxygen.