Code Style

[00:00:00]
>> So, we've now arrived at the build process milestone. So, if you didn't get something or you fell behind or something like that, the build process milestones, the build process directory, instead of that Git repo that I had to clone, all the files will be in there. There's also a link in the course notes as well.

[00:00:18]
So everything should be working there. And so if we go to Project Fox Game here, this is the website, we just finished build process. So we were down here if you click this link here, this will take you to the part of the repository with the build process.

[00:00:34]
So this is kind of the state of where we are at the moment. Okay, so we are going to move on to code style. So if you've watched my other courses, you can quickly figure out that I'm pretty passionate about automated code quality. I have the mantra that that which is not automated is not enforced, like if you ever have been working on a professional project is big tendency for people to come in and make nitpicks.

[00:01:00]
And I actually got so passive aggressive about that at my previous company that I wrote a bot that if you put a comment on my pull request that said nitpick it automatically closed your comment, because I think it's dumb, right? I don't believe in nitpicks. If it's either a code quality issue and I should fix it, or it's not an issue, and you shouldn't say it, right?

[00:01:21]
Not necessarily shouldn't say it. I'm all about teaching and collaborating and things like that, but if you're telling me that I have two equivalent things and you prefer the other, I don't care. So that's why I believe that you need to automate things, right? So if you have something that you feel passionate that should be enforced in your code base, either write an automated rule that enforces that or don't write it, or just don't do it.

[00:01:47]
Having worked in front of infrastructure before, like I feel pretty strongly about these kind of things. And I feel like any time to introduce rules like that, like let's say you have to, you're not allowed to use arrow functions in JavaScript or something like that, right? Anytime you do that you're creating artificial friction for your team, for your project, for anything like that, and you need to take care of when that's useful and when that's not useful because you're intentionally slowing down your team to adhere to some set of rules.

[00:02:20]
And you better make sure that those set of rules is worthwhile. So if something like outline arrow functions like, is that worth it? Like if my brain thinks an arrow functions is it worth kicking me out of how I think about things, the answer to that is no.

[00:02:36]
That's a terrible rule and don't put that in your code base. Developers have a pure idea of how they want to solve problems in their head and anytime that you modify that, you're introducing friction, you're slowing them down, you're making them enjoy their job less. Like there's a bunch of stuff there, so make sure that any rule that you add to your code base is worth it.

[00:02:53]
This is why we have tests, this is why we have Linton, this is why we have creating and code formatting. All these stuff is to automate away a lot of these problems, but just be cautious. Be cognizant, be intentional about the friction that you introduce to your team, to your projects and that kind of stuff.

[00:03:13]
So, the reason why I like automation is because it presents immediate feedback to someone. So if I write code that's wrong, that's either not gonna work or has a problem with it or doesn't match our code style, the great thing about these tools is that you can present immediate feedback.

[00:03:27]
And I can get like a little red squiggly line inside of my project that says this is wrong, fix it right now. And so that, I'm still in the same code flow I'm still have everything in my mind is like, cool, that is wrong, fix it really quick, and I move on and it's not a lot of friction.

[00:03:43]
The problem with like nitpicks, and PRs is that I wrote code, I finished writing the rest of the code, I committed it, I pushed it, I marked you on a PR and then like two days later, you look at the PR and you come back to it. When I say PR, I mean pull requests on Github so it's like when I'm trying to merge code into Github.

[00:04:01]
After that span of like five days since I wrote the code, I have to go regain all the context of what I wrote and then try and fix it. So it's a very, very inefficient and frustrating process. That's why I don't like these nitpick things like PRs are really great and PR reviews are really great for big things like, hey you wrote this code, we actually already have that code over here and we can reuse it over here, things like that.

[00:04:26]
Pull Requests are perfect for to make those kind of comments but like, hey, you named your variable in a way that is minorly offensive to me is like, fine I don't care. That's my rant on code style. I don't know why I necessarily had to say it here, but I had to.

[00:04:41]
You're all starting out and I want you to be thinking about these things like code style is important but the most important thing is like, the best code is code that exists, right? And if it doesn't exist, then it doesn't work obviously. So, all right. We're gonna get into some code style things and I kind of split code style into two different kind of things.

[00:04:59]
One is like, code formatting and one of them is like the style rules of like linting and stuff like that. So we're gonna start with code formatting because it's more mechanical and it's easier to solve.