Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron.

I can't stand, I just can't stand it when people use more than 80 characters in a line of programming. Like, what are you doing?

Are you on the terminal? What's going on here, Aaron? Why do you feel so strongly?

Yeah. All my font is green and square and this...

Oh, okay.

No. But that does bring up a interesting point. There's this idea about line lengths and coding and does that matter? And why do people have such strong opinions? And I think that there's probably a couple different reasons why those are brought up. But it kind of also aims at maybe a larger thing. Which is, what's the point of code standards?

Yeah. And maybe the way my brain goes is line length, to me, you could say, "Oh, that's a coding standard. We never go longer than this." But it's almost like a layer deeper, it's a stylistic thing, right? It's maybe less about where do you put your spaces or what order you put conditions in. But it's more just, how does the code look? Because I think line length maybe contributes more to that than some of the other more nuanced, nitty-gritty code standard-type enforcement things.

And I would disagree with that. On the one part, which is how does it look?

I think it's important.

Well, I mean, yes and no. Because you see so many times that Laravel developers and other developers are like, "Hey, look at this piece of code I wrote on Twitter," or something like that. It looks really nice, but it's actually harder to follow than a simple loop or something like that.

Okay. Sure.

So, to me, it's about not what it looks like but its readability. Which is a very different... I mean, it's a very similar, but it's a very different thing.

Yeah. Well, and I think you threw an extra wrinkle. If it's a code snippet you're sharing, sometimes things are formatted for that medium that are not typical. But you know I can concede that. That it's not purely stylistic, it's about readability. Like, that's the goal with enforcing a certain type of style.

I think deciding on line lengths and different styles is important but it shouldn't be the only thing we focus on. Now, I want to define why it's important but why it's not the only thing that we care about. The first thing is the importance of being able to scan, being able to see something on your monitor. Not everyone has a giant monitor like you Joel. This idea of being able to keep everything in your sight, in your vision is kind of a cool idea. But I think what it really breaks down to is if you ever look at usability studies and the way that things work in, let's just say marketing copy or things like that, you'll notice that on our webpages that we go, line lengths are never longer than two-thirds of the main container. They kind of like there's always these columns and people think maybe those columns are for navigation, which yes, or additional information asides.

But also, the usability studies was said, there's a certain length and once you get beyond the eye can't seem to track and follow to the next line, it's just too far away. So that's with how we read. Now, I think that there is something to be said about that with code but that's not the only thing with code because code is a little bit different type of beast, right? It's got letters and numbers just like our words do, but the way you understand it, the way you process it is different than reading.

Yeah.

So, I think it's important to keep that in mind as like there is a basis for having shorter line lengths, but the code is a little bit different than what we're reading so we can stretch those out a little bit. So, we don't have to be so strenuous about 80 characters or anything like that.

Right. So, you're saying there's a visual or neurological underpinning to why we can't just scan maybe 300 characters and make sense of that over a long span? But it's not a hard and fast rule. 80 probably is maybe too small because that has some historical roots in old computers and old technology.

Terminal sizes and, yeah.

Right. I agree with that. And I will say, first of all, I don't have a strong opinion on this topic. The one thing I'll say though is when we made the switch from CodeSniffer to CS Fixer, I did kind of miss, on the one hand, CS Fixer does not let you enforce line length, right?

Mm-hmm (affirmative).

We won't get into why, but they don't. It's not a rule that's even available to you. And at first, I kind of missed it, but then I actually kind of liked it because I do... Looking back through some of our code, we used to have to ignore, there were legitimate times: inlining an SVG. You know, there were things where you would do it where it's like, "This is not my normal way of coding but it makes sense to have maybe 200 characters on this one line." It's some crazy test setup thing. You know what I mean? It did feel sort of arbitrary in the past so I have mixed feelings.

Well, that's the reason why I bring up the second thing is the reason for coding standards is the keyword you just said there was, it makes sense. Well, to you it makes sense but to another developer that may not make sense. So that's kind of why we develop these things and that's why line length and stuff maybe becomes part of your standard even if the tool doesn't do it. Because there shouldn't be conversations... I mean, this podcast is the last conversation anyone should have about line lengths, right?

Really.

