Doing that with GNU or WINE will use your entire memory
Doing that with GNU or WINE will use your entire memory
of course nods along
my favorite JS framework is HTMX for making me write less JS or even none at all.
I don’t think so. A half-measure using docstrings would likely take more processing power and require an ad-hoc implementation because comments are not broken down into ast components afaik. It would also be more costly in the long run if they decide to convert it into a proper syntax, as a result of docstrings not having a single standard way of being written.
Python has introduced several syntactic changes for type annotations, this is not unreasonable.
So you have to do dumb workarounds like declaring every
bool
values asbool | np.bool_
or castingbool_
down tobool
.
these dumb workarounds prevent you from shooting yourself on the foot and not allowing JS-level shit like "1" + 2 === "12"
deleted by creator
I’ve been using copilot for a while to know it’ll be something like timeBottom and timeTop.
But if anyone’s getting this recommendation there’s probably not much code in that file or the code is trash. Garbage in, garbage out.
some heroes don’t wear caypes
that’s still a docstring, idk of linters that take docstrings into account at all. We need a semantic approach for this kind of annotation.
nothing wrong with that - it is an exception, as in, the customer is likely lost after that anyway.
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave the validation behind just the same.
And that conditional indents your entire function one level - if you have more validation checks, that’s one level of indentation per check (or a complicated condition, depends whether you can validate it all in one place). It’s pretty much the case the other user illustrated above.
Returns inside business logic past validation is where the problematic bugs of this class show up
That much we agree. But again, this is not an early return issue, putting too much logic in a function is the issue. Rewriting it without early returns won’t make it much clearer. Creating other functions to handle different scenarios will.
You can say any execution flow controls are like gotos - continue, break, exceptions, switch, even ifs are not much more than special cases of gotos.
This is true regardless of the size of the function which shows that the size of the function isn’t the determinant
Logical clarity does tend to worsen as the function grows. In general, it is easier to make sense of a shorter function than a longer one. I don’t know how you could even say otherwise.
Early returns are still great for argument validation. The alternative means letting the function execute to the end when it shouldn’t, just guarded by if conditions - and these conditions any reader would have to keep in mind.
When a reader comes across an early return, that’s a state they can free from their reader memory, as any code below that would be unreachable if that condition was met.
I hate it when some blame early returns for the lack of maintainability.
Early returns are a great practice when doing argument validation and some precondition checks. They also avoid nested blocks that worsen readability.
What’s being described there is a function that tries to do too much and should be broken down. That’s the problem, not early returns.
I thought it was just incrementing the address and dereferencing it, but I don’t write C or C++. What is being overloaded there?
a fellow two marshmallow kid, I see
“cross-platform” exe
lists windows, windows, and windows disguised as wine
Phear
nice stack traces don’t matter when PHP has the best built-in name: die()
if your tractor can’t run farming simulator, is it even a tractor?