486

July 20th, 2022 × #JavaScript#CSS#TypeScript

Our Code Styles

In this episode of Syntax, Wes and Scott discuss their coding styles and preferences in JavaScript and CSS.

or
Topic 0 00:01

Announcer introduces Syntax podcast

Announcer

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talinski and Wes Boss.

Topic 1 00:11

Wes announces today's show on coding styles

Guest 2

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.

Guest 2

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?

Topic 2 00:54

Wes asks Scott how he's doing

Guest 1

Rid. Oh, I'm doing good.

Topic 3 01:04

Scott says he's good and has nothing to report

Guest 1

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.

Guest 2

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.

Topic 4 01:16

Wes says they're recording ahead before he moves

Guest 1

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

Topic 5 01:38

Wes talks about work needed on his new office

Guest 2

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.

Topic 6 01:52

Wes suggests starting with JS styles then CSS

Guest 2

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

Guest 1

functional versus object oriented.

Topic 7 02:01

Scott talks about functional vs object oriented JS

Guest 1

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.

Guest 1

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,

Topic 8 02:30

Scott likes functional for easier testing

Guest 2

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

Topic 9 02:51

Wes uses OO for tutorials occasionally

Guest 2

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.

Guest 2

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.

Topic 10 03:13

Wes gives timer class example for OO

Guest 2

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.

Topic 11 03:23

Timer class has start, stop, pause methods

Guest 2

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

Topic 12 03:44

Scott asks about TypeScript interfaces vs types

Guest 2

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

Guest 1

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.

Topic 13 03:52

Scott now uses interfaces over types

Guest 2

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.

Topic 14 04:36

Wes shows both in TypeScript course

Guest 2

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.

Guest 2

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.

Topic 15 05:10

Wes heard interfaces compile faster

Guest 2

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

Guest 2

People said that interfaces are faster to compile.

Topic 16 05:17

But compile speed not a reason to choose

Guest 2

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

Topic 17 05:27

Wes says it doesn't really matter

Guest 2

It means it doesn't matter.

Topic 18 05:29

Scott agrees it likely doesn't matter much

Guest 1

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

Guest 1

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

Topic 19 06:04

Wes explains tabs as one character displayed by editor

Guest 2

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

Guest 2

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.

Topic 20 06:24

Spaces argument is consistent indentation

Guest 2

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?

Guest 1

No semicolons.

Topic 21 07:06

Scott sees no need for semicolons ever

Guest 1

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,

Guest 2

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.

Topic 22 07:36

Wes says linters now fix semicolon issues

Guest 2

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

Topic 23 07:46

Wes uses semicolons and likes them

Guest 2

I like them. Big oof.

Topic 24 07:51

Scott strongly dislikes semicolons

Guest 2

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

Guest 1

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.

Topic 25 08:09

Scott asks about let vs const

Guest 1

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

Topic 26 08:13

Scott uses const unless reassignment needed

Guest 1

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

Guest 2

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.

Topic 27 08:35

Wes uses const and rarely needs let

Guest 2

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.

Topic 28 09:03

Wes likes block scoping of let and const

Guest 2

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.

Guest 2

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?

Topic 29 09:16

Scott explains var function vs block scope

Guest 1

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

Topic 30 09:43

Wes started with inferred but now explicit types

Guest 2

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.

Guest 2

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.

Topic 31 10:12

Wes says explicit types for exports, inferred internally

Guest 1

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.

Topic 32 11:02

Scott finds explicit catches more bugs

Guest 1

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.

Topic 33 11:36

Scott asks about naming conventions

Guest 2

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.

Topic 34 12:05

Wes likes kebab-case in HTML

Guest 2

I'm not sure why.

Guest 2

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.

Topic 35 12:20

Screaming snake case seems standard for GraphQL

Guest 2

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

Topic 36 12:49

Scott explains screaming case for constants

Guest 1

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.

Topic 37 13:00

Scott saw study on faster snake case reading

Guest 1

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.

Topic 38 13:14

Scott now uses snake case for everything

Guest 1

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.

Guest 1

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

Topic 39 13:36

Except upper camel case for components

Guest 2

You should get a snake case tattoo.

Topic 40 13:44

Wes jokes Scott should get a snake case tattoo

Guest 1

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

Topic 41 13:55

Wes mentions Wikipedia naming conventions page

Guest 2

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.

Topic 42 14:08

Wes lists alternate names like dromedaryCase

Guest 2

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

Guest 2

Camel case is also called dromedieri.

Guest 2

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.

Topic 43 14:19

Dromedary case is camelCase

Guest 2

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

Topic 44 14:31

Flat case is all lowercase

Guest 2

Pascal case is.

Topic 45 14:36

PascalCase

Guest 2

Underscores.

Topic 46 14:41

kebab-case

Guest 2

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

Topic 47 14:49

Train-Case

Guest 2

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

Topic 48 14:54

HTTP-Header-Case

Guest 2

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

Guest 2

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

Topic 49 15:14

Scott agrees it's fun

Guest 1

definitely a treat.

Guest 1

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.

Topic 50 15:53

Scott uses array methods instead of for loops

Guest 1

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,

Guest 2

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

Topic 51 16:17

Wes likes for-in loops

Guest 2

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

Topic 52 16:26

for-in allows async/await

Guest 2

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

Guest 2

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

Topic 53 16:32

for-in pauses for await

Guest 2

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

Topic 54 16:37

for-in works on objects and iterables

Guest 2

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.

Topic 55 16:54

Wes uses for-in instead of array methods sometimes

Guest 2

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.

Guest 1

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

Topic 56 17:12

Scott rarely needs for loops now

Guest 1

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.

Guest 2

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.

Topic 57 17:53

Destructuring is nicer than index access

Guest 1

Yeah. No. Thanks.

Guest 1

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

Topic 58 17:55

Scott reminisces of past for loop pain

Guest 1

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

Share