I think this meme sums it up quite well:
My Expierence with Python and API so far
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)
Co-owner and Developer of TornPal
TornPal API - Extract market & bazaar data with your own tools/sheets
I think this meme sums it up quite well:
That's where I more or less said to myself: "f**k it, I'm moving to finance"
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)
It doesn’t look too testable but it doesn’t look that bad.
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)
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.
Co-owner and Developer of TornPal
TornPal API - Extract market & bazaar data with your own tools/sheets
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)
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
programfunction do one thing well. To do a new job, build afresh rather than complicate oldprogramfunctions by adding new features.(ii) Expect the output of every
programfunction to become the input to another, as yet unknown,programfunction. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.(iii) Design and build
softwarescripts,even operating systems, to be tried early, ideally withinweekshours. Don't hesitate to throw away the clumsy parts and rebuild them.(iv) Use tools in preference to unskilled
helpmanual 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!
~ P
Support my suggestions: Faction API Keys