Hot Takes + Bike Shedding

Welcome to Syntax. Today, we've got a bike shedding hot takes episode for you. This is where we're gonna go into those questions that don't really matter, but kinda do matter. Like, the Wes like the the typical one I run always argues over is tabs versus spaces, and and we'll talk about that. But this we got some much more interesting ones, and we're gonna go and and pick a side and try to argue our case on each one. My name is Wes Boswell, a developer from Canada. With me, as always, is Scott Tolinski. How you doing, Scott?

Oh, I'm doing good, man. Man, I had a productive weekend cleaning.

I spent my, like, whole holiday weekend that we just had for Labor Day. I was cleaning the house. I repainted all the trim because it's so dinged up. Like, I I got a paint bucket. I'm getting all the trim. I filled in the dents and stuff with spackle.

I'm like phone. I I use this, a little, like, you know, those little plastic pry tools? I use one of those to get into the cabinets with a, paper towel and clean out all of the little gunk and stuff. Like, I detailed that thing, man, and I had a I had a blast doing our house.

Steamer. Yeah. You have a, like, a steam wand or something like that? We we got one of those for at our cottage. We always get, like, flies and, like, even on the on the trim. Yeah. And we got, like, a little steam wand, and it gets in all the cracks and stuff. It's good stuff. That JS, something I don't know anything about. Mhmm. Alright. Let's get on into the first one that we got here. This is in CSS.

When you're naming your variables, do you name them after the color that they are, like dash dash red, or do you name them after something like primary, secondary, base, border, things like that? Like, what more of what they would do in your application.

So what I'm going to put myself I I made these questions up, and I'm actually not sure, right now. I think I going to tend towards the the primary side of things. I will have a variable of of my colors, but then what I'll do is take primary and assign it to red because I've gotten in many many troubles before where I have a variable called yellow, and then it's it's no longer yellow after you change it because it's like the button background color or something like that. Node. Yeah. I I would say if the app

has one color scheme and one theme and it's never going to change from that, I am using the color names. Like, on the Syntax site, things that are yellow are yellow. They're not primary. Right? Like, it it doesn't make any sense. But if I'm building an app with theming or I'm at building an app that has a lot of different colors, I'm I'm actually mostly primarily using the primary type of flow. That is the standard way I do it unless I am feeling lazy. And then I'm gonna make the color. Like, every site you're making probably has at least a light and a dark mode, don't you think? Yeah. Does the primary color change, I guess, between the two of those? Yeah. But I guess I guess you could just switch

like, would you make a variable called dash dash text or or foreground, or would you just simply just say, like, in dark mode, make the text white, and and in light mode, make the text black.

Yeah. I mean, I kinda do that. I I use color scheme as a CSS property, but I I do tend to use f g and b g for the text versus the background. That makes most sense of Vercel variable, then have to, like, reselect

elements, things like that.

Yeah. Alright. Do you prefer snake case or camel case? As JavaScript developers oh my. Wes has brought a new head in here, and it's larger.

I prefer snake case myself. Wes, what do you think?

Man, all of the arguments for snake case make so much sense. I just have not made the switch myself. I've been in many projects before, the Syntax website themselves where we use snake case, and it makes a lot of sense.

But I simply am still on team camel case for most of my projects by default.

Yeah. Team camel for sure. I mean, I I personally man, snake case for me all the way.

Not only do I think snakes are cooler than camels, I just tend to, read this so much better when I'm looking at my Node, and I certainly don't mind the fact that I'm the only one writing snake case. Node I don't mind the syntax of it and being different. It also another thing that it helps me differentiate between is things that I've written and things that are like built in modules and stuff. I know some people would see that as a negative, the fact that many of the language built in things are camel case and that your things are snake case, but it helps me read, and it helps me stay organized.

Snake case all the way for me, folks. Alright. When you're writing JavaScript,

do you prefer to export default from a file? Like, you have one file, and and there's one main thing that happens in that file. Do you prefer export default, or are you using export, like a named export from that file, and why?

I am almost always going to export named because for me personally, it is so much more predictable, reliable, extendable.

