[A photograph of a road signpost in front of a metal fence with a low, long building in the distance. The post has two signs on it. At the top is an octagonal sign, filled red with a white outline, reading “STOP”. Beneath it is a rectangular sign with an arrow pointing up to the stop sign, and text reading “THIS IS A STOP SIGN”.]
I am a human who transcribes posts to improve accessibility on Lemmy. Transcriptions help people who use screen readers or other assistive technology to use the site. For more information, see here.
Thanks! Not sure if there’s been other people doing any or not, but for my part I just do them when I find the time, which unfortunately isn’t all that often.
They will die there, because they need a slightly older version of some minor library for compatibility, and nobody cared enough to continue hosting it.
If I'm thinking of the same device, the one I used in Sweden and Norway, it's fantastic. It's in the shower itself, so you don't have to contend with 30m of cold pipes between a less effective water heater and the nozzle.
In the house I grew up in, you’d also have to hope no one flushed the downstairs toilet. If so, the cold water pressure would suddenly drop, leaving a lot more hot water coming out of the shower head.
Let’s face it, such comments usually cause more problems than do good. If someone changes the code and forgets to modify the comment, the reader might favor one or another at random. “Stop sign” example isn’t the best but you get my point.
Comments at best should explain some non-obvious logic, or some sort of reasons for implementing one way or another. For SDKs and packages overall, public APIs should also be commented. The rest imo should be readable from code.
A form of “self documentation” I like to do is create variables for conditions before using it in an if statement. If you break down a funky conditional into easy to read variables it becomes a lot more clear what it’s trying to do.
If someone changes the code and forgets to modify the comment, the reader might favor one or another at random.
Hence why you should comment why, not how/what.
// slow down traffic before crossing busy main road
Now you can change the stop sign to a yield without touching the comment. Or judge that the comment can be removed if it’s clear the main road does no longer exist.
If yours uses a thermal sensing element (not just mixing blind),I’ve found running it through its full temperature range helps a lot. I suspect limescale and other crap build up on the thermal element. It adds several years on to the life of the mixer. Descaling it would likely also work, but involves removing it from the pipes, to get the cleaner in.
“Other people” are what’s wrong with me. People don’t use linters/formatters/type annotations when it’s optional and produce dogshite code as a result. Having the compiler itself enforce some level of human decency is a godsend.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.