I remember having this argument with my professor at the school, who insisted that a function should have only one "return" clause at the very end. Even as I tried, I could not get him to explain why this would be valuable and how does this produce better code, so I'm interested on hearing your take on this?
It helps prevent bugs with state. The apple login bypass bug comes to mind.
Basically, you have code in an "if" statement, and if you return early in that if statement, you might have code that you needed to run, but didnt.
Forcing devs to only "return once" encourages the dev to think through any stateful code that may be left in an intermediate state.
In practice, at my shop, we permit early returns for trivial things at the top of a function, otherwise only one return at the bottom. That seems to be the best of both worlds for this particular rule.
> In practice, at my shop, we permit early returns for trivial things
Are you also writing C or similar? If so, then this rule is relevant.
In modern languages, there are language constructs to aid the cleanup on exit, such as using(resource) {} or try {} finally {} It really does depend on if these conveniences are available or not.
For the rest of us, the opposite of "no early return" is to choose early return only sometime - in cases where results in better code, e.g. shorter, less indented and unlikely to cause issues due to failure to cleanup on exit. And avoid it where it might be problematic. In other words, to taste.
> Kent Beck, Martin Fowler, and co-authors have argued in their refactoring books that nested conditionals may be harder to understand than a certain type of flatter structure using multiple exits predicated by guard clauses. Their 2009 book flatly states that "one exit point is really not a useful rule. Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t".
There are missiles in which the allocation rate is calculated per second and then the hardware just has enough memory for the entire duration of the missile's flight plus a bit more. Garbage collection is then done by exploding the missile on the target ;)
They don't publicize it because they'd rather sell all the data they don't have already through your payments and bank movements but many still send you a dedicated device if you mention you don't have a smartphone.
At least in Nordics (I'm from Finland) heat pumps are rapidly replacing other forms of heating. One can get a big enough heat pump for a 200m^2 house (including heating hot water) for around 10-15k, with a few thousand more for installation price.
Adding 10-15kWp of solar panels to the roof is around 6k more. It's definitively a no-brainer as it will recoup the investment in 5-10 years.
It helps tremendously if you have a programming background as usually the developers behind the original format didn't have any need to make things harder than they need to be. Because of this, you can often guess how the format works, aka. "If I was the original developer, how would I do this?"
I am an engineer, but not a computer scientist or developer. I have been using Linux for 20 years and program a lot at work and at home. I think it should be possible, but find it difficult to interpret the hex code. I do have a general idea of how the format should be organized, as it contains mostly geometric data and associated results.
I used to have a very common name (before getting married and took my wife's last name). Imagine that I have firstname.lastname@gmail and somebody was genius to take firstname.lastnam@gmail.
I felt this was so stupid, that i quickly lost any willingness to try to relay the emails to their original owner, as the other person had zero interest to change their address to be harder to mistype.
Apparently; I wasn't aware. But unlike Zig this doesn't work with FFI ... everything has to be Go code ... cross compilation works by compiling the library code for the target and caching it ... but if you need anything outside of that you're out of luck ... or maybe not ... I ran across this tidbit:
"When a Go project utilizes CGo to interact with C code, standard Go cross-compilation might require additional steps. This is because Go can cross-compile Go code but not C code directly, necessitating the availability of target system libraries on the development machine. Tools like Zig can be used as a C compiler (zcc) to facilitate cross-compilation for CGo-dependent projects by providing the necessary cross-compilation capabilities for the C code."
I'm curious to understand the need to have names for such many different colors and I'd love to hear your take! A naive reasoning would say that names are useful if at least two different persons know the meaning for a name and thus it will help communication.
Now I'm not sure how many colors are there in that list, but it feels like there are too many to be practically useful. How do you see this?
I build a lot of tools that generate colorpalettes and I wanted a wide range of nice-sounding names that feel evocative of the colors they represent. I see it as an API between a program and a human.
I started with about 1,600 names scraped from Wikipedia, but with only that many, there were a lot of redundancies and when you disallow duplicates, you end up with colors being labeled as “orange” even though they don’t actually look orange. On top of that many of the names were racist or at least questionable (so are many names on colornames.org)
Other large lists like the Pantone one, don't have a permissive license.
So for the past ten years or so, I’ve been collecting color names in a very unscientific way. It slowly turned into a hobby—something I often do on vacation, especially when I’m surrounded by unfamiliar places, dishes, or objects where color is used in unexpected ways.
reply