Doesn’t it steal control flow? More like a break point, except you define where execution continues.
I wonder if it’s a compile error to have multiple conflicting COMEFROM statements, or if it’s random, kind of like Go’s select statement.
How awesome would it be to be able to steal the execution stack from arbitrary code; how much more awesome if it was indeterminate which of multiple conflicting COMEFROM frames received control! And if it included a state closure from the stolen frame?
I'd say it's more like setting up a handler for a callback, signal, interrupt or something along those lines.
Function declarations by themselves don't usually do that. Something else has to tell the system to run that function whenever the correct state occurs.
That doesn't account for unconditional come-froms.¸but I expect there'd have to be a label at the end of some code somewhere that would give a hint about shenanigans yet to occur. Frankly that'd be worse than a goto, but then, we knew that already.
Its like if subroutine bar could say its going to execute at line N of routine foo. But if you were just reading foo then you’d have no clue that it would happen.
You can simulate this effect with bad inheritance patterns.
A function will be called by code and go to that point in code. To implement functions, you store necessary things to memory and goto the function definition. To implement that with comefrom you’d have to have a list of all the places that need to call the function as comefroms before the function definition. It’d be a mess to read. We almost never care where we are coming from. We care where we’re going to. We want to say “call function foo” not “foo takes control at line x.”
I don’t see any case where this is better than a goto. A goto you can read progressively though. A comefrom you’d see written then have to track to that piece of code and remember there’s a potential hidden branch there.
It’s not that bad. It definitely helps in long functions.
I’m an advocate for code commenting itself, but sometimes it’s just better to comment on what you’re doing, and in those cases it helps to over commentate.
Instead of letting the reader interweave code reading and comment reading, I think it’s better to do either. Either you go full self describing code, letting the reader parse it as code,m, or you abstract everything, making it more of an explanation of your reasoning, and abstract lines that may look too complicated.
Not every comment needs to be useful, but I still write them to not have this switch between reasoning and thinking in code. It can also double as rubber duck debugging too!
Management said that writing tests takes too much time and eats into the time that could be used to write features for the app, so they decided that we’re not writing tests. They were always green anyhow
What would be even more wild is if you edited/replied to yourself and said, “nvm figured it out”…only to later discover it and not remember what you did
I had an issue years ago with a tv and a dvd player. For whatever reason, whenever the dvd player was connected, the tv would blank out every few seconds. At some point I posted on the tv manufacturer forums. I did eventually figured out that I leave a thumb drive connected to the tv, the problem disappeared. I wanted to let people know about my work around. I got 1 result – the forum post I had made quite a while back.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.