Because you should just decide on what it should be for your team and then that's what you do. Unless someone has a better idea of something else that, you know... Unless it's brought up again like, "Hey, we should change it for this particular reason," not just because I like it this way. Because it doesn't really matter what you like per se when you're in the team especially, it should just always be the same.

Yeah, I agree with that principle for coding standards. I mean, avoiding the, you said discussion which I think is diplomatic, the argument which is often what happens with some of these things. It's nice to just kind of sidestep that. I mean, full disclosure we're living without that as a standard right now so you're saying... Is this you telling me that I should figure out how to enforce this at PHP CS Fixer?

No, we have a lot of "discussions" already so I don't think it's a big deal.

Okay.

But I guess the main point here is that if you find yourself arguing about things like line lengths and stuff like that maybe that needs to be part of your coding standard. If you don't have a problem with line lengths and all that kind of stuff then it's fine.

Sure.

And when it comes to line lengths, it's more about readability not what it looks like.

You think it would be useful to maybe come up with one more example? Because I think line length is very concrete. I have one in mind that I haven't shared with you. When you have a conditional, you know, an if statement, that has multiple non-trivial things within it. To me, that's something that would be hard to enforce with a coding standard. But what I'm trying to say is, how would you compose that? Like, is each condition on its own line? Is each condition, do you capture it in a named variable so that it's more clear why you're saying... why you're maybe chaining three methods together to test the truth or non-truth? Falsity?

Truthiness?

Truthiness in PHP land. I think that has a lot to do with readability. If you see this massive wall of booleans versus something that's split out onto different lines, my brain interprets that differently.

Yeah. I think that that's a readability thing, but not necessarily a code standard.

Right.

I mean, I guess there could be code standards of... But you can only have one if on the line or something like that. But that just seems way too, you know, people just caring too much about little things and not actually making programming. No, I agree. Code standards and readability they go hand in hand, but they're not a hundred percent the same thing.

Well, and this is one too. Like, I think part of the reason it would be challenging to enforce a standard is it is so contextual, right? Like, what the boolean is, what the truth test is might be really easy to read even though it's kind of long. Whereas another one would be really short and terse, but still kind of inscrutable. You know, like you're throwing the not symbol in, the exclamation point. You know, there's ways of writing it that are just harder to understand it. It feels a little more subjective to me. But I just think it's another area where I've seen code kind of a before and after it actually... Maybe the reason I bring this up is a project that was on yesterday just had the craziest if statements in it, and I'm like, "This is not right, this is not good." And I refactored a few of them and it, at least to me, and I'm being honest it maybe it's just the way my brain works, the after was clearly better than the before. I don't know if you can enforce that as a code standard, but I still think it's worth thinking about as a team when you're doing a code review or talking about it.

So really there's different levels of how we build our code. Whether there's that very high level, which I guess I'll acknowledge is what it looks like. Some people care about that. Then there's readability underneath that and there's code standards, which are just the mechanics. So those things kind of layer on top of each other and go to make sure that we understand those have different places.

I have to share a confession and I'm hoping you relate to this a little bit, Aaron. But do you ever get weirdly obsessed with identifying where a sound is coming from?

I wouldn't say weirdly obsessed, but I'd say definitely annoyed and like, "What is that?" It'll bother me.

I had something recently, in fact, over my shoulder. Aaron has the privilege of seeing a space heater in my office. And I'm sitting in my office and I was hearing a rhythmic buzzing, almost like an alarm sound. You know what a UPS sounds like when you pull the power out of the wall or the power goes out and it's like this buzzing alarm?

Yeah.

But it sounded it was really far away, in my attic or in my basement. So, it would start and I would hear it and I'd pause and I'd go running around the house. And after the third day of this, I had like, "I'm going crazy." So, my wife came in and she's like, "It's your space heater. It's right there." And sure enough, it was like when it heated up to a certain point, it would just go, eh, eh. And then it would turn off and I'd... In my mind, I had a preconception as to it had to be far away because of how quiet it was and it was literally right behind me. So that was a fun three days.

Is your code running as fast as I am talking?

If your code is as slow as Aaron was just talking, then get in touch with us. We can help, we specialize in performance optimization. Go to masteringlaravel.io and click on the 'Need Help' menu.