If I add another module to this file, I don't have to worry all of a sudden about changing anything else in any other file. To me, it makes the most amount of sense, and I will use this 100% of the time.

Yeah. I agree.

Unless I'm I'm using something where the convention JS, the main thing exported from this file, like like routing. Right? Like, you have, like, a index dot TSX in a specific route, and the main thing that you export from that will be your your layout or your page. Otherwise, if you Yarn importing that anywhere in your application, I'm going named export all the way, and I find it much easier to have the auto complete import. I find it much easier to rename things. You know, if you're refactoring code with a with a default import, it's kind of annoying. So I'm on team named export all the way.

Okay. Do you prefer barrel files or importing directly from the file itself? A barrel file is when you have an index file at the root of a directory, so therefore, you can import things essentially from the directory itself. It kinda scoops up all the exports from the exports from the files and then reexports them into, so you can import directly from a directory. Which do you prefer to do? Man, I, a 100%,

don't like barrel files because I find it's just another file to make. I don't like any of the magic of having to explicitly import from, like, a directory and just assume, like, an index file inside of there. I don't even like importing without, the extension on it.

ESLint in all of mine. I just wanna be as explicit as possible. I think the whole require Node. Js lookup tree is very complicated, and it's a huge pain once you're switching different environments. So very much of just put it in a file. Even if I have, like, a file that is named, like, format money and I'm putting that in another folder of the same name, I'm totally fine with that. I I much prefer that over just like an index dot t s in my project.

I am going to say I agree, especially because I think that, like, earlier in my career, I thought the it was a style over substance for me. I thought let me make you come out of I'm gonna come out of your ear here. I thought that, specifically, it would look so nice to have to look so nice to have just the import from a directory. But I didn't necessarily think about the logistics. I didn't think about, tree tree shaking, code splitting, those types of things warp, like, you're really trying to reduce the amount of things anything loads at any given point. Like, I shouldn't have to load every single file from a directory when I'm importing from one directory. I shouldn't have to if I don't need to. So for me personally, it was definitely a style over substance thing. And once I was just like, why am I doing this? Like, what am I getting out of this and taking a look at it from a more objective point of view? I realized

there wasn't any single good reason to do it, so I am not doing barrel files. I think the one good reason is if you are, like, publishing a library where you want one like, all of your APIs that are going to be explicitly exposed to the user is is what you're gonna be publishing. In that case, a barrel file works. But, yeah, all the tree shaking stuff, that that's all been fixed in all the bundlers, so I don't think it's totally necessary anymore. It's just more hunting around trying to find what you want.

Oh my god.

Do you prefer a function declaration or a function expression. And the the difference between those two are a function declaration is where you write the word function and then the name of the function and then the whole signature, and a function expression is where you Yarn sticking a function into a variable. And this could be an arrow function. This could be simply just saying Scott do things equals a regular function.

They are different in how they work given the way that hoisting works.

But other than if you understand how hoisting works, they are I don't know. For a while, we saw a lot of people just doing the the function expression, sticking an arrow function in a variable, but I am very much of the mind that a function declaration is the way to go. I I'd much prefer that. The only pain in the butt is that with TypeScript, the hoisting problem bites me in the butt, and I have to often do like, if you wanna check if a variable exists, you have to do it in every single function.

But other than that, I'm much I'm a big fan of the declaration.

I am a big fan of function declaration as well. I just feels like it makes less sense to me to make a variable.

This is stupid because so many of my decisions are aesthetic and ergonomic based. But to me, it feels like it makes less sense to just declare a variable to equal function Wes it's like, we have a keyword for that. Function is the thing. It's a it's the function declare like, just do it that way. That it just feels unnecessary to do it any other warp, personally.

Do you prefer, Wes, inferred types in TypeScript or explicit types in TypeScript?

God.

I'm running out of these fun ones that I made. I should've spent a little longer working on them. I used to be on team infer quite a bit, because when you made changes up your tree, it it sort of, like, filtered its way through much more easily.

However, I find that with AI, it's often better to have more explicit types.

