Hacker News Reader

Comment by cwp | Hacker News Reader

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 ago, where somebody got flamed harshly when he mentioned using a global variable. He then explained that he was working on an embedded control system for cars and all the variables in that system were global. The team was well aware of the pitfalls of global state and used a combination of documentation, static analysis, custom tooling and elaborate testing to mitigate them. It was a considered design choice that made it possible to develop high-performance, hard-realtime software that could run on very limited hardware.

View on HN

One thought to add here - when you appeal to an authority, which one is it?

In the OP example, it seems the senior dev is saying “on my authority”. And sometimes that is enough, especially if the senior dev can give examples of when not following this practice bit them.

But sometimes there is a higher authority, such as “it’s what is recommended in Google’s SRE book”, which is probably good advice if you are building a large SRE team. (Though as you say, not in all situations.)

I think in the worst case, “best practice” can indeed be used to shut down discussions of a leader’s preferences. But you can smell that out by asking for concrete examples, and asking how widely the practice is recommended.

A good “best practice” should be justifiable and explainable.

All that said, sometimes as the senior engineer you need to go with gut feel; “this design smells like it will give us trouble within a year” is the sort of thing I sometimes say. But I think it’s important to be honest that it’s a hunch, not a certainty in these cases, and discuss/weight accordingly.

> All that said, sometimes as the senior engineer you need to go with gut feel; “this design smells like it will give us trouble within a year” is the sort of thing I sometimes say.

That's a really great perspective. There are a bunch of times where I have a preference for or against something, but I can't point to a specific example of when that thing was good/bad, or any objective data about it. It's just that my experience suggests to me (via murky pattern matching in my brain) that particular thing will be good or bad.

It's certainly weaker evidence than data or concrete examples, but I think it's still valuable and worthy of consideration.

Yep exactly! I think if you broaden the concept of "authority" beyond literal authoritative sources it gets even more murky.

Are you appealing to the authority of speed? Compilation time? Readability? Functionality?

I dunno, and it often (especially around readability) comes down to the developer's/senior engineers preference.

“Best practices” smells like such a marketing term it should be tossed in the bin.

It’s poetic language that has nothing to do with specific problems.

What people usually mean when it comes to engineering is “be safe, reliable, and correct.”

Security best practices to be safe.

Developer best practices for reliability.

Etc etc

“Best practices” is hand wave-y fluff for “do a good job” and doesn’t need a technical definition.

Make sure you’re secure, reliable, and correct given the engineering context, and odds are you result in a system that also has a lot of specific best practices in place.

I think it's very telling just how little engineering there is in Software Engineering that people can call best practices "just preferences" or "marketing fluff" and not be immediately laughed out of the room.

Because that's what would happen if someone suggested "best practices smells like a marketing term" in an actual engineering discipline.

Engineer to solve the problem. Not banter online.

My problem is people take a slogan like best practices and copy-paste in every new framework because it’s de facto best practice.

If the business is one of 1,000 todo apps, sure copy paste.

But it’s new hardware best practices are different and we ought to acknowledge that software use case isn’t as uniform as electronics, where Ohms law and material waste are coupled to waste.

Language choice and syntax choice depends on the problem as the team sees it. Avoid buffer overruns, sanitize inputs.

There you have it; software best practices.

Which brings to the realization that we have a lot of software development and much less software engineering.

Sometimes "best practice" is not because we need to worship a standard, but we need to have a standard. If everyone does everything in a different manner, you wind up with a tower of babel and support becomes impossible.

I'm of the mindset where an organization needs to agree to specific principles that everyone adheres. Not dogmatically but pragmatically.

Having that shared "best practice" makes is easier to support other people code/system, allows people to get up to speed faster and as a bonus, allows you to make a blog post on Medium where you can call yourself a thought leader.

> I'm of the mindset where an organization needs to agree to specific principles that everyone adheres.

Agreed. But GP was talking about context dependency of those best practices. E.g. what might be a good best practice for a large organization inside a FAANG might be very bad for others. Some organization have very immediate feedback cycles. A significant problem in Amazon's online shop will probably show up immediately in sales numbers. A significant problem in the control software of a plane, might kill a few hundred people in a few years before people realize there is a problem. Therefore you cannot a/b test which auto pilot works better in a certain situation. (Although Tesla might disagree about that /s).

The point is every so called "best practice" should state under which precondition it is supposed to be applied. And most blog articles and books ignore that completely.

My experience is that enforcing standards for everybody is really bad. Different projects are truly different and require different trade offs. Enforcing one way to do things is anti-agile.

