Our Code Styles

Welcome to Syntax, the podcast with the tastiest web development treats out there. Today, we've got a pretty fun one for you. It's on our coding styles. We're gonna go through all different coding styles of JavaScript and CSS and how do you write things. We'll do the rid. The the silly ones, tabs and spaces. But we'll also get into a lot more, rems, ems, and pixels. How do you make something 100% height? Rid. Some pretty cool stuff. And Scott and I will go back and forth and sort of explain our approach and our thoughts rid behind all of this. We are sponsored by 3 awesome companies, FreshBooks, Cloud Accounting, Sentry, Ericksception Performance Tracking, and Sanity.

Rid. They are the content platform for your next website. Check them out, and we'll talk about them partway through the episode. How are you doing today, mister Talinski?

Rid. Oh, I'm doing good.

Yeah. I got nothing to report. This is, like, the 5th, 6th episode we've recorded today. Rid. Yeah. Yeah. You know everything that I've been doing.

Yeah. I, we are recording a whole bunch trying to get ahead. I'm about to move, so we're trying to get at least a couple of weeks ahead so we can take some time off and work on the house a little bit. So excited about that. Yeah. Yeah. That is really super exciting.

I am pumped for you, especially to see, what you make of your new space. I think that's going to be really cool. Yeah. Yeah. It should be pretty fun. There's a lot of

A lot of work to do in my office. I have to build an entire office, but I think it's going to be so sick by the end of it. So stay tuned for that. We'll have some shows on it. Rid. So sick. Let's jump right into it.

Should we start with the JavaScript focus stuff and then get into CSS after that? Sounds good to me. Alright. You you kick it off there. Okay. So

functional versus object oriented.

I find myself Programming almost entirely functionally where I'm not using classes. I'm not, using even, like, classic JavaScript objects based, o o p or anything like that. And I'm just I I for some reason, it makes it easier for me. I think the biggest thing For me, that makes me want to type more in a functional manner is testing specifically.

It feels way nicer for me to just test A single function. Right? Single input, single output, test it, make sure it works. And to me, that was, like, the killer feature was just how easier my code felt to rest. So I primarily,

code functionally. Yeah. Me too. I would say 90% of the code that I write is functional.

Every now and then I'll dip into object oriented stuff, especially my tutorials, is I don't want to I do lean a little bit in the functional direction, but I do like Show people object oriented as well, especially because people that are taking away tutorials are sometimes coming from object oriented language. Like I had one the other day where I needed to have a timer.

And I needed to be able to start and stop and pause that timer. And I was like, this is actually this is a pretty good use for a class because you create a new class, you create a new timer.

That timer can have Like intervals. And so it ran every however many seconds. And then it needed to pause that whenever I wanted it. So I just had a timer and it returned a new timer. I could run Stop the start and the pause methods right on top of it.

But past that, especially when you get into these these frameworks that are pretty functional as well.

I tend to lean towards functional. I find it much easier to test. Yeah. That's really it for me. What about in TypeScript interfaces

versus types? I've primarily been writing types, but now I think I have moved over entirely to interfaces just because of The more functionality it feels like you get with interfaces, whether that's extending them or or it just feels like they're easier to work about in. Like, I had to create a bunch of, like, utility types to spread types and do all sorts of stuff that I wouldn't have to do with interfaces.

It's hilarious they say that because I was on interfaces by default and type when you need it. And as I've been building my TypeScript course, I've been kind of been like, well, A type would work in. I have a really good video of like the tiny little edge cases here and there. They one's better than another.

Rid. But I was like, Oh, well, types types make sense for a lot of the use cases as well. So I used to default to interface and then use a type when I need it. And that is the rid. Recommendation from TypeScript themselves. Mhmm.

And but then I find myself saying, like, well, rid. If I want to do like a custom alias or something like that, I do a type. And, so I don't know where I'm at with that right of them. I've just kind of been going back and forth between them and not because I'm wishy washy, but because I want to show people that you can do it rid In in either way.

But the maybe when we did the 1st TypeScript show, I am less confident on my answer of interface first.

People said that interfaces are faster to compile.

I don't necessarily know if that's a reason why you should use interface over a type. But if that says anything.

It means it doesn't matter.

I know. Yeah, I just I have a hard time necessarily.

I don't know. This does feel like the grass is always greener a little bit, but I don't think it necessarily matters that much. Yeah, exactly. Exactly. Next one tabs versus spaces. Where are you at with that right now? I am in tabs because I had a very convincing argument that tabs are more accessible, but There's, like, 2 people using my code base, so does it necessarily matter? I don't know. But I'm using tabs just because. Yeah. The The argument of tabs is that

