938: Hot Takes + Bike Shedding

Wes and Scott dive into some hot takes and classic debates—tabs vs spaces, camel vs snake case, export styles, barrel files, variable naming, and more. Show Notes 00:00 Welcome to Syntax! 01:26 CSS variables: descriptive vs. semantic 03:38 snake_case vs. camelCase 04:54 Default exports vs. named exports 06:23 Barrel files vs. direct imports 09:15 Function declaration vs. function expression 11:00 Inferred types vs. explicit types 13:40 Brought to you by Sentry.io 14:40 Long and explicit variable names vs. short with comments 16:27 Self-documenting code vs. code comments 17:03 Rebase vs. merge commit 18:39 Naming event parameters: e vs. event 20:33 Tabs vs. spaces 22:18 Big line height vs. small line height 23:50 Hard line length vs. line wrap Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

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

• 0:31Scott Tolinski?

  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 got a paint bucket. I'm getting all the trim. I filled in the dents and stuff with spackle. I'm like, I use this, a little like, you know, those little plastic pry tools? I used 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.

• 1:06Wes Bos?

  You gotta get a steamer. Yeah. You have a, like a steam wand or something like that? We got one of those for, at our cottage, we always get like flies and like drooping 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.

• 1:22Scott Tolinski?

  That is something I don't know anything about.

• 1:25Wes Bos?

  Mm hmm. All right, 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 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.

• 2:10Wes Bos?

  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.

• 2:20Scott Tolinski?

  Dude, yeah, I I would say if the app has one color scheme in 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 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 will go to color.

• 2:58Wes Bos?

  Like every site you're making probably has at least a light and a dark mode, don't you think?

• 3:03Scott Tolinski?

  Yeah, does the primary color change, I guess, between the two of those?

• 3:06Wes Bos?

  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?

• 3:15Scott Tolinski?

  Foreground, yeah.

• 3:16Wes Bos?

  In dark mode, make the text white and in light mode, make the text black.

• 3:21Scott Tolinski?

  Yeah, I mean, I kind of do that. I use color scheme as a CSS property, but I do tend to use FG and BG for the text versus the background. That makes the most amount of sense to me.

• 3:32Wes Bos?

  Swap a variable than have to like reselect elements, things like that.

• 3:36Scott Tolinski?

  Hmm, yeah.

• 3:37Wes Bos?

  All right.

• 3:38Scott Tolinski?

  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?

• 3:53Wes Bos?

  Man, all of the arguments for snakecase makes 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 snakecase and it makes a lot of sense. But I simply am still on team camel case for most of my projects by default.

• 4:15Scott Tolinski?

  Yeah, team camel for sure. I mean, I personally, man, snakecase 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 code. And I certainly don't mind the fact that I'm the only one writing snakecase. No, 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 snakecase. But it helps me read and it helps me stay organized. Snakecase all the way for me, folks.

• 4:54Wes Bos?

  All right. When you're writing JavaScript, do you prefer to export default from a file? Like you have one file 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?

• 5:16Scott Tolinski?

  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.

• 5:41Wes Bos?

  Yeah, I agree. Unless I'm, I'm using something where the convention is the main thing exported from this file, like, like routing, right? Like you have like an index dot TSX in a specific route and the main thing that you export from that will be. Your layout or your page. Otherwise, if you're importing that anywhere in your application, I'm going named export all the way. And I find it much easier to have the autocomplete 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.

• 6:23Scott Tolinski?

  OK, 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 kind of scoops up all the exports from the files and then reexports them into. So you can import directly from a directory. Which do you prefer to do?

• 6:49Wes Bos?

  Man, I 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. You know, I want to import dot TS in in all of mine. I just want to be as explicit as possible. I think the whole require no JS lookup tree is very complicated. And it's a huge pain once you're switching different environments. So I'm very much of just put it in a file. Even if I have like a file that is named like format money

• 7:33Wes Bos?

  and I'm putting that in another folder of the same name, I'm totally fine with that. I much prefer that over just like an index dot TS in my project.

• 7:43Scott Tolinski?

  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 going to come out of your ear here. I thought that.

• 8:02Scott Tolinski?

  Specifically, it would look so nice to have,

• 8:08Scott Tolinski?

  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 where 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'm not doing barrel files.

• 8:48Wes Bos?

  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 going to be publishing. In that case, a barrel file works. But yeah, all the tree shaking stuff, 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.

• 9:12Scott Tolinski?

  Oh, my God.

• 9:17Wes Bos?

  Do you prefer a function declaration or a function expression? And 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 are sticking a function into a variable. And this could be an arrow function. This could be simply just saying cons 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,

• 9:59Wes Bos?

  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 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 want to 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.

• 10:28Scott Tolinski?

  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. Where it's like, we have a keyword for that. Function is the thing. It's a, it's the function declarat. Like, just do it that way. That it just feels unnecessary to do it any other way, personally. Do you prefer, Wes, inferred types in TypeScript or explicit types in TypeScript?

• 11:10Wes Bos?

  Your god. I'm running out of these fun ones that I made. I should have 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 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.

• 11:53Wes Bos?

  And then two, if this is something where AI 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 handy and I, some TypeScript, even if you use some of these libraries, like a lot of the Tanstack 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 going to put myself maybe in the middle of that one, given that I I will be explicit when it's necessary.

• 12:33Scott Tolinski?

  Wishy-washy here is what you're saying.

