Have you considered just doing hyposensibilization therapy? No reason to go the way of surgery before trying that. Worked wonders for me and my array of allergies, dust mites among them.
I tried hyposensibilization therapy, and while it worked for seasonal birch pollen issues, it didn't work for dust mites, oral allergies, and chronically stuffed sinuses.
Prevent pasting comments. Implement a naive check for time spent typing the comment, and shadowban posts that don't pass the criteria. Add a 1 minute wait and captcha for posting.
That'd drastically reduce the amount of low effort posts, both human-written and generated.
Well, the map obviously does a lot of extrapolation. Look at Norway, for example. The bigger cities pollute the air in a 50km radius? In a country where heating is primarily electric? When Berlin and Paris don't seem to affect the air quality 20km away, despite having ten times the population?
Which branch your work was done on is noise, not signal. There is absolutely zero signal lost by rebasing, and it prunes a lot of noise. If your branch somehow carries information, that information should be in your commit message.
I disagree, without this info, I can't easily tell if any commit is part of a feature or is a simple hotfix. I need to rely on the commiter to include the info in the commit message, which is almost always not the case.
It's worse than that: the branch name is lost after a merge. That "merge branch xyz" is simply the default commit message. So it doesn't matter what you do, commit messages are all you have!
How would you measure time going backwards if you can only perceive it going forwards? How can you "experience" everything around you going "backwards" if that includes your memory? How can you determine that a specific moment in time was arrived at by time going forward, or by going backwards?
Readability without a clarification is a non-concept. You can't say "X should be readable" without giving some context and without clarifying who you are targeting. "Code should be readable" is a non-statement, yes.
Add "to most developers" for context and you'll probably get exactly what original claim meant.
It's not a non-statement. Rich Hickey explains it well, readability is not about the subjective factors, it's mostly about the objective ones (how many things are intertwined? the code that you can read & consider in isolation is readable. The code that behaves differently depending on global state, makes implicit assumptions about other parts of the system, etc - is unreadable/less readable - with readability decreasing with number of dependencies).
"to most developers who are most likely to interact with this code over its useful lifetime."
This means accounting for the audience. Something unfamiliar to the average random coder might be very familiar to anyone likely to touch a particular piece of code in a particular organization.
>"Code should be readable" is a non-statement, yes.
Oh, I completely disagree here. Take obfuscation for example, which you can carry on into things like minimized files in javascript. If you ever try to debug that crap without an original file (which happens far more than one would expect) you learn quickly about readability.
reply