a tab is 1 character, and how that is displayed in your editor is up to the end user.

That is an editor value, right? Like you could you could make a tab a 1000 pixels wide or you can make a tab 1 space wide. Rid. It's up to you. It's just 1 tab. And that that's actually a really good argument.

And then the spaces was spaces kind of comes back to Where people were like, well, 2 spaces, 4 spaces. I use 2 spaces myself, only because I try to cram as much code as I can. Not cram, but when I'm coding, I don't like it when I have my code goes horizontally off the off the thing. I don't mind it when I'm coding, but when I'm doing videos, If it goes if it makes a horizontal scroll or it wraps, that's very annoying to people watching. So I'll try to do 2, but it Doesn't really matter at the end of the day. I think with a lot of these, it doesn't really matter. But the next one does matter. Semicolons or no semicolons, Scott?

No semicolons.

I don't know in what universe I would ever need a semicolon. I'm kind of passionate about this one. No. I I don't care. The there's the like, the arguments against semicolons is there's, like, a 1% use case where a semicolon becomes important. But guess what? Yeah. In that use case, Prettier adds it for me or ESLint. I don't even know which one because I don't think about it. Because when I save the file, it automatically adds the semicolon in the one instance in which it needs And, other than that, I just don't need them. I don't need I don't need them polluting my,

my eyes. A lot of, the arguments That we have used to have are now solved with well, Prettier fixed that for us. So it's no longer an argument.

It just rid. Fixes it for us. I do use semi colons all the time.

I like them. Big oof.

I like them. They're great. Rid. Can't can't I can't code without them. I just like seeing them in there.

And that's that's all I got for you on that one. I really don't like seeing them in there. If I see them in there, it makes me upset. So I need that.

Oh, man. That's good. Next This is let versus const.

You know, I'm using const for everything unless it gets actually redefined, and then I will use let, but only because I'll start with constant, then I'll say, oh, wait. I actually need to change this variable. I'm gonna use let. And that's mostly again, that goes along really well with the functional Style of programming for me. So, yeah, I'm using const. Yeah. I do const by default

and if I need to explicitly change a a value, Which is very rare because, like the situations where I would need a let is if you have a boolean you need to flip.

So I just use const and that allows me not to ever have to overwrite like an object or anything like that. Because with const You still can change properties of an object. And in most cases, that's what I'm using. So default to const and then change to let when I need it.

And never use var. Not because var is deprecated or anything like that, but I just like the rid. Block scoping of let and const. Yeah.

That's really the way it is for me. Yeah. Whereas var is we should say var is function scoped, Not block scope. So anytime you have a set of curly brackets, you can think of them as a fence that are keeping your let and const values in. Whereas very var variables will leak outside and that's kind of annoying for, like, 4 loops and and whatnot. What about, for TypeScript?

Do you, Explicitly type your things, or do you allow TypeScript to imply

some types? Because That's a good one. I started out Using the implied types quite a bit and just letting TypeScript do its magic, but I found some bit of rid. Comfort in just, like, explicitly typing everything. Yeah. I I can see what you mean by that because it's very easy for Something is implied based on something else and that something else is implied based on that. And then you change one thing and it could ripple through your code base without you seeing that.

I will use and I got this answer from asking a lot of people. Do you is it okay to use implicit types? Implicit types For internal code, anything that is exported and used as as as an API or used as a function somewhere else in your code base Should be explicitly typed. And I don't even know if there's like a lint rule that would say, if this value is rid. Exported, you must explicitly type it. Wouldn't that be kind of a cool linting rule? That would be kind of a cool linting rule. Yeah. Yeah. I think I'd like that. So yeah. I I think that's a good way to go about it. But You certainly can go a long way with implicit types in TypeScript. And it's very, very handy, especially if you are like, And you change the turn type of a function that you don't have to explicitly go in and change it yourself. It's just implied. Right? Can be very freeing.

Yeah. Yeah. It's it's Sometimes it's nice to I mean, in terms of, like, catching bugs and stuff like that, always making sure that everything is rid. Typed for me has found some instances in which I thought something was implied to be something, and it really wasn't, without me having to, like, hover my mouse over and being like, what is this implied to be? And the TypeScript will just complain. That's true. That's a good point as well. What about Naming variables. So, camel case, upper camel case, kebab case, snake case, screaming case snake.

Oftentimes, people use screaming snake case for, like, constant variables and things like that. Do you have any rid Specific rules, are you doing one thing, everything one way or whatever? I in JavaScript, I will default to camel case.