• 12:34Wes Bos?

  Yes.

• 12:35Scott Tolinski?

  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 in 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,

• 13:18Scott Tolinski?

  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.

• 13:41Wes Bos?

  Let's talk about Sentry real quick. Absolutely hilarious. The Sentry.io website now has a, two things that's hilarious. So the new tagline is someone's got to babysit the bots. So if you are working on anything AI, things will go wrong and you're going to need Sentry 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 request to you. So that's really cool, but also they have a marketing mode toggle on their website now where 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.

• 14:24Wes Bos?

  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.

• 14:34Wes Bos?

  So check it out. Sentry.io forward slash syntax. That's going to get you two months for free. All right. 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?

• 14:55Scott Tolinski?

  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 as long as you want, because it for me tells me exactly what the dang thing does. And that is such a, man, I don't mind writing comments too. I'm going to 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.

• 15:40Scott Tolinski?

  I'm not.

• 15:41Wes Bos?

  You got, and you got the screen rail 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's sort of, it brings it around with it. So I'm a big fan of more explicit. 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 prefer

• 16:26Wes Bos?

  long and I'm also, maybe we should, maybe we'll follow this up with 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.

• 16:42Scott Tolinski?

  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 know, is it 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. Wes, do you prefer to rebase or do a merge and commit?

• 17:10Wes Bos?

  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 then put into a, a single commit, then, 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,

• 17:55Wes Bos?

  and then just have a single merge commit and happy with that rather than rebase it.

• 17:59Scott Tolinski?

  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 stick with it. Yeah.

• 18:39Wes Bos?

  All right. When you're doing an event listener and you need to pass the event as a parameter, are you using e, eV, or typing out the full ass event?

• 18:56Scott Tolinski?

  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 event, and then like, only at this very moment am I realizing is there some kind of conflict?

• 19:14Scott Tolinski?

  This is like, not something I've ever thought of before.

• 19:17Wes Bos?

  But is it, is it a conflict actually? You know, like it like

• 19:20Scott Tolinski?

  Well, it hasn't been.

• 19:21Wes Bos?

  Sitting here, chatting about it. Yeah.

• 19:23Scott Tolinski?

  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.

• 19:41Wes Bos?

  I, I have a list of like, things that I allow explicitly in my ESLint config. And E, um, and these are also variables that can go unused. R E 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, that's a bad time. Yeah. 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 it, people who type E V, what is this?

• 20:25Scott Tolinski?

  What? Yeah.

• 20:26Wes Bos?

  You're a bunch of weirdos. Pick one. Pick a side.

• 20:29Scott Tolinski?

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

• 20:35Wes Bos?

  Yes.

• 20:36Scott Tolinski?

  Tabs or spaces? Do you prefer tabs or spaces?

• 20:40Wes Bos?

  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.

• 21:26Scott Tolinski?

  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 formater, your linter, 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 I am firmly in that camp. I actually don't even understand the argument for using spaces. What, like, what is it?

• 21:55Wes Bos?

  I don't even know what, like, those, all of the arguments for spaces are kind of moot, you know?

• 22:01Scott Tolinski?

  They don't make any sense.

• 22:02Wes Bos?

  And, 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.

• 22:10Scott Tolinski?

  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. All right. Do you like big line height or small line height? Which one do you prefer?

• 22:25Wes Bos?

  Man, I am firmly in the camp of small line height. I don't know how these PHP developers do it, where 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 when you're screen recording. You want to 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.

• 23:04Scott Tolinski?

  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. And then, over the course of a week, I'm like, you know, this is feeling a little thrown 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, uh, 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

• 23:48Scott Tolinski?

  to see all this stuff on the screen at one time.

• 23:50Wes Bos?

  All right, this is another one that I think comes from a lot of like, like, older coding, and, and people still follow. And this is hard line length. Like, you say, I want to be 80 or 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.

• 24:15Scott Tolinski?

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

• 24:30Wes Bos?

  Oh.

• 24:30Scott Tolinski?

  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 vertical.

• 24:40Wes Bos?

  Yeah.

• 24:40Scott Tolinski?

  But I don't have anything forcing that. And I don't also have line 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.

• 24:57Wes Bos?

  Wow.

• 24:58Scott Tolinski?

  But, in practice, I just end up scrolling. I'm a VS Code user. Now that I'm a NeoVim user, maybe that changes, who knows?

• 25:05Wes Bos?

  Man, I love line wrap, and I, I do put, I think I have 140 character limit. And basically, I, like, I don't necessarily care about either of these, because I just let my formater 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 line. And that drives me nuts because it's a sentence that should wrap, not put each on its own line. If I want to select all of the code on that and I'm,

• 25:46Wes Bos?

  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 formater so that if there is a situation 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.

• 26:06Scott Tolinski?

  I think out of all of these, this is the one we disagree on the hardest. 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.

• 26:17Wes Bos?

  Oh, man. All day long. Love it. Cause like my VS code 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, uh, 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 hundred 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.

• 26:45Scott Tolinski?

  Yeah.

• 26:46Wes Bos?

  Beautiful. All right. 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.

• 27:08Scott Tolinski?

  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. So some 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, uh, 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.

• 27:35Wes Bos?

  All right. That's it. Let us know down below what your, uh, anthills that you'll die on. We'd love to hear them and we'll record another one shortly. Peace.