My Expierence with Python and API so far

I think this meme sums it up quite well:

Load image

Can’t have scope creep if you never define the scope xD

Just going to leave this here and go cry myself to sleep with my spaghetti nightmares (FYI, I am not a developer, I'm sysadmin/infosec xD)

[image: uploads.glasnost.dev]

[image: uploads.glasnost.dev]

That's where I more or less said to myself: "f**k it, I'm moving to finance"

It doesn’t look too testable but it doesn’t look that bad.

Probably the best feedback my coding has had in years, I'll take it :)

I do have some unit tests setup elsewhere, but coverage isn't great whilst I am still shuffling things around and building up the workflows.

I'm not one to judge. Most of my Torn projects have no or almost no tests.

My advice is to make heavy use of functions. Each of my functions does ONE thing, but with variable parameters. It is modular in that way. Then, I can puzzle piece functions together at the end of the script to execute. This way, I can stay organized and easily read the logic.

Internet search for "Unix philosophy", it helps. When scripting, I substitute "program" for "function". I've copied/pasted it below, and reworded a couple terms.

(i) Make each program function do one thing well. To do a new job, build afresh rather than complicate old program functions by adding new features.

(ii) Expect the output of every program function to become the input to another, as yet unknown, program function. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

(iii) Design and build software scripts, even operating systems, to be tried early, ideally within weeks hours. Don't hesitate to throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help manual work to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!