So I've sort of landed on, like, two things. One, is this an external API that will be imported and used somewhere else in it? If I am going to be importing this function or this API somewhere else in my application, I'm going to make that explicit. And then two, if this is something where AI is is is gonna need a little bit of help in that, I will also make it as explicit as possible. Otherwise, I'm I love leaning on inferred types.

I find them very Sanity. And and some TypeScript, even if you use some of these libraries, like a lot of the tan stack stuff, it's inferred all the way down. You're not actually writing any types yourself. It's just inferred, inferred, inferred, and you just have full type safety all the way down. So I'm gonna put myself maybe in the middle of that one given that I I will be explicit when it's necessary.

Wishy washy here is what you're saying. You're you're a flip flopper. I'm going to put my flag in the sand on explicit types. I'm talking we're talking, parental advisory here. That's what I like to have here for explicit types. I'm dropping f bombs at my types. No. I I personally think that it is for somebody who likes things so streamlined, this is one of the absolute things I do not mind being verbose on. It makes things crystal clear. To me, it, like, clears up anything. It it finds little bugs. Yeah. You could say, okay. You know, your function returns, this, and therefore, having that be inferred, that makes a lot of sense. But for me, if I'm writing code, I can write the inputs and the outputs first as types, and then I can write the function, and then I can know if there's anything potentially in that function that would cause an issue there. Like, it's it's stopping me from writing potential bugs. Now granted, you can just not write those bugs in the first place, whatever. But, like, I like it being explicit personally, and I certainly do not mind having the extra bit of text in my files. Let's talk about Sanity real quick. Absolutely hilarious. The sentry.i0

website now has a two things that's hilarious. So the new tagline is someone's gotta babysit the bots.

So if you are working on anything AI, things will go wrong, and you're gonna need Sanity in there to help you find out what happened and help you fix it. And a lot of times, it will just automatically fix it, and it can go as far as just send a pull Wes to you. So that's really cool. But, also, they have a marketing mode toggle on their website now Wes you can, like, turn it on, and it will simply just give you a chat box. No marketing copy. No value props. No obligatory logo rivers. What's the point? Everyone uses it already. The fact that you don't can't be fixed. It's just a chat box of ask me about features and troubleshooting,

blah blah blah blah.

So check it out. Century.i0/syntax.

That's gonna get you two months for free.

Alright. Do you prefer a variable that is long and explicit as to describing what it does, or do you prefer a variable that is shorter paired with a comment above above it?

You know, this is one of those things. Again, when I was a young buck, I was like, let's name background BG. Let's name color CLR. Let's go as short as possible for no stinking reason. And I have grown up, and that is one of the reasons why I absolutely go for long and explicit. Let's give me JS long as you want because it, for me, tells me exactly what the dang thing does. And that is such a man, I I don't mind writing comments too. I'm I'm gonna say I'll write comments with this style, but I have no

need for things to be short. Like, there's my computer's got gigabytes on it. I'm not You got and you got the screen real state for it. I agree as well. I think that I will opt for a longer, more descriptive variable. The comment will get lost as soon as you import that thing into another file, whereas actually having the name in the variable is it does not get lost, and it sort of it brings it around with it. So I'm a big fan of more explosive. I don't go nuts with it, but I certainly have been in the opposite situation quite a bit where the variable I'm not sure exactly what it does, you know, or I'm not sure what value it is. Is this in pixels? Is this in in rems or m's? You know? How am I bringing this in? Is this a variable? Granted, TypeScript does make that a little bit easier, but, still, I'm I'm prefer long. And I I'm also maybe we should maybe we'll follow this up with a a mini one. A lot of people say you don't need comments in your code.

Should your code be able to self document? What are your thoughts on that? I love comments.

Comments all day long. Yeah. Like, please. Like, sometimes telling you simply what the thing is and what it, you know, what its name is and what what act it does doesn't give you enough context about even, like, I don't wanna say just quirks, but, like, the things of the way the application actually integrates and works with each other. I mean, personally, I like comments. I comment all day.

