Imagine you’re writing a CRUD API, which is pretty common.
If null attributes aren’t included in the payload, and someone does an update (typically a PATCH), how do you know which fields should be nulled out and which should be ignored?
I agree for many cases the two are semantically equivalent, but it’s common enough to not have them be equivalent that I’m surprised that it causes arguments
For many uses it is semantically the same.
But for cases where you need to know if something was intentionally set to null or was simply not set, the difference is enormous.
Ah yes the difference between “unset” and “intentionally set to null”, the bane of API devs who work in languages that don’t inherently distinguish between the two.
I love when an API takes a json payload, and one of the json fields is a string that contains json, so I have to serialize/deserialze in stages 😭
Owners:
Now that we have generative AI, we can finally get rid of all those expensive employees
There are common traps and employer don’t spend money/time to train their devs to avoid them.
SOLID principles are pretty decent but a surprising number of people don’t do any of them
I kind of agree. I’m not a pro but I’ve been using gimp to do little bits of editing (mostly to make slack emojis and memes) for a few years, and I constantly encounter little things that seem like they should be simple and intuitive, but are not.
I haven’t used Photoshop in over a decade, but I feel like I rarely felt the same frustration regarding basic tasks.
Gross
But considering the current state of Google search, not as gross as it was.
A coder after my own heart. State machines are the bane of my existence.
IMO there are two underrated benefits:
Designing for micro services doesn’t mean you need to deploy it as micro services. You can deploy it as a monolith and configure it too skip the network stack
Now that’s the pot calling the kettle black.
What work have you even invested? You’ve just repeatedly restarted your original stance. But sure, whatever.
Have you stopped to consider why you can’t explain it better? Perhaps the reason is because you’re wrong.
Your toy example does not show the issue you think it shows. You’ve moved your cleanup block away from the context of what it’s cleaning up, meaning that you’ve got variables leaking out of their scopes. Your cleanup code is now much more complex and fragile to changes in each of the blocks its cleaning up after.
You tried to use your toy example to show A is better, but then we showed that actually B is just as good. So fix your toy example to show what you actually want to say, because everything you said so far depends on you setting different standards for each scenario.
If you’re reading the control flow, and the control flow tells you the first block isn’t being entered, then it doesn’t matter if the first block contains an early return or not, because it wasn’t being entered. If it was being entered then you have to read it anyway to make sure it’s not manipulating state or leaking resources.
To use your example: in subsequent reads, when I’m interested in the second block out of n, say during defect analysis, I can head straight to the second block in either case since control flow shows the first block was skipped - but in the case of early return from the second block I can stop reading, but in the case of a single return I need to read the flow for all subsequent n blocks and the business logic of any subsequent blocks that get entered. The early return is a guarantee that all subsequent blocks may be ignored.
To me this is also obvious. I’ve been doing this for quite a while and 95% of the time, reviewing and debugging code with a single return is far more tedious.
Right. Like I said.
What are you hoping to accomplish by only reading control flow and not the contents of the blocks? You keep raising concerns like not properly releasing resources, but if you don’t read the blocks you don’t know what resources we’re allocated.
I think your argument depends on both having your cake and eating it.
You said yourself they’re equivalent. You either have to read the blocks in both cases or neither case.
You need to read the blocks to know what gets returned (either early or in a single return). You need to read the blocks to see what resources get created but not released. What are you hoping to achieve by only reading control flow?
At least with an early return you can stop reading.
If your function is so long that keeping track of returns becomes burdensome, the function is too long.
I’m not a fan of returning status codes, but that’s a pretty clear example of early return validation where you can’t just replace it with a single condition check. Having a return value that you set in various places and then return at the end is worse than early return.
Cost is the only one you can change quickly.
Yeah, I know I shouldn’t expect much from a site like that, but since it’s shared here I felt like I should shine a little light on the deeper issues.
This kind of superficial “journalism” rage-baiting boomers for clicks is really frustrating to me. Shit like this is brain-rot at least as bad as Tiktok is. It has always existed, but the extent to which it has replaced actual analysis and investigation is depressing.
Yes, the parents are partially at fault, of course. But as you indicated, there are significant societal pressures that force families into dynamics like this and it’s not realistic to expect an overwhelming majority to be able to resist it, alone. And since we’re not about to engage in class-based eugenics, it’s up to society to give them a serviceable ladder to climb out of their situation.
So, TLDR; I wanted to shine a light on deeper issues, so that people don’t think that this is solely a moral failing of parents, and that they DO understand that we have a collective responsibility to help families.
Found the illiterate bootlicker ☝️
I wasn’t taking about new fields. I was talking about resource partial updates (eg PATCH, or commonly the U in CRUD).
If you just want to update a single field on a resource with 100 fields, rather than GETting the entire resource, updating the single field, and PUTting whole thing back, just do a PATCH with the single field.
Likewise if you’re POSTing a resource that has nullable fields, but the default value isn’t null, how do you indicate that you want the default value for a given field? Do you have to first query some metadata API? That doesn’t seem ideal, when this existing pattern exists