291–300 of 369 posts
Earlier quoted context omitted.
Singleton is just a fancy name for a global.
Ah, but they come with the benefit that you are forced to only ever make one. A global doesn't prevent you from doing that, so singletons are ever so slightly better.
Earlier quoted context omitted.
Singletons are globals, aren't they?
Kinda depends. Single instance things are usually globally referenced, but as long as you're referencing an instance and not a static thing they're not hard to convert to an "injected" dependency if you need to provide a test impl to some thing being tested. The real problem is static things that can't be swapped out because you're actually calling static methods on some class rather than sharing an instance and call…
Earlier quoted context omitted.
But here's the thing: aren't most alternatives to global, some other kind of global state anyway, but possibly better managed?
Almost assuredly better managed. There are no reasons to manage state on the global level apart from laziness.
but even if the prog-lang had specific support for safe(r) globals, it would still just be a global at the lower (higher?) level.
Earlier quoted context omitted.
Kinda depends. Single instance things are usually globally referenced, but as long as you're referencing an instance and not a static thing they're not hard to convert to an "injected" dependency if you need to provide a test impl to some thing being tested. The real problem is static things that can't be swapped out because you're actually calling static methods on some class rather than sharing an instance and call…
I see your point, but aren't all those things architecture dependent i.e. dependent on the implementation of the prog-lang environment?
Earlier quoted context omitted.
> Calling something a "best practice" is basically an appeal to authority. If presented on its own, but then, any conclusion presented on its own without supporting context and analysis is the same. > But really, "best" and "right" are highly situational A description of a best practice that doesn't provide a sufficiently precise description of the situation to which it applies as a best practice is generally inappro…
Even worse are people that talk of "code smells", applying their personal opinion of style in a judgmental and often unjustifed way.
// A
const int giraffe = 1 + 1 + 1 + 1 + 1;
// B
const int number = 5;
A is similar to Roman numerals. We all know that Roman numerals are no longer used for most purposes and were replaced by the numeral system we currently use. Not only the new numeral system is more convenient for various reasons but it allowed people to advance math further. So A is better than B in that sense.
Then, A uses an identifier that doesn't represent its value. We can also say it's bad because of that reason.
You can try to seek ways to compare and improve code. Not all of them will be effective, but at least you will be trying. That is better than being that disagreeable, nihilistic guy that thinks that everything is subjective and relative and won't agree with anything you say.
You have to learn how to treat your code with respect and prevent it from becoming a tech debt dumpster.
There is code that is objectively bad. And you will know when you try to maintain, debug or profile it, or when you have to explain it to someone else. Or when it keeps breaking over and over again and many defects are connected with it. Or when it becomes a product limitation and you have to apologize to customers about it.
Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…
Reminds me of US Generally Accepted Accounting Principles (GAAP). I don't need to be perfect, just consistently good enough.