I got no problem with that. So Yeah. Yeah. Wes, do you prefer to rebase or do a merge and commit?

Man, I have I have flip flopped back and forth so many times on this. I don't like the merge commit because it's it muddies up the history, but I also don't love the rebase a whole lot because I find it a pain in the butt. As soon as as soon as it's been rebased and and put into a a single commit, then, oh, oh, I have some other code that's dependent on this, and then I have to rebase that. And I just I find it to be a bit of a pain in the butt. So I lean on my repos a little bit more towards the merge commit. The syntax website we have on on rebase, and it's it's okay, but I I much prefer to just squash my own commits, make sure everything is good, and then just have a single merge commit and happy with that rather than rebase it. Yeah. For sure.

I am gonna say I merge commit because I it's just how I've always done it.

I don't necessarily have the problems with it that like, I honestly don't what am I gaining by rebasing that I'm missing? I don't know if I am. I don't work on a big team. I work on a small team or I work by myself. So, like like, I'm sure there are definitely things that the reasons why people use rebase are very valid. But for me, it's like, I personally don't hit those things in my day to day life because that's just not my general workflow. So for me, the merge commit, you know, flow just has always worked fine. So Mhmm. Stick with it. Yeah. Alright. When you're

doing an event listener and you need to pass the event as a parameter.

Are you using e, e v, or typing out the full ass event?

I'm doing e. I would only ever do e, which is interesting because I also do e for error, which it feels like that should probably like, I do e for error. I do e for ESLint, and then, like, only at this very moment am I realizing JS there some kind of conflict.

Like, this is, like, not something I've ever thought of before. But is it is it a conflict actually? You know? Like, it like Well, it hasn't been. Sitting here, like, chatting about it. Yeah. No. It hasn't been a conflict actually. And in fact, this also is a conflict with my previous answer of long name that describes what it is or does. But, like, for some stupid reason, things like errors or events, like you know? I that's, like, one of the few things I'm willing to make an exception for. I I have a list of, like, things that I allow explicitly in my ESLint config.

And e, and these are also variables that can go unused.

Re q for request, r e s for response, e for event. I I never do e for error because what happens if you're catching an error inside of an event listener? That's a that's a bad time. You then you have to, like, rename things. So I always do e r r for error. With TypeScript, it's a little bit less of a problem because you have to explicitly type it if you're defining your event handler outside of a, like, a listener. So I'm I'm on team e all day long. I ain't got time to type event. That's and people who type e v, what is this? What? Yeah. You're a bunch of weirdos. Pick one. No. Pick a side. E v. Pick a side. Yeah. Yeah.

I agree. I agree with that. Now here's one that is a classic.

Tabs or spaces. Do you prefer tabs or spaces?

I am I'm I'm on the same team as the underscore where I have fully understood that tabs are better because it's less characters.

Anybody who's using a tab character can adjust visually how big it displays in their editor. At first, the argument for spaces was that tabs show up really funny when you're, like, viewing source or it shows up really funny on a lot of editors. Those are solved problems. You know? You can you can change the actual tab one. And then quite a few of my projects still use spaces, but I've switched over to using tabs simply because it's one character. You can adjust how big they, display in each one. So I'm a I'm a big fan of of that.

Yeah. I, personally, I am a tab man all the way. I use tabs. It's an easy thing to change over to. I used to use spaces. You just change a setting in your format or your ESLint or whatever.

You're done. That's it. Bingo. Who cares? Tabs all day. It makes the most amount of sense to me. You can change the space in the editor. Tabs to me, make the most amount of sense, and and now I am firmly in that camp. I I actually don't even understand the argument for using spaces. What, like, what is it? I don't even know what like, those all of the arguments for spaces

are are kinda moot. You know? They don't make any sense. Yeah. And, like,

ideally, it's like, it doesn't really matter. It doesn't matter. Like, it's but this is the show where we're talking about it, so it does matter. I think it matters. Honestly, if you have two things and one of them makes a lot of sense and the other one doesn't make any sense, like, yeah, That matters.

Alright. Do you like big line height or small line height? Which one do you prefer?