> somebody got flamed harshly when he mentioned using a global variable.

Harsh bashing on global variables is such a dumb thing.

Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals.

But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost every function [sic]).

Global mutable variables are generally a bad idea because they have nonlocal side effects which are difficult to mitigate, like aliased mutable pointers but worse. Extra non-aliasing arguments and multiple return values are free of these issues, and a better tradeoff in almost all cases (unless you're sure you'll never run 2 instances of a system in the same address space, and you have specialized constraints possibly including embedded/safety-critical development and emulators).

When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations. Windows's GetLastError is a mess (some functions set it on error but don't clear it on success), I'm not sure about POSIX's errno, and when threads were introduced, these variables had to be changed to thread-local state.

That big backing relational database of yours contains tables of "global mutable variables". The non local side effects are part of the point.

For service directory lookup, global variable is fine. For global scope queue, global variable is fine. For global scope logging service, global variable is fine.

Each of these things prevents isolated testing of dependent components. For that reason alone they are nonstarters.

   globalvar = new NopImpl()

works fine for testing. If you squint, you can even think of dependency injection frameworks like Dagger as a lot of boilerplate around a global database of instantiations.

Until you try to run two tests at once, one which requires NopImpl and one which requires the real impl.

As dcow pointed out, it really doesn't work fine for testing, as it couples what should be isolated tests together, and prevents them from being executed concurrently.

> When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations.

Usually.

There is one pattern I keep using in Rails to inject the current_user for the request into the model layer. At the beginning of a request, Thread.current[:current_user] gets set to the current_user. At the end of the request, it's cleared.

For those unfamiliar, each Thread has its own Hash object and [] and []= instance methods to access it. It's a way to create global variables scoped to the current thread. To hide this implementation detail, I wrap this functionality in ApplicationRecord.current_user and ApplicationRecord.current_user= methods so no one accidentally uses :curent_user.

The most common use case for this is to automatically set created_by and updated_by on a model, the same way created_at and updated_at are set.

Cron jobs can do something like ApplicationRecord.current_user = User.cron_user if needed. Ideally, I would set this in a CronTask parent class so current_user is always available in the model layer.

I always document these methods and explain exactly what is happening and why. Abstracting away from the implementation detail mitigates most of the problems with a global variable. Obviously, the Thread.current method does not work at all if you're using an event or actor driven architecture. Rails does a thread (or process) per request, so this works extremely well.

> It's a way to create global variables scoped to the current thread.

That's not a global variable; that's a thread-scoped variable.

(It's also not (really) mutable. It gets initialized at the start of the scope and gets removed at the end of scope.)

This is one of the reasons GNU Emacs will probably never be symmetrically multithreaded.

> Yes, we should tell beginners to avoid globals.

Welcome to Dependency Injection in .Net Core!

"Those who cannot remember the past are condemned to repeat it." -- George Santayana

On the contrary, I think beginners should use them because it reduces cognitive load in tiny applications.

My standard rebuttal to anti-global dogmatism is "there's only one instance, and never needs to be more. If/when we do, we can consider doing something else."

But here's the thing: aren't most alternatives to global, some other kind of global state anyway, but possibly better managed?

You can just... not. Give the thing an explicit scope and lifecycle. Maybe that's actually "program lifespan", but if you make that "execution of the main() function" rather than just "IDK, somewhere", you have more visibility and control.

Singletons come to mind as being a better alternative in languages that can do that sort of thing.

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.

Yes, but hence a global "but .. better managed" :-)

People also bash singletons, so you can't really win.

You can get issues with a singleton being accessed for the first time from multiple threads at once, for example, so you end up with more than one instance being created or a situation where one thread triggers the creation and another accesses before it has been fully initialized, depending on the code.

If you expect that sort of thing to occur, then your get method should be synchronized to prevent it.

These days in both Java and Swift you can just lazily reference a static class field/property set to an instance of the singleton (in java the field must be on a dedicated private class) and the Runtime will lazily initialize it exactly once in a thread-safe manner the first time it is referenced.

That's only the tip of the iceberg I'm afraid. If the singleton has methods that perform actual work asynchronously and different threads are hammering on it, all kinds of issues come up. Of course a seasoned developer is going to acticipate this and write the needed infrastructure, but a newbie is not. It can be better if different threads have their own worker objects with their own state for example.

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 calling instance methods.

I understand "singleton" as "only one exists" and "it exists in the global scope". That is, if I create one instance of something in my `int main()` that's not enough for it to be a singleton. That's important, because there's more than one way to enter your program. Notably, tests don't flow through your main entrypoint.

