It's pretty apparent when you open up somebody's project and it's a hobby or they're just starting out and they don't know how to improve their code.

Make it so that it looks professional.

It looks readable, maintainable.

These are all going to be things that I've picked up as my years as a developer, but also that I, you know, I can't take credit for most of them because, you know, I read books and I do courses, and I'm going these from people with many more years of experience than I have.

So what does it mean to have professional code like what I mean by that?

Well, I want to give ah sort of analogy to explain it.

Ah, la times when you're getting started, all you really care about is does your code run and does it deliver the features that you're you know, the client wants, does it work?

And it can.

And I'm assuming it does in both situations where you're writing professional level code and then you just writing some code we're getting getting started and learning.

Um, it's sort of like comparing a treehouse to the homeless.

I feel like it like there is something that's going to last the test of time because we have written it in such a way that it's going to be maintainable and easily updated.

And then you have a tree house, which is going to slowly get worn down because we didn't build it in the proper way.

Um, both our shelters, one's going to outlast the other.

So what makes clean maintainable code?

Well, we're gonna be talking about a whole slew of things in this series, and we're actually going to be giving specific examples, not just like, hey, you should do it this way.

We are going to tell you how to do this way and why, But we're also gonna give coding.

Examples were going to say OK when I say variable names need to be descriptive and how what does that mean exactly?

And how can we showcase that our code will be now more readable by using something like object or a raid e structuring, for instance, to get us going here and see actually see in our in real time how we can take this set of code.

And now we make it this set of code and it makes a whole lot more sense.

So we're gonna talk about code readability.

You don't write code for yourself or the client even.

I mean, you do because they're cutting the checks, right?

So But the reason the not the reason.

But one of the reasons that you write code is you write it for the next first asked to maintain it, right, the average deficit job, two years or something like that.

And chances are that project's gonna outlive you for a very long time.

And so you need to make sure that you're writing the cleanest code possible, the most maintainable coat.

And to do that, you have to write readable code.

So what is limping to those of us who are new?

The concept?

Well, lynching really is two things, and these they're always Whenever you're incorporating a tool, you have to answer what I call the Big Two.

The what and the why.

So what is a letter?

It is a tool that you set up essentially one time, usually per project that will flag Ares programming.

Ares bugs die elastic Ares Ah, and suspicious constructs.

What does that mean?

It's basically gonna catch Syntax airs.

That's it.

It's going to find out if you're making simple mistakes in your code where Hey, you're declaring this here outside of its scope and that's gonna break job script is one those languages where sometimes we don't find if that happens until we work our way through the application.

So lynchers give us the opportunity to find those airs earlier and more often.

It also adds the readability.

What that means is we're going to make sure that we are code is formatted in such a way that is the industry standard or is a standard for that language that programming items.

And that's why so it's gonna catch Ares syntax there, sometimes more than syntax Ares.

It's gonna have trouble catching logic ares, But But, ah, that's that's usually more so.

Developer issue won't talk about howto catch those later on this, saying it's something that can also be automated so you don't have to run it every time it's just there, and we'll start picking up good habits by just sort of being trained by the winter to a degree, um, and this will lead to more readable code.

Ah, less prone, less bug buggy coat.

And I will be writing in better standards because of it.

So let's go ahead and jump into an example.

All right, So what we have here is a typed her file, which is just javascript.

It's a super set of JavaScript.

And what we're going to be looking at is, you know, immediately because he didn't intend this file to be typescript.

We have some air, so I'm not too worried about that right now.

Um, we should have some worries, but, uh, you'll see here, this is before return the lint err on, by the way.

And so what's gonna happen here is we're gonna go ahead and turn the lynch around and see Hey, let's take this file.

Um, from someone just getting started and see how we could just clean up our code to follow the standards.

And, uh, don't worry about the setup of letters.

I will include, as I mentioned to videos, but I'm gonna go ahead and turn the letter back on and reload the app.

And what we're going to see here is quite a bit of difference.

Uh, supposed todo there guess just a little bit of a hiccup so you can see that now there's something wrong with pretty much everything in this file.

And, uh, this is so where lynchers excel at is catching those small heirs that are semantic in nature or that are, you know, we want to anything that we can compare that they're not logic based areas.

There are structure airs.

They are formatting ares items like that.

And so what you'll see here is that the standard for comments, for instance, this have a space between them and so that's something we can fix.

You'll see here that in modern Java script, you know, the VAR keyword is essentially forbidden.

And that's what the word they use and you'll say, OK, this is something that we have decided that, you know, use letter constant.

So for the time being will go ahead and change all the bars here and there's quite a bit right.

There's quite a bit to let so change that let go ahead and replace all of those far, so we may have to change some of them The cons.

You also see that we have her over this, That she s Lane is saying, Hey, on average, you can use you should be using double coats.

This includes That's kind of a silly one.

But, um, you can change that, depending on your preference.

But I think the more important point here is that you see double quotes here sing quotes.

Here is we want to have a set standard of what it is we're doing.

You shouldn't have multiple ways of how you do things like this in your code.