Man, I am firmly in the camp of small line height. I don't know how these PHP developers do it Wes they have six lines of code on their screen at once. I'm all about having things feel calm, but have have high amount of information density. Part of that comes from being being able to screen record, and and you don't really have a lot of space Wes you're screen recording. You wanna show as much code on the page as once at once. But part of that is just like, I'm not I don't feel like scrolling around as as much as I want. So I'm I'm firmly in team small line height here. Yeah. I am

in team small line height in practice and big line height in concept. I'm the poster child for somebody who should like big line height because it, like, helps me read and stuff like that, but I just can't stick with it. What I end up doing is I I've done this multiple times. I set my line height to be decently big, ESLint a little sore out. Let me move it down just a little bit. And that happens eight times until I'm at the original line height that I was at before where I'm like, this is just feeling not not right to me. So I end up always rocking with a small line height, and it just to me feels the most normal. I don't have any issues with it. I like to see all the stuff on the screen at one time.

This is another one that I think comes from a lot of, like like, older Node, and and people still follow. And this is hard line length. Like, you say, I wanna be 80 or a 120 characters in, or do you just let your code wrap around? So if you're chaining a bunch of methods, is it fine to to let it wrap around? I'm curious your thoughts on this, and I think there might be some. It depends here.

So I tend to keep it as vertical and thin as possible, but in practice, I end up just using, I I don't use either of these. I just I don't have it wrap.

I have it scroll Oh. Side to side. And because of that, I do tend to make it a line length in terms of, like, when I code, I keep it all Vercel.

Yeah. But I don't have anything forcing that. And I don't also have ESLint wrap because I like one line per line, and that line wrap to me is obnoxious. So if if you were to make me be in one of these camps, I would say, give me that hard line. Wow. But in practice, I just end up scrolling. I'm a Versus Node user. Now that I'm a Neo VIM user, maybe that changes. Who knows?

Man, I love line wrap, and I I do put I think I have a 140 character limit. And, basically, I like, I don't necessarily care about either of these because I just let my formatter take care of it for me, but I do turn on my wrap and have it wrapped around. The one thing that I absolutely hate about Prettier, and this is not fixable, is that if you have, like, a paragraph tag with, like, a very long sentence in it, Prettier will chop it up into multiple lines, put them each on their own ESLint. And that drives me nuts because it's a sentence that should wrap, not put each on its own line. If I wanna select all of the code on that and I'm I'm selecting over multiple lines, so that drives me nuts. I much prefer to have my things just wrap, but I put a 140 character limit on my formatter so that if there is a situation, like like, chaining array methods, then they'll just stack them each on their own line, and it's it's quite a bit easier to read that way.

I think out of all of these, this is the one we disagree on the hardest. I I I would never want a one line. Like, if if something

extends visually onto multiple lines, like, I don't want that to be Oh, man. All day long. Love it. Because, like, my Versus Node will indent it a little bit for me, and it's very clear to me that that is a wrapped line.

And and almost always, it's like a like a like a long array of items or something like that. That's another thing I hate about Prettier is if you have an array of, like, a 100 items, it will just, like, format it so that every item's on its new line. I wish you could just, like, turn it off. There's some extensions and whatnot, but I don't feel like fussing with that.

Yeah.

Beautiful. Alright. That was fantastic little bike shedding moment. It's so funny because none of this stuff really matters, but it also is it matters a lot, and it's fun to talk about. So let us know down below. We'll do another episode. What are your, like I call them anthills that you would die on. You know? Things that you don't necessarily matter, but there's a hill you die on.

Yeah. What's interesting, Wes, is when I go through this list, the amount of things that I've changed my opinion on is, like, almost all of them. Like, I've changed my opinion on so many of these things over the years. Node of it is maturity. Some of it is, like, really understanding the benefits of this or that, but it is crazy. As you grow in this industry, your taste will change. So, again, a lot of these things are taste based, and some people want to act like they aren't, but many of them are just taste based for sure. Alright. That's it. Let us know down below what your, anthills that you'll die on. We'd love to hear them, and we'll record another one shortly.