All language subtitles for 004 Naming Things & Cache Invalidation_en

So here is a very commonly repeated quote about computer science.

There are only two hard things in computer science cache invalidation and naming things.

And this is usually attributed to Phil Carlton, an engineer who worked at silicon graphics and Netscape,

among other famous companies.

And this is a very sometimes added to this quote, by the way, is and off by one errors.

So there's only two hard things cache invalidation naming things and off by one errors.

I tend to think that really the first two of the most important, although that second one is kind of

funny.

So what is cached cache invalidation?

We'll get to naming things in just a second.

I think it's the easiest thing to unpack, but cache invalidation doesn't necessarily mean something

if you haven't necessarily got a theoretical grounding in computer science.

So what do we mean by caching?

Well, caching is when we store of value.

That's for performance reasons or for ease.

We could have just calculated.

So for example, we've got a square and the only information we need to know about a rectangle in this

case.

Only thing we need to know about a rectangle is its width and height.

And from that, we can have set width height on this.

If this was a class, we could also have a get area method and we could calculate the area using the

width and height by multiplying them.

However, if we decided, Oh, we want to do this for performance reasons or just for simplicity's sake,

we didn't feel like writing a getter.

We just go and store the area in a new variable.

So we've just added another piece of state, another variable into the mix in this class.

And because it's a cache, because it is derived from other data and could easily be read arrived,

there is a problem of invalidating this cache every time I call set width or set height.

I need to remember to write code that updates the area.

Otherwise, this cache becomes invalid.

The very variable stored in the area is now no longer the real area, not representing the current width

and height of this rectangle.

So that will seems like, OK, well, I've just got to remember to store it in two variables.

I can go ahead and do that, and at the time, that will seem like a good idea.

Then somebody else will come along and write a method like double width and height and you.

And they won't remember when know that area is a cache and needs to be updated every time.

Width and height is updated, so they just go ahead and naively double the width and height and think

everything will be fine.

It isn't.

Area becomes invalid every time this method is up is called, and that is how bugs are introduced by

cache invalidation.

Now, this is a trivial example.

However, in reality, these bugs get far more obscure and hard to pick up, so that's why it's really

important whenever introducing new variables that you think very carefully about all my caching something.

Could I just calculate this some other how?

Here are a few a couple of common signs that you can look out for just to save yourself the hassle of

introducing the caching in the first place.

If, if in doubt, calculate don't cache.

And even if it's not that efficient, you think it might cost you something in terms of efficiency in

the long run?

Trust me, it probably won't, and it will cost you in terms of bugs.

So a common thing to say is Boolean flags.

If if you've got a Boolean around the place, for some reason, Brazilians tend not to be tend not to

be state that there are some states, but for example, a common Boolean flag might be is jumping.

Could you not calculate whether you are off the ground instead?

Because then some other way that you could calculate whether you are jumping rather than storing a Boolean

variable about that, as probably it's probably the right state, you can probably in a lot of cases

with Boolean flags, you can calculate that from some other state.

So that's an important one.

Get components.

So this is unity specific when you have get components and store the result of that in a way you're

actually caching the result of that.

What happens if a new component is added later on?

What happens if that component gets deleted and a new one gets created?

Your cache, your pointer to that component will go out of date.

Now, this is reasonably safe in unity and probably one that you can ignore.

But just be aware that that is a cache that you're creating.

There is not necessarily.

If you've if you think of the state as being, what is the current component on this game object, you're

not necessarily going to get that.

You're going to get the component that was on the game object at a wake.

So that was a cache having to remember to update something in code.

So if you've got some function and you always find yourself saying to yourself, I need to remember

that that needs to be updated.

Then you probably have a cache.

Updating variables on callbacks is quite common.

One.

If, like on collision and on collision and on collision exit, you find yourself again update something

like a Boolean flag or maybe something else, you might find that you have got yourself into a situation

where you have to do that with callbacks because you are trying to keep a cache up to date.

It's not to say that all caches are bad and that you should never cache but avoid it if you can help

it.

Now on to the slightly easier, good naming.

Part of that quote?

Here are some good naming tips.

So typically, the measure of a code quality is w.e.f per minute.

Well, at least that's a nice way to think about it.

You want to have whoever is looking at your code.

Be confused as few times as possible when they're reading it, and that includes you in the future.

So you want to name things so that everybody understands what you're talking about us where good naming

comes in, it's all about good communication.

Ultimately, code is communication.

Something like this is terrible.

You've got an integer named T. And then in a comment, you're saying seconds since the event happened.

So second, since I did something like the character was shot or the character died.

Those kinds of things.

But you've called the variable T. So anyway, you're using this in the code.

You'd have to go and find this place where it's declared, find the comment.

You're going to go WCF.

What is this t about?

What am I supposed to do with it?

If you'd named it something sensible to begin with, like seconds since event happened, even if it's

a long variable name everywhere that variable is used, you will know exactly what it's for.

And it's going to be clear to the reader of the code, including yourself in the future, that this

was what it was meant to do.

General rule of a good practice is that classes should be named as nouns.

Avoid names such as manager, controller, processor.

It's really not clear what a manager does or what a controller or processor do.

They are kind of cop out names, in my opinion.

We add them because we don't really know what this thing is supposed to do.

It's an audio manager.

What does it do with audio?

What exactly is its purpose?

Is it an audio source?

Is it an audio player?

Things like that are much more meaningful than calling it a manager or a controller or processor.

So if you find yourself and I find this quite often that I want to call something a manager, stop and

ask yourself, what does it actually do?

What do I really want to call this thing?

Methods should be verbs, typically, so you do something with a method to a class, which is a noun.

So those are good rules to follow in terms of object oriented programming and be consistent.

Once you've chosen to call something something, use that term all the time.

Don't go switching between terms and confusing the heck out of somebody who is reading it something

like fetch value and then later having a get value in a retrieve value will leave.

People wondering is fetch different to get or is retrieve different to fetch?

You just don't know.

As the reader of that code, if you have chosen the exact same word, then you are sure that the same

thing is probably happening.

And finally, if you're not sure, go and talk to somebody else about how to name something.

You'll often find that they go, Oh, well, what you're talking about is blah blah blah, and they

know exactly what word you intended to use or so on.

I will often find that I have very lengthy discussions about naming something Well, we do this inside

the team very regularly will go and talk about like, what should we call this?

And we will spend 15 20 minutes talking about naming something very specific.

And that's because naming so, so important in communications.

So don't underrate it.

Spend time on it.

Good naming will save you a lot of time later on.

So there are going to be lots of challenges like this one in this course to share your own examples

from your own experience, because I think this is much more interesting than my clinical examples that

I can come up with on the spot.

So where have you used cash in your code?

Go and share in the discussions for this lecture.

Where have you cashed something?

Where have you ever had a cache invalidation bug?

Not everyone will have had this if you've been programmed for a short while, but if you've been probing

for a long while, I'm sure you have.

Can you point to any cases where you like done it?

I should have updated that variable and I forgot to, and it led to a bug.

What is your variable name of shame?

What is the worst name you've given to a variable function or class?

And let me know down in the discussions I would love to read and share my own there as well.

In the next lecture, we're going to be looking at the sources of spaghetti ification spaghetti fying

in your code, and I'm not talking.

About the kind of tasty sources I'm talking about, the points where they originate from.

Let's dive in to that lecture.