So let's go ahead and replace all the single quotes with double quotes.

You can see how we're slowly going to make this file.

Just look a little bit cleaner.

Um, this isn't something that's there that winter would do.

But from a personal standpoint, I would say that that, um, you know, you want your coats faced out evenly as well.

When we're getting started here, your coat needs to look like you cared.

That's really what code readability means as we're going through here.

So we'll go ahead and put a space here, but its face here and there's gonna be other things that we're gonna want to do this file as we progress.

But we just want to make it a little bit more readable.

And we could do this in just a few more steps.

Um, any time you'll have commenters code in here as well, you go ahead and remove that.

There's no reason to have that.

So right now you're going to the fire.

We're doing these minor changes.

A lot of this will be syntax stuff.

Some of it's important, right?

We're using a lead instead of a concert.

And there's there's hundreds of rules when it comes to this.

And so what you end up picking up are these good conventions, these conventions that say, Hey, what makes a good?

What makes a what makes a good clean code?

Because that's really what a letter is there for, um, for what it could do in that aspect, and you'll pick these up.

Just her habit, your habit.

So what we've done is now we have made our code just using the winter, and there's still some areas in here and that we'll talk about those in later section, but we have been able to make our code much more readable, much more understandable And to the latest standards and in terms off just basic t s lint, things and winters to get going so laters air here to stop those syntax mistakes lynchers air here to get you to code in a certain manner in a cleaner manner in a more readable manner.

And they're the first step to writing cleaner, more maintainable code.

This will be the more of the hard cut like this is the only tool the rest of the stuff we're gonna be talking about.

This is stuff that you have to learn that you have to implement and one thing about letters, and in our case, we're just using T s lent.

But one thing is that you have the ability override rules because they're not absolutes, right?

Don't live in a world of absolutes, but these always help to get you going.

These always help to get you started, especially when you're just getting started to writing cleaner code and in especially in a job script environment, where this is kind of a newer idea when you're getting it going and no one maybe has told you about it, which is kind of occurred.

Me, like this is where we should start.

We're gonna be talking about how we can define our variables and use them better.

Thio accomplish a couple objectors, right?

We all want to be ableto write software like a professional.

And these were some of the items that you need to keep in mind when you're using variables as well as defining names for variables.

So what is that gonna accomplish?

We're gonna have three objectives.

By the end of this course, you're gonna write code that it's more searchable, readable and understandable.

There's a lot of bubbles there, but this is what our objective is here.

And we're gonna talk a little bit.

About what?

Those How we're gonna accomplish those objectives now, these are just some of them, but we're gonna be diving into other things.

Well, we're talking about falling language standards, limited scope of variables.

We're talking about creating new variables, verse, reusing them, eliminating magic numbers and magic strings and items like that in general, we're talking about naming burials, spent a good portion of time talking about that, about choosing a name that describes what a variable does or what its purpose is not how it does it.

And then we're gonna talk about what I call the, um this relates to naming the variables what I call the parent or significant other test will dive into that in the code examples we're also gonna talk about when we can use long names for variables and when verse short names and you know, some of the you know how we can incorporate that into her coat and more.

Some of the and more sections we're gonna talk about is the practice is that a lot of people do that we need to break right.

Um, you're actually causing more harm than good.

And those are some of the examples we're gonna give.

So I'm not one that really like looking at at slides.

I learned from the code.

Let's go ahead and dive in.

All right, so let's start with a couple different things here.

Here we have a simple algorithm to return a factorial of a number.

It's not important about the code.

It's not important that's in Java script.

But the important point here is there's a couple things that we can fix immediately with our variables.

One we can start following the language standards, right?

This is something that's very simple and immediately going to be a parent in Java script, for instance, you would never ever have something in all caps unless you're dealing with a constant and an actual constant meaning and stuntmen object during a ray that you're gonna be modifying.

But this is something that we need to keep in mind at the very least because before we can get get into the higher level things off.

Hey, we need to be able to thio understand how to write good variable names this week.

We have to just understand how to write variables.

We have to write this to our standards.

So we're gonna use our camel case, lower case camel case, which is the standard here, and go ahead and fix this.

All right.

The next thing that we need to start thinking about is can we eliminate variables?

The less variables, the better.

And this is actually some code I wrote from, like, three years ago.

So, um, you don't think that, you know, everyone writes bad code, and we all improve his welcome songs we put effort into, but can we eliminate things.

This is something that we need to start thinking about because it's rather important.

And the less variables we have to maintain, the better.

So in our example here, we can actually eliminate this count variable altogether.

There's really no reason to have it.

And you'll see here.

Okay.

What are we doing with it?

Were saying zero.

Okay.

Can we eliminate it?

Well, yeah.

Goes number here, which is just a number.

And this is typescript, right?

And we're expected return number here.

Just provide some context.

But count isn't counts.

Doing nothing.

Count is doing absolutely nothing for what?

We need to do it here.

Is it performing anything different than number?

No.

Then what we can do is we can't just eliminate it.

There's no shame in eliminating variables when needed.