I see your point, but aren't all those things architecture dependent i.e. dependent on the implementation of the prog-lang environment?

Yes.

Almost assuredly better managed. There are no reasons to manage state on the global level apart from laziness.

Sweeping statements like that are the real laziness. All it proves is that you lack diverse experience in software development.

I'm a big advocate for functional programming but even I have to concede that in some domains, and particularly in some languages, when you're having to manage universal properties those properties are sometimes best placed at a global level.

Funny you should mention that. I've used ocornut's ImGui library in the past, with a single, hierarchical object that managed the entire GUI state.

This approach caused whole classes of problems that affect regular GUIs to simply disappear, and it was the most performant, least buggy UI I've ever written by a country mile.

It's quite common in python to manage/encapsulate a global by wrapping it in a module, so arguably a singleton is the same thing, just encapsulating in a class/class-instance instead?

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.

Isn't Redux doing this exact thing?

It is best practise to use RCCBs, because it turned out faulty wiring can kill people. But in Server rooms where you might not want to switch off the whole rack without warning when one device is faulty, you can use a device to monitor the residual current (RCM). Which issues a warning first, and only switches of when the residual current raises over the acceptable level. Different scenario, different best practise. (This is also the reason medical equipment is expensive).

I think a professional should be aware why a best practise exists and how to deal with a situation where for some reason it cannot be applied as you showed with the embedded example.

Don't forget however that many devs are against best practises out of lazyness or because they don't understand the reasons why they are best pracises.

Identifying a best practice is actually not as hard as people realize imo (although it may take some time), and only becomes hard when you let emotion and sources of emotion come into what should be a rational decision making process (such as preference for a certain tooling for reasons like familiarity or popularity in the field today rather than outright advantages vs other tooling).

To identify the best practice for anything, you start by doing a review of all the available practices in the field for a given problem you are working on. Then once you've reviewed the literature you can work out the pros, cons, caveats of each of these tools, and how these considerations affect your particular use case and your expected results. Then after doing that, the best practice out of available options will be readily apparent, or at the very least strongly justified, not by an appeal to authority or popularity or familiarity, but by looking at what the underlying technology actually does and how its relevant or not to your particular task at hand. In the end you will find the very best hammer available out of all the hammers people have made in this field for your particular unique nail.

That sounds like a beautiful example of letting perfect be the enemy of good.

Just like your design choices have trade-offs, is it important to realize that there's a trade-off between finishing sooner and making a better solution. Diminishing returns are usually very much in play with analysis.

(I would also challenge the notion that every situation has a different "best practice". That's just creating a solution. "Best practices" are usually general advise that is applicable in most situations.)

You shouldn't take forever, but what I'm saying is a best practice emerges after doing however much due diligence. Maybe you spend an hour looking into it and that's it, but you should do your due diligence to vet what sort of approaches you can take to solve your particular problem as best you can, so you can make the best decision based on the evidence you've been able to find within however much time you are working with. A professor gave me a word of advice once, "a week in a library can save a month in the lab."

Most decisions don't require that much thought. They're low stakes and can easily be changed. To build on the professor's metaphor: don't spend a week in the library in it'll only save you a day.

If it's a bit more important, do a quick Google, but only break out Excel for the comparison tables if the decision is life-changing.

Honestly, the most important thing that professors don't teach and real life does is that sometimes the optimal thing to do is to not do the optimal thing.

Two different “experts” will do this and arrive at different conclusions. Now what.

> 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 inappropriate, unless it is the conclusion of an analysis of applicable best practices to a certain situation, in which case the scope is specified in framing the analysis.

It is true that lots of things described as best practices for particular situations with supporting rationale and up getting detached from their logic and context and becoming cargo cult best practices.

Even worse are people that talk of "code smells", applying their personal opinion of style in a judgmental and often unjustifed way.

Code smells aren’t conceptually about style but indicators of potential (possibly latent) bugs. A code smell is different than a style problem (though they overlap), its a thing that warrants attention because of risk of hiding errors.

Smart experienced software developers disagree on “best practices” all the time. What is “obviously” the best practice to you is “obviously” not the best practice for somebody else. Now what?

Reminds me of US Generally Accepted Accounting Principles (GAAP). I don't need to be perfect, just consistently good enough.

Or Tesla/Uber/etc, in which rules don't apply to you so do whatev

> He then explained that he was working on an embedded control system for cars and all the variables in that system were global.

Everyone should write Embedded at least once. It's a completely different world.

and hard real-time.

It really inverts some priorities (I mean development priorities, not the priority inversion on mars pathfinder)

Reply on news.ycombinator.com