Thank god

In the way that’s common in languages like Java where you’re making a property read-only, yes. But there’s a whole protocol in Python called descriptors where you can override the . on a field. The most common form of these is class methods annotated with the @property annotation, which makes it so the method can be accessed as if it were a property.

Yeah. I can understand the use case when it’s something relating to keeping simple state in sync by replacing it with derived state. But this particular case was flushing a cache after each get, which made each get of the property non-deterministic based on the class’s state.

I helped a friend debug a script last week that was working inconsistently in really weird ways. I looked at the script and it was all event hooks littered with sleep calls. I told him he was basically fuzz testing his own script and then getting surprised when he found race conditions. Shit was wild. Also, sometimes getters in Python are a mistake.

You left out the part where, instead of telling him to knock it off as soon as they learned about it and disciplining him internally as a student, the school contacted law enforcement and allowed him to continue doing it so they could prosecute him harder make an example out of him. You’d think if he was as big of a threat as you’re implying, they would stop what he was doing ASAP. And if you’re going to be pedantic about leaving out details, maybe tell the whole thing. Maybe it’s not “honest” enough if we haven’t posted the full text of a documentary in a comment. That’s clearly your call.

Worse than Bitcoin miners, AI seems to have the wholethroated support of capital (rather than a single faction), who see it as the next big form of automation

dozen = 12 + 1; // one extra for the baker!

I got mad at this when I first saw it but then I remembered there’s some code at work that defines an hour as 50 minutes

Statistically, this makes your code better

Yeah…. I’ve definitely been the next guy on a couple bad regexes that I wrote

When versioning and feature flags are too hard: just use git and hope for the best

My old senior used to do this before he got laid off and now I’m charge of code that’s littered with old commented out code and no way to know why it was commented out.

Then it breaks years after you’ve left and someone has no choice but to touch it

I often use comments as ways to say, “I know this is cursed, but here’s why the obvious solution won’t work.” Like so:

/**
 * The column on this table is badly named, but
 * renaming it is going to require an audit of our
 * db instances because we used to create them
 * by hand and there are some inconsistencies
 * that referential integrity breaks. This method
 * just does some basic checks and translates the
 * model’s property to be more understandable.
 * See [#27267] for more info.
 */

Edit: to answer your question more directly, the “why not what” advice is more about the intent of whether to write a comment or not in the first place rather than rephrasing the existing “what” style comments. What code is doing should be clear based on names of variables and functions. Why it’s doing that may be unclear, which is why you would write a comment.

It’s worse. Her husband, who is filing the suit on behalf of her estate, once signed up for the free trial. It wasn’t even her who agreed to it.

Writing plain old JavaScript without a library or framework is nice while you’re learning. Too many people will learn a single framework and not have any idea what the underlying APIs are, so the transferable skills are minimal.

This is what buying from coop developers is like. You know that everyone involved has agreed that everyone else is essential to the creation of the game and that everyone receives a cut in one way or another.