In CSS, rid I go between it's per project I go between Kebab Case, which is dashes, and Camel Case. Rid. For some reason, I tend to like the look of Kebab case a little bit more in CSS and writing in HTML.

I'm not sure why.

And then I don't use snake case unless it's by convention. And that convention is often in GraphQL rid There is a mutation seems to be better.

I don't know why, but uppercase with the screaming snake case, that's all uppercase With underscores in it seems to just be a convention for GraphQL mutations and or like, Like a Redux reducer will often be named like that as well. And for some reason, I like that convention because you you look at it very quickly, you know exactly what that thing is. Yeah. People use screaming k is the reason why that is that way. Screaming snake for constants

is is really the the way that People do it. So it's like you have, like, for your mutations or your actions or whatever, those are string constants typically, which is why you'll often see that that way.

So that that's like one of the reasons why people do this. And, you know, Rich Harris posted a like a a study saying why he uses snake case Showing that you're, like, your your brain can perceive it faster. You can read it easier. Interesting.

I've started, like, going all in on snake case because of that. Rid. And, you know, I'm just you know, it's it's the Svelte Svelte thing to do. Right? But I started using Snake Case, and I gotta say, I Love it. I use snake case for everything now. I use snake case for CSS. I use snake case for everything except for, rid.

Components. Components, I do upper camel case. But everything else, snake case all the way, baby. Yeah. Snake case. Wow.

You should get a snake case tattoo.

I know. You know what? I like snake case even more because of the name of it. If it wasn't called snake case, I might not as be

rid. We've talked about this before. There is a Wikipedia entry called Naming Conventions rid. Programing. We'll put that in the show notes for you. And it lists all the types.

Snake case is also called rid. Pothole case. No.

Camel case is also called dromedieri.

D r o m e d a dromedary case. What's a dromedary? Yeah. You might wanna know before you. It's also known as a dromedary camel, Arabian camel or 1 humped camel.

Why would you? Why would you call it true? Maybe in flat cases, all lowercase.

Pascal case is.

Underscores.

Kebab case train case is Traincase is uppercase with a kebab in it, but screaming kebab case is also that.

So there's some pretty fun Oh, HTTP header case. HTTP.

HTTP header case is dashes with capitals on every word, which makes sense because that's what headers are.

Cases. Yeah. Uh-huh. Cases. Yeah. We've every every I think what the year we get into this, what are all these other things called? And that's It's a treat to look at it. It's kinda fun. It is. It's a treat. Yeah. It's a it's it's

definitely a treat.

Next 1 is looping for each first Or in or just loops in general. And I almost find myself using array methods to do any kind of looping nowadays. And it's just Just because of I I've gotten so used to it. I'm so comfortable with it. I almost never reach for a classic for loop anymore unless I don't know. When am I reaching for that? There are times, but it's, like, very much not often for me. I'm usually having an array, and I'm doing something to that array And over the contents of that array. So that's why I'm using every method for each or map or anything, reduce whatever.

So I I guess there aren't too many times where the code that I'm writing in my UI code or or any of that stuff is having to essentially rid. Do something for X amount of times that's not based on an array length. Yeah. Yeah. I will default to using an array method, most likely for each,

rid. Unless you actually need to modify the data. In that case, it's a map or a reduce.

But I am a big proponent of the for in loop Because the for in loop can be awaited inside of it.

So if you have an asynchronous function that you need to do inside of that, you ready.

You can await inside of that and it will pause that loop from running. That's really nice.

The for in loop will allow you to loop over objects and other iterables.

The for in loop will allow you to skip an iteration with the continue word and you can rid. Stop that loop from running entirely with a break clause.

So those are the those are the situations where you say, ah, let me stop a second. And rid. And instead of using an array method here, let me reach for a for in method or not a method, a for in loop.

Yeah. I think that's probably the times that I'm reaching for them specifically.

It's like if I have to do anything like that, then I'll say, okay. Let me Let me pull out the old loop here.

Yeah. And same with, if you want to loop over, object entries, An object that entries will give you an array, and each item in the array will be the key is the 1st item And the value is the 2nd item. And that's really nice because you can destructure that in a for in loop. I guess you can destructure that in a regular for each loop as well, though. But it's a really nice experience rather than having to do the remember the square bracket I where you reference The index of it, that was a pain in the butt. It's much nicer to have proper variables.

Yeah. No. Thanks.

No. Yeah. That's true. Put me back into a place of programming that I haven't done in a while. You know? Yeah.

Four loops were a pain. Yeah. For you naming oh, no. Next would be if statements