That's How We've Always Done Things Around Here
Posted by alexcristea@reddit | programming | View on Reddit | 178 comments
We do this in software way more than we think:
We inherit a process or a rule and keep following it, without questioning why it exists in the first place.
It’s like that old story:
Someone cuts off the turkey tail before cooking, just because that's how their grandma did it. (spoiler alert, grandma’s pan was just too small.)
Some examples of "turkey tails" I've seen:
- Following tedious dev processes nobody understands anymore.
- Enforcing 80-character line limits… in 2025.
- Leaving TODO comments in codebases for 6+ years.
Tradition can be helpful. But if we don't question it, it can turn into pure baggage.
What’s the most enormous “turkey tail” you’ve seen in your company or project?
Curious to hear what others have run into. 🦃
InterlinkInterlink@reddit
Providing examples of "turkey tails" is in my opinion a pointless exercise. You are correct in your assessment that tradition should be scrutinized, but if you want to instigate real change you are ultimately responsible for generating inertia for it. Under ideal circumstances the answer to turkey-tail questions would be obvious, but said turkey-tail wouldn't exist to begin with if there was not some confounding factor. A brief investigation will either reveal that yes indeed Grandma's pan was too small - or that the ritual exists for other reasons (suboptimal implementation, broader systemic issues, etc.)
Better safe than sorry - the risk evaluation is very simple: either you follow the pre-established process (that presumably works) or you don't and risk negative outcomes. If it's that much of a problem, advocate to allocate time unravel the process. Even better, if the process is business critical why don't you understand it to begin with.
Just because the 80 character line limit was a product of physical terminal restrictions doesn't mean it's defunct. There have been numerous studies which I would casually summarize as "just because you have more screen real estate than the post doesn't mean you should use all of it." Then there is the general concept of constraints guiding implementation; longer line lengths will facilitate longer lines - more indentation, less concise naming, etc.
I won't make any assertions as to what the optimal line length limit is. I personally dislike anything exceeding 100 columns, and its a nuasance to need to counter colleagues advocating for a line limit increase (to proposed limits of 150!) with their only rationale being "it's 2025 I have big monitor."
Another process failure. Either you have a system to track future work items (if you create a TODO, you should be required to create a trackable work item) or else resolving these TODOs will be left to chance. But try explaining to business stakeholders that you can't deliver a feature because you need to spend a cycle eliminating defunct TODOs.
Dr-Metallius@reddit
These numerous studies you refer to - were they done for reading the code specifically or just the regular text? Because it's completely different. The regular text is never indented and is always read left to right (or right to left depending on the language) and top to bottom without going back to already read parts, and that's not what happens with the code at all.
With regular text I don't care how much of it I can see at a given time. It can be a single line I'm currently reading for all I care. With the code, however, the more I see at a given time, the better, otherwise I need to keep more stuff in mind, which increases the cognitive load. Your colleagues may not be phrasing it like me, but that's what they feel when they mention the monitors.
Damn right I don't want concise naming and having to constantly look up what all these obscure variable names mean. Or scanning over a gazillion of small meaningless functions which exist for the sole purpose of lowering the indentation. It shouldn't go to another extreme, of course, but that's what the code reviews and style check tools are.
I've been in software development for many years, can't remember anyone who advocated for lines as short as you do. With my current project we discussed the line limits just recently and decided to codify 150. No one complained about it being too long. So my personal experience says that your preferences are an outlier.
babada@reddit
Wait what. You don't like small functions? If small line limits are making you compose your code into small functions than it was probably doing you a favor.
Dr-Metallius@reddit
The key word here is "meaningless", not "small".
nikolaos-libero@reddit
How can they be meaningless when they have scope?
Dr-Metallius@reddit
What do you mean by scope?
nikolaos-libero@reddit
Scope may not have been the best word, but basically anything that might require, or "require" in case of style, indentation, like conditionals, closures, or function chains.
The conditionals less so because their indentation can be reduced by putting them in variables and structuring them well with guard clauses and such.
Dr-Metallius@reddit
You mean a compound statement then. But that's just some stuff that gets executed together. That doesn't mean that it's a single coherent action or something reusable. Every function is a compound statement with a name after all, does that mean that every function is meaningful? That doesn't sound right.
nikolaos-libero@reddit
I would argue that every function that lowers indentation cannot be meaningless. That's not to say that the meanings won't be mixed and split across functions unnecessarily.
Dr-Metallius@reddit
That's a contradiction right there. The second statement is completely sensible. Of course, the code can be spread too thin over functions which don't stand on their own, and that's exactly what I had in mind when I talked about meaningless functions. And it will most likely happen when the developer has to think more about how the code looks than what it does.
The first statement is obviously in conflict with the second one. You still haven't explained why you think it's true or what counterarguments to what I said previously are, just reiterated that you disagree.
nikolaos-libero@reddit
What's an example of meaningless indentation that could be reduced via extracting the code into a helper function? I think the indentation would have to be meaningless otherwise the meaning would apply to the function that reduces it as well.
Dr-Metallius@reddit
Here's a function from Ktor.
What would you separate out of here to reduce indentation?
InterlinkInterlink@reddit
Many years with your head in the sand then. When the largest open source project in history is 80 columns with 8 space indentation, not much else to be said.
Good naming is hard. Good programming taste and abstraction is hard. Just throwing longer lines to facilitate longer names is a naive solution.
See above. Your personal experience and preferences have no bearing on broader analysis - let alone classify another's experience as an outlier. The fact that every counter in this thread can't even maintain logical coherence speaks volumes.
azirale@reddit
If you're talking about Linux it has specific reasons to be 80 and 8 and they don't have anything to do with being the one true ideal layout for all time.
Linux code started over 30 years ago. Code layouts people would have had experience with for comparable projects back then would have been 80+8 , because those projects and that experience would have had a lineage back another 10 to 20 years.
So Linux today keeps its standard so that all the C code is consistently formatted which makes the codebase as a whole easier to read. That's not a turkey tail.
But saying all new modern projects should also be 80+8 because Linux is is a turkey tail. New projects don't have that lineage or 30 years of precedent to follow, so that's just copying the rule divorced of its reasoning - practically the definition of a turkey tail.
InterlinkInterlink@reddit
At no point did I ever say that projects should adopt these exact same limits. If you go up to my parent comment I quite clearly state:
I cited Linux because this other commentor who has reading comprehension issues like most others responding to my comments keeps arguing either past, around, and ignoring the core thesis. I'm not even going to bother responding to his latest writeup since he unironically suggests we should ignore research (while also simultaneously optimizing for the "average" user. I wonder if he even understands how the scientific process works).
Dr-Metallius@reddit
Of course, you not going to respond because you a) can't provide any relevant research and b) explain why it's relevant in this particular case, so you have nothing to say. I think I didn't ignore any parts of your answer (unlike you), but if I did, kindly point them out and I'll reply to them as well.
azirale@reddit
No you just acted out as a complete asshole to someone giving their personal experience, then capped it off with a condescending appeal to authority.
In response to "I've been in software development for many years, can't remember anyone who advocated for lines as short as you do" you had...
Also you were directly asked "These numerous studies you refer to - were they done for reading the code specifically or just the regular text?" - which you've completely ignored, you haven't even offered a cursory 'I don't have time to look them up right now' - and they were completely right in responding to you that "You haven't provided any broader analysis."
You're making claims, completely avoiding backing anything up, then being repeatedly condescending and dismissive, which seems to be on brand since you describe having to deal with your colleagues requests for change as a 'nuisance'.
Dr-Metallius@reddit
Perhaps you refer to Linux, so what is the point of giving it as an example? Are you saying that personal preferences of Linus Torvalds, which are in the basis of this project's code style, must be the best for most people because his project has become massively popular? He isn't even exactly a person known for democratic decisions and listening to preferences of other people. Even assuming the code style was agreed upon by many people, it was selected for a specific language and project. Are you working on an OS kernel in C?
Linux kernel also contains Rust code now. It is formatted with 4 space indentation and a 100-symbol limit. Does that mean that all C code is formatted wrong then if newer code is formatted like that?
Exactly, good naming is hard, and that's why I don't want to have any artificial limits on top of what I already have to deal with. If extra clarity offsets longer field name length in a certain case, then that's what I will go for.
You haven't provided any broader analysis though. You skipped the most important part in my comment which discusses the relevance of the research you refer to. In the light of its absence, it's your experience against mine, of course. In fact, your own experience says your preferences are an outlier too, since you are having conflicts with your colleagues about the line length, and I haven't had a single one yet.
Even if you do provide some research, I don't see why you cling to it so much anyway. When you are designing a website, you need to optimize for the average user since there will be lots of them, so you need a research to know what the average user wants. When you set the code style for your own project, most likely you already know who's going to be working on this project unless your company has a massive turnover rate. So if most of your colleagues are comfortable with something, that is the right preference, and not some preference for some average guy on some abstract project in a vacuum.
seven_seacat@reddit
lol 8 space indentation
greebo42@reddit
Your comment about regular text is consistent with a cognitive style difference I've informally observed over years (not related to programming). Like you, many people seem to parse text in the customary order and be satisfied (unless I misunderstood you). I find myself sensitive not only to the text itself but also the layout. Not sure how to articulate that elegantly. I wonder if it's one of those "two types of people in the world" things.
Consistent with my preference for regular text, I find I prefer code lines that aren't too long, so if I'm getting close to 80, I look for ways to break the line. I don't claim to be in the taste majority. And sometimes i just have a 90+ character line. My respect for a line length limit is about my own cognitive load, not about the hollerith card or the VT 100.
I agree with your preference for adequately descriptive names, and in my experience, that often clashes with taste in line length .. a balance I try to navigate.
jc-from-sin@reddit
Re: line character limit
You're not doing what you're preaching. You're advocating for 100 characters without any reason. The other colleagues have a reason: our monitors are much wider, larger and higher resolution. Not taking advantage of that is... Wasteful.
InterlinkInterlink@reddit
Did you just choose to ignore this part:
So I will be more specific. There are numerous eye tracking studies, UI/UX studies, et al which all suggestion character limit ranges of 80-100 are objectively better for left-to-right reading comprehension.
"with their only rationale being 'it's 2025 I have big monitor.'" Can't believe I had to write this twice. Welcome to the real world of collaborative programming where your personal preferences and circumstances should not be what guides collaborative policy.
jc-from-sin@reddit
Those studies are probably old on people that grew up with 4:3 monitors and worked in DOS. It would make a lot of sense.
Just because the line size is 150 doesn't mean all lines are that size. Almost all of the code lines we write have left padding. We didn't use to do that when we had 80 character lines.
Funny you say that when you say your colleagues want something and you're the one that opposes it. It seems you're the one blocking a change that will help more people than not.
phil_davis@reddit
Lol, jfc "they were probably old people who worked in DOS." What an embarrassing comment...I would delete this if I were you.
jc-from-sin@reddit
Why? I've written Basic for spectrum and 286 before.
That's not something I remember fondly. We have much better tools now and we're not using them to their fullest.
phil_davis@reddit
Because it was a piss poor argument, if you can even call it that. It's telling that his response was left 6 hours ago, and mine only 2, yet you replied to my comment and not his.
Manbeardo@reddit
IIRC, the results have been replicated in many formats, but the earliest research was done with physical paper because newspaper companies wanted to figure out the best width for their columns.
InterlinkInterlink@reddit
The studies extend far beyond just programmers. See other comments in the thread about how reading just about everything is improved with narrower column restrictions. Also nice to see pure conjecture on your end.
Left padding? You mean indentation? Furthermore that argument does address the root analysis that reading comprehension is improved under restricted column lengths. What you're trying to say is "with current indentation, we should extend line lengths to match. So 4 spaces for function indent, and 8 more for two nested indentations under most sensible implementations - 80 + 4 + 8 = 92. Still below 100 characters.
I'm not opposing colleagues for no reason. I'm opposing change that is based solely on personal preference when there is non-trivial amounts of evidence contrary to their preferences. Should I demand that we rewrite hundreds of thousands of lines of Python we have into a typed language because I prefer it? No, because it makes zero engineering sense. In that same vein I'm not going to allow "feelings" to dictate engineering decisions. I am not blocking change because of my personal preferences, I am blocking change because their only rationale is personal preference, and it's an objectively bad preference in the presence of tangible research.
There's a reason you're being downvoted.
mallardtheduck@reddit
This is like the firth post I've seen here citing "numerous studies" without linking to a single one... The phrasing you use strongly suggests you're talking about general text/reading studies, not ones specific to code, which is read and understood in a very different way to general prose.
Venefercus@reddit
I had a team that would copy-paste 1000 lines of boilerplate db wrapper (the top-most "orm" of three layers) every time someone added a new table. It turned out this started as an orm layer on top of a cassandra orm (because apparently depending on db libraries directly is bad???), and was left over because nobody in a 40 person team wanted to learn how to understand sql/postgres well enough to use gorm when they switched from cassandra. And the guy who built the cassandra-> gorm wrapper (middle layer, initially intended just to make the migration easier) was long gone.
josh_in_boston@reddit
Because "you might want to change your database" which almost never happens but let's pile DB abstractions onto every single project just in case.
Kernel_Internal@reddit
I see the "almost never happens" argument a lot. But isn't it a self fulfilling prophecy, likely caused by people like you believing it and choosing not to make their code capable? I know for a fact my CTO would love to move away from oracle but the cost is prohibitive due to all the direct dependencies and inlined sql strings with oracle specific syntax.
IanAKemp@reddit
That's not a self-fulfilling prophecy, that's just bad software development practices period. It's 2025, we have ORMs, they figure this shit out for you, use them. And if you absolutely need to do business logic in the DB, use a sproc.
Kernel_Internal@reddit
That's kind of my point. The guy I replied to is on the side of "don't use ORMs" because one of their primary benefits is almost never needed. But I'm saying I think the reason they're never needed is because of the natural consequence of his viewpoint, when maintained over years by people of various skill. And yeah, this is 2025, but the code I'm talking about was born in 2010.
vytah@reddit
What actually happens is that the code is written half in an abstract way in preparation for changing the database, and half in a way that works only on one database.
So swapping databases is only 100 tonnes of pain instead of 200 tonnes of pain.
nickthegeek1@reddit
This is peak "nobody wants to touch it" syndrome and exactly why tech debt grows into a monster - everyone's afraid to be the one who breaks the sacred boilerplate lol.
meshugga@reddit
oh good lord that is the worst one yet
ZakanrnEggeater@reddit
i find pondering the reasons why things are done the way they are done an exercise that bears fruit consistently. YMMV
IanAKemp@reddit
Getting people to ponder things, though, is a lot more difficult. Especially if they are the people who decreed the thing should be done that way to begin with.
ZakanrnEggeater@reddit
in my experience, all that institutional knowledge will show right back up when it goes ignored
at least, all those things that are still actively used (which always seems to be a big question - how much of this old stuff is actually in use versus what can be pruned)
dendrocalamidicus@reddit
The flip side of this is the over eager inexperienced team member who comes in and suggests every other thing they encounter should be changed.
We ShOuLd rEwRiTe tHiS iN RuSt
There's a time and a place for suggesting code and processes should be scrapped / reworked, and it's never all at once, and it should generally only be suggested after a significant period of observation and experience with what's there already.
alternatex0@reddit
There's an easy way to handle these devs. Allow them to tinker with their ideas. Telling them that they lack experience or are naive is not productive. If the want to rewrite a project or a section of the code, whenever they have some free time they can work on it in a separate branch. If they succeed and manage to produce a better implementation then the team will benefit, if they fail they gain important knowledge on why it wasn't doable - which also benefits the team.
IanAKemp@reddit
Ah yes because software development jobs have SO MUCH of that free time. Just OVERFLOWING with it.
alternatex0@reddit
If no one has any time ever then it would be moot for a dev to suggest a rewrite/refactor. Or to look at it from another angle, every dev has 8 hours of time every day, it's just prioritization that decides what we do with them. Sometimes a dev can suggest a piece of work that is more valuable than what's currently on the backlog.
IanAKemp@reddit
No.
You allocate time for these things, out of the sprint boundary, because refactoring and learning are important.
alternatex0@reddit
Oh so we're arguing semantics. Very useful.
dendrocalamidicus@reddit
The reality is they invest a huge amount of paid time in that project to create something that is not in our tech stack, is developed by an inexperienced dev with code quality issues, is filled with missing business requirements, and they also burden QA with a back and forth over the inevitable plethora of issues and missed requirements, the PO with trying to get answers to how it should work, and senior devs with assistance on problems. If you gave them a time boxed period to work on it it's possible they could then see that it's more complicated than they think, but that's a very expensive lesson given the cost of dev time. I don't think this suggestion really works in practice in anything other than a trivial area of the code, which aren't the bits they are suggesting to rewrite. They suggest rewriting the big complicated bits they struggle to understand because if they can't understand it, it must be shit.
IanAKemp@reddit
If you never give people the freedom to fail, they're going to become failure-averse, and that means they're never going to grow. If you want juniors to become mids and mids to become seniors, then you have to give them that freedom. It costs money to invest in your people, but do you know what costs more? Having your entire application written by juniors.
jl2352@reddit
Right on. If you want to pick on a 1,000 line file and improve a few bits. Maybe throw out something bespoke for a well used off the shelf library. Sure, I can be happy with that.
The problem is the scope and quantity. I had one new joiner suddenly pull out a 10k line PR they did in their own time, built on top of their custom library (with no docs, tests, or users). Dealing with it wasn’t pleasant for anyone involved. Even though they had some great ideas.
NerdPunkFu@reddit
I'm not sure adding an external dependency is a positive.
jl2352@reddit
It depends. When I wrote that I was thinking of a bespoke LFU cache with zero tests. Reading through the code it looked very naive and inefficient. I replaced it with an off the shelf with 100k downloads. I trust the 100k download library more than the non-tested bespoke one.
alternatex0@reddit
If the dev spends other people's time and gets stuck, it means they're not qualified to rewrite that piece of code or not qualified to assess the viability of the rewrite (time-wise). So their preconceived notions about what it takes to improve the code in terms of skill and time required were wrong. When this happens, the reasons for the failure should be apparent to the dev. If they are not and the dev continues to keep hold of their ego and naivete, then they are beyond help IMO.
I don't think there's anything wrong with telling overeager devs to "prove it". In my experience it's a great exercise for ambitious devs to improve their skill-set (whether it be coding or estimation) and show what they can contribute, as well as a great way to reveal devs who are all bark and no bite.
abandonplanetearth@reddit
I call those people resume developers. They focus on things that look good on their resume instead of focusing on what the business needs.
Recently I worked with a senior dev who:
4.
vsujeesh@reddit
Resume driven development
FullPoet@reddit
OTOH, you arent getting a raise at your current one (most likely) and loyalty does not pay.
What pays is moving jobs.
apadin1@reddit
I hate people who criticize “job hopping”. I understand some people like to stay at one job forever but I’m always keeping my options open. If a company comes around with a better offer and the job sounds interesting, I’ll take it. Because I know any company would lay me off at the drop of a hat if they didn’t need me anymore
FullPoet@reddit
Honestly, its because the people who critise and write that sort of thing arent developers.
Nearly all the time they're managers and that person sounds like a manager.
zxyzyxz@reddit
How did they even last that long? If they were doing a poor job I'd assume they'd be shown the door in relatively quick fashion.
I call it RDD, resume driven development.
allo37@reddit
Hate the game not the players I guess
ThrowRADisgruntledF@reddit
Man, these developers are exhausting. I know many code bases are flawed, but you can’t join a codebase that’s 10+ years in the making and assume that every anti pattern is being done blindly or without reason. It’s also often more time consuming to correct the anti pattern than it is to leave it. If it’s not presenting a security, performance, or architectural flaw just leave it. I’m the lead for a legacy codebase and I have a new developer who is constantly messaging me with new “antipatterns”. Bro please just work on your ticket, it’s three days overdue.
LookIPickedAUsername@reddit
Most of the time when I see something stupid in our codebase and decide to fix it, a couple of hours later I say “ohhhh I get why they did that now”.
I still generally consider this time well spent, because now I understand this corner of the codebase and I can at least add a comment explaining the reason this seemingly-dumb thing is happening.
Naturally, I wish whoever originally wrote the code had left that comment instead and saved me a bunch of time, but you can’t have everything.
ThrowRADisgruntledF@reddit
Hard agree on the comment thing.
CherryLongjump1989@reddit
Yes I can.
NuclearVII@reddit
The "can't we rebuild this in X" is much, much better than "can't ChatGPT do this?"
zabby39103@reddit
In my experience this is the more common problem, not just with inexperienced team members but even with senior members. The best developers think programming is fun, and either consciously or unconsciously we want to try new things and have fun. The MBAs will often go with it because they want to do the "new thing".
There was zero reason to move the software at my work to a kubernetes/microservice model, absolutely zero use case to scale that hard, but hey my resume is better now and the effort gave jobs to a lot of people.
witness_smile@reddit
Had a new “medior” join (who after a few months turned out to be more at junior level still) recommend we change one of our build tools completely after their first week at the company lmao
__konrad@reddit
// TODO:comment is an alias for// MAYBE-LATER:or// WOULD-BE-NICE:.FIXMEis an alias for// TODO:.IanAKemp@reddit
More like
// WILL NEVER HAPPEN:.__konrad@reddit
JDK uses
REMIND:for that purpose, e.g.REMIND(aim,7/29/98): ...- 27 years later still not fixed ;)IanAKemp@reddit
:hidethepain:
LessonStudio@reddit
I have long just put this into a category I call "religious".
If you want to have fun, ask flutter/dart people how to change the formatting in the IDE to change it from 2 spaces to 3, and then to change it to tabs. These will compile, but IDEs like jetbrains say, "hello no, people don't want it." yet, I regularly read people asking for it, only to be told they are the stupidest people on earth.
IanAKemp@reddit
Because they are.
hotpotatos200@reddit
On the 80-character line limit, I still try to keep roughly 80 characters because I like having two windows side-by-side, and much more than that on my monitors gets cut off. It’s not a huge deal, but slightly annoying to side-scroll
YumiYumiYumi@reddit
You don't like word wrap?
hotpotatos200@reddit
It’s a personal preference, but absolutely not. That makes it confusing as to what is actually on a separate line vs part of the previous.
The 80 character limit isn’t a hard limit. In most situations it makes sense and can break long lines apart. If you rely on word wrap, just keep it at the 80-ish limit.
YumiYumiYumi@reddit
Some editors provide a marker to indicate that a line has been wrapped. Does this not really work for you, or you don't enable such?
I personally find vertical space to be a premium, with today's ultra-wide monitors, and actually prefer longer lines over breaking them up.
hotpotatos200@reddit
There’s an assumption that everyone uses ultra-wide monitors, where that’s just not the case. Some (like me) use 24 inch monitors, while some just stick to their laptop screen. For these people having a 200+ character line means side-scrolling just to read every single line. Breaking it up 80-ish characters works for the majority who don’t have ultra-wides, as well as those who do.
Another anecdote from work recently. I made a python library to perform some data analysis that was previously done by hand in excel. The first pass did have everything on one-line, mostly because I’m a C dev, not Python, so I didn’t know you could put things on different lines.
Anyway, after stumbling upon PEP8 and finding out you can do multiple lines, to me, it made the code more readable. The biggest gain was putting function arguments on their own lines. This all then also conformed to PEP8 regarding their 80-character line limit style. So win-win.
YumiYumiYumi@reddit
That's the whole thing. Everyone will have their own setup and their own preference for line length. Enforcing some particular limit will either be too long or short for some people.
I see this more as a tooling issue - users should be able to set their preferred line width and the editor adjusts the code to suit their needs. If this can be achieved, there should be little need to set length limits as code will display well regardless of one's monitor/window setup.
I've personally gotten used to word wrap, and as a result, have largely stopped caring about length limits. I see a bunch of people here objecting to using it however, so am interested to hear the reasoning and whether a "better word wrap" could meet their objective.
hotpotatos200@reddit
Agree that it’s a preference. Word wrap is just a tool that visually solves the issue, while character limits do it manually. However, character limits are more portable for any IDE or text editor.
Another anecdote. Our dev environment is remote VMs. We SSH into them to do anything. Some use VSCode and the remote extensions, and some prefer simply to use vim. For both of these use cases, character limits works. If we relied on word wrap, one or both would suffer less readability due to having to side scroll, or the terminal window (e.g. Putty) doing weird wrapping.
At the end of the day, if there’s a standard for the code base, use that. My preference, as is many others, is to use the 80 character limit.
YumiYumiYumi@reddit
Your comment makes it sound like word wrap isn't the issue, rather it's that tools don't support it well enough?
If so, that differs from your original statement about word wrap.
You mentioned VSCode and vim as examples where undesirable side scrolling can occur, however both editors support word wrap (and it works fine in PuTTY too). So I'm confused - is it that you don't like how they do word wrap, or that it's simply not configured?
hotpotatos200@reddit
Word wrap isn’t the issue, no. It’s one solution to viewing long lines of code. So is limiting the number of characters on a line. One is visual only, the other is the format of the text.
My issue with word wrap is that not all devs will take the time/effort to install/configure it. They’ll use the vanilla experience for whatever they do. Standardizing on line limits ensures it works everywhere, not just when the tool is installed/configured.
YumiYumiYumi@reddit
People not spending ~30 seconds to turn on a setting seems like such a poor excuse to force a ~1980s coding style over. But that's just my opinion, and clearly you disagree.
Thanks for taking the time to explain all this - it's good to know a reason why this still exists.
JanB1@reddit
Some say there's also a deeper idea behind the 80 character limit.
It's so you don't get endless chains of method calls with arguments all on one line chained after each other. Or really, really nested code. Or function heads with 15 arguments.
YumiYumiYumi@reddit
If those are the things you don't like, then restrict them specific. Hiding that behind a line character limit shouldn't be the approach - otherwise function heads with 15 single letter arguments will pass the check, which is probably not what you want.
apadin1@reddit
For code? Absolutely not
YumiYumiYumi@reddit
Are you able to elaborate on what exactly works poorly with word wrap? Could a "better word wrap" suit your needs?
recycled_ideas@reddit
A carriage return is meaningful in most if not all languages. It should be clear where one exists.
maxinstuff@reddit
My favorites are always processes/software/automation that product vestigial artifacts.
I've seen entire setups maintained and monitored for the sake of a thought-bubble report built for a middle manager who no longer works at the company.
pheonixblade9@reddit
this is a perfect use case for doing a scream test
maxinstuff@reddit
100%
The old story I was always told was about getting rid of a printer - you can’t ask people if they use it because they’ll say yes - but what they’re actually saying is that they like the IDEA of using it.
So you don’t get rid of it at first, you just unplug from the wall and leave it for a month first 😬
alexcristea@reddit (OP)
I like this. It can work wonderfully with features that are no longer used but are a nightmare to maintain.
NuclearVII@reddit
I felt this one.
The worst is when you delete all this old crap that isn't clearly being used by anyone, and then the next day some poindexter goes "hey, can I see the output? Just outta the blue? I felt a disturbance in the force!"
PrimozDelux@reddit
Sure, check out this git hash and build it yourself
stefand986@reddit
Creating associative tables for things that should just be another attribute in the table, “because of normalization”, but in reality there is simply insufficient understanding of the semantics of that attribute and insufficient knowledge of what a functional dependency is.
“Database Systems: A practical approach” by Thomas Connolly is a good book to improve the understanding which everyone should read who touches relational databases.
youngbull@reddit
Damn right, it's time to go back to 65 characters per line like it's done in typography. This new fangled 45-80 characters that web designers are touting is just modern sloppiness. https://kickpoint.ca/the-readability-formula-making-your-website-easy-to-read/
civildisobedient@reddit
The big difference is sentences have natural spacing between words, while in code you sometimes find compound-word monstrosities like EndOfYearSummaryConfigurerFactoryBean or post_bill_pay_request_without_credentials_throws_unauthorized_response_test() and there goes your 65-characters.
CherryLongjump1989@reddit
But to be fair, both of your examples are of shitty practices that suck at any line length.
Nicksaurus@reddit
Code isn't text though. Most lines of code don't get close to the character limit so it's not the same as reading a block of text where every line is roughly the same length
youngbull@reddit
True, but for big statements I would still just want some splitting of lines in there. Consider
vs
Nicksaurus@reddit
You need two spaces after each line or reddit removes your newlines
Anyway, at this point it's just preference. I prefer the first one personally, just because I don't like to have one logical unit of code split up too much if I can avoid it
youngbull@reddit
Weird, looks fine for me on Android.
Also, I might be a bit influenced by classical lisp line splits and indents (e.g. https://www.sicpdistilled.com/section/1.1.7/ ), but I strongly prefer some grouping by Linesplitting rather than lines that just go on and on. Of course, just splitting arbitrary places is just bad.
ShinyHappyREM@reddit
There are different clients, e.g. RedReader
LegendEater@reddit
What's your problem?
LegendEater@reddit
jc-from-sin@reddit
This.
ewouldblock@reddit
marinuso@reddit
ewouldblock@reddit
You forgot to make it a
varsyklemil@reddit
I don't disagree, but we also generally don't left-align our text the way prose typography does. If we allow ourselves to keep the syntax highlighting we do with whitespace we could likely get something like indentlevel + 65 characters as a decent standard, though we'd also have to set some limits on indent size (both in terms of level and how much visual space an indent level takes up).
Kinda similarly I also generally like the idea of having one character that represents a scope change; it's just a shame it's been such a PITA to do well in practice. Ultimately we likely shouldn't store syntax highlighting in source, whether that highlighting is done through placement, typeface or colour, but I don't have the foggiest how to get that toothpaste back in the tube.
marinuso@reddit
There shouldn't be too much indentation anyway if you're writing decent code. If you find yourself more than about three levels deep within a function it's generally time to extract it anyway.
TROLlox78@reddit
You mentioning whitespace reminded me of the realization I made that I basically waste two idents on a namespace and a class. They are always there, you almost never write outside them yet, we waste screenspace displaying them.
civildisobedient@reddit
The big difference is sentences have natural spacing between words, while in code you sometimes find compound-word monstrosities like EndOfYearSummaryConfigurerFactoryBean or post_bill_pay_request_without_credentials_throws_unauthorized_response_test() and there goes your 65-characters.
youngbull@reddit
If you don't indent more than 16 characters, then you end up with 65+16=81, so going with a maximum of 80 is not that bad.
Uristqwerty@reddit
Typography also usually has a multi-column layout to pack content densely despite each individual line of text being narrow. Especially for technical content where the reader will want to jump backwards to revisit previous points, or skim ahead a few paragraphs, I'd say short lines are the equivalent of micro-optimizing a bubble sort instead of using an algorithm with a larger inner loop but better overall running time.
youngbull@reddit
Programmers do that too, by having multiple windows/buffers open with other code, documentation, repl, outline, terminal, etc.
6502zx81@reddit
Nice article, bit lol it took 30 seconds to load for me.
youngbull@reddit
Yeah, not my website though. Just wanted to point out that for books and websites, readability is best between 45 and 80 characters per line. So even with 20 spaces of indentation you have a generous 60 characters left. Personally, I use a lot of compound statements (must be all that functional programming), but use autoformatting to split a statement into multiple lines. Tend to split into multiple declarations when there is reuse or I can introduce a good variable name. .
BigHandLittleSlap@reddit
The most spectacular one I’ve seen is a team that wrote about a hundred web apps all with a near-identical architecture with a separate “API” tier behind the web app front end. No, not a SPA JavaScript app! ASP.NET Web Forms running on the server.
This easily tripled the lines of code written, introduced an untold number of security vulnerabilities, killed performance, and made deployment extra complicated for no benefit whatsoever.
Why? Because twenty years ago(!) some firewall nazi refused to let the web apps talk “directly” to the database servers.
That restriction is long gone, the “front end” tier can talk directly now, but… they continue with the workaround for this limitation that no longer exists.
I saw one new trivial app use several thousand lines of code to implement this architecture.
I deleted the whole thing and replaced it with less than a hundred, fixing several security issues at the same time.
I bet their next app will have extra unnecessary tiers too. And the next, and the one after…
NotGoodSoftwareMaker@reddit
I find the 80 character limit useful because im accustomed to it. I tried 120 for a bit and it felt… wrong
Its like my brain has been trained over decades so that it can only buffer that much text per line without overloading
Loves_Poetry@reddit
For me it's the opposite. 80 characters seemed unnecessarily restrictive. Increasing it to 120 worked better and still got the point across that there shouldn't be too much code on one line
I suppose it depends on the language though. In object-oriented languages you run into character limits more often than with C for example
Ok_Comb_7542@reddit
Agree, 80 is not enough. We have 80 in our codebase, a new restriction actually, implemented without much thought along with Java Google Code Style. In my opinion it makes code harder to read because there are so many more line breaks.
It also annoys the piss out of me when it splits a short, in-line comment into two lines.
ShinyHappyREM@reddit
There's also often a situation where a certain structure is inherent in what the code does. Code like this:
... is much better structured like this:
ShadowIcebar@reddit
that looks like you're formatting your code by hand. That's always a mistake, especially in teams. Tools like prettier are the only good way.
Uristqwerty@reddit
Formatting is a sort of communication. Some people don't believe in writing comments, after seeing too many
// increase i by 1, yet hopefully most of us can agree that they're worthwhile despite the bad ones.Automatic formatting tools set a hard floor on how bad formatting may be, but also a hard ceiling on how clearly you can communicate intent though layout. Sometimes, there's a layout that would better convey the structure of a block, and unless the formatter has built-in support for that layout, the best you can do is mark a block as manually-formatted. Assuming the formatter even supports that, rather than being too opinionated to leave an escape hatch in.
ShadowIcebar@reddit
nah, sorry, manual formatting in teams wastes a ton of time and the "communication" you think you're doing by manually formatting is absolutely not worth the hassle. Any team of coders works much, much better with automated formatting.
dagbrown@reddit
I like how nobody's even mentioning the bug that, cutesy formatting aside (better hope nobody else has git commit-hooks that run
indenton your code), neither of the two "else if" clauses will ever be executed.ShinyHappyREM@reddit
Well, it's just pseudo code for showing syntax.
Miranda_Leap@reddit
I mean it's pretty bad pseudo code tbf.
babada@reddit
At some point most of us realized that you should stop being clever and instead be predictable.
Absolutely no one should put an
elseat the end of a line longer than approx 20 characters. If you're scanning through code formatted like your second example, you can't tell at a glance that there is even an if-else chain without also having to scan the far left side of the page. Especially if you're stuck reading it off a webpage without proper syntax highlighting because your company has shitty custom built internal tools.Hiding a bunch of
function2calls over there is also not ideal. It's also a pain in the ass to maintain. What if the third block needs afunction3added? Someone has to go back to all the previous blocks and add even more whitespace?This is the kind of shit that makes people add linting to code bases. Standard code formatting guidelines are often there for a reason.
Ok_Comb_7542@reddit
I the latter less readable because it breaks with the common formatting conventions.
NyuWolf@reddit
I like that, putting all the ifs aligned vertically makes it so much faster too see the logic. It also makes it faster to see the missing xyz assignment.
I understand the worry of "oh what if we need to add more stuff" but presumably this formatting is only done after the design for this system is locked in, which is what I do too, in a formatting pass later.
Of course it only works if everyone working on the code has decent taste, which is what the naysayers will point to inevitably.
Kered13@reddit
Interesting, the Google Java style uses a 100 character line limit. Google uses 80 for C++, Python, and Go.
Ok_Comb_7542@reddit
Oops, it's 100 then. Coming from 120 it felt so restrictive that I assumed 80!
XenonBG@reddit
I see what you mean, but in your example that last word doesn't really add much.
Ok_Comb_7542@reddit
Bad example, but you get my point. Often it's impossible to shorten.
silverwoodchuck47@reddit
I know this is out of scope, but isn't this 2 TODOs:
'// TODO: Refactor this calculation logic to improve clarity // TODO:handle potential division by zero errors`
NotGoodSoftwareMaker@reddit
Yea I can see something verbose like Java hitting that 80 limit very quickly
babada@reddit
I think somewhere between 80 and 120 feels right. It depends a bit on the language. Java seems to need more space. TypeScript doesn't.
aniforprez@reddit
I usually just use 88. 80 is too small and 120 is too long. It's the default line length limit in black, a python code formatter so it stuck
notkraftman@reddit
With 80 characters I can have 4 editors side by side, with 120 I can only have 3. I'd rather use my screen than have a tonne of blank space just in case someone decides to make a really long line.
temp1211241@reddit
Tabbed terminals or widows for testing and also it's a pretty reasonably long line.
yturijea@reddit
This can not have enough get enough upvotes. Having to slide right in a PR review...
jc-from-sin@reddit
We have better ways to visualise diffs rather than side by side tabs.
phil_davis@reddit
...asking for a friend, what are they?
jc-from-sin@reddit
Inline diff
Kered13@reddit
Inline diffs are much harder to read than side-by-side.
latkde@reddit
Maybe that works for you, but inline/unified diffs aren't inherently better or worse than the side-by-side formatting.
I like unified diffs when working on a change, but always use side-by-side diffs when reviewing code. It shows a clear before/after state.
jc-from-sin@reddit
Inline shows exactly what has changed, not just the before and after. Some changes can be subtle.
latkde@reddit
You can see the changes in both layouts.
For illustration, here's an arbitrary recent commit from the Python interpreter:
All of this is a very personal and subjective preference. But the key point is that some people do legitimately prefer split diffs at least some of the time.
temp1211241@reddit
You will find at some point in your career not every diff is actually conducive to inline viewing, consider yourself lucky to have not run into that yet at this point.
jc-from-sin@reddit
You can say exactly the same thing about the opposite.
Plorkyeran@reddit
Correct, both have scenarios where they're good. Pretending that one is strictly better than the other is the problem.
babada@reddit
You don't always get to pick your diff tooling. Working at big companies can suck.
babada@reddit
Yeah, I think this post is a great example of why we tend to leave well enough alone. An 80-character line limit is arbitrary but it does have a few remaining benefits and my faith in junior developers was shattered when some of them started checking in 200+ character lines.
So I turned the rule on and set it to something like 120.
matthieum@reddit
I use 120 too.
On my work screen, I can have 3 columns of 120 characters text, complete with file overview on the left, and file overview on the right. Perfect.
alternateme@reddit
Similarly, we've updated our standards to 'should' not exceed 120.
franklindstallone@reddit
For a sector that likes to think of itself as a bunch of disruptors there is one thing software refuses to disrupt and that's how it operates.
zam0th@reddit
Oh, we do question it a'right, but then things keep turning out like: * a C-level likes it the way it is, because "they're the decision-maker" and "they know best". * an obscure regulatory standard mandates certain ways of doing certain things which can't be changed, avoided or circumvented without legal consequences or a lengthy and costly audit. * an optimization change requires a financial model with a 5-year ROI, an approval from two committees and a formally issued directive from the CEO, followed by a mandatory "transformation project". * enacting the change requires a huge amount of monies the company doesn't have (or rather it does, just not for this particular stuff). * actually enacting the change does indeed require a huge amount of both monies and mandays which makes it objectively non-feasible. * a significant proportion of your IT staff is going to leave (or will threaten to leave) because of the change.
The list can go on forever.
OMGItsCheezWTF@reddit
I found an @todo in some code recently that said "@todo check if we need to do this"
followed by a chunk of commented out code
and a comment that said @dontdo we don't.
theboston@reddit
So many people in this thread just talking about whether they agree with an 80 character line limit or not and missing the whole point of this post...
Plorkyeran@reddit
Using bad examples to support a point does tend to result in people disregarding the point you were trying to make.
Hail_CS@reddit
Used to work in fiber optic telecom and the things I saw made me decide to leave. There was a file from 1978 that had a 10,000+ line else if(!strcmp(...)) chain I had to work on. I wasn't allowed to refactor it in any way, just had to work with it the way it was.
TheFaithfulStone@reddit
This will get buried - which is too bad because this is an important realization. There is a large component of everything that is this way. You do things the way they’re done. This makes the thing you’ve done “legible” to the next person to look at it. Four walls and a pointy roof? That’s a house! The things that people produce this way are “cultural texts” they are used by groups of people to do stuff without having to explain from first principles why you do thing a certain way.
This is also how an LLM works: we fed it a GIANT collection of cultural texts and it produces infinitely more cultural text - but it ONLY produces the bits that are “the way it’s done” - the name for this portion of “doing a thing” is habitus. Habitus is actually humanity’s secret weapon for “winning” evolution. I don’t need to I dependently discover how to do everything, I can just do shit “how it’s done” and get like 80% of the way there.
The problem is that habitus is not always right. Like what you’re describing. The world changes faster than the culture, and the culture has to change to keep up with it. “People should be able to say whatever they want!” is a good idea when powerful interests control the press. Less so when you introduce memetic viruses controlled by immortal sociopaths into the mix.
Anyway, I begging all of you to take an anthropology class. You’ll learn so much about software.
Caraes_Naur@reddit
I am one of the scant few users of an open source issue tracking project. I spent a lot of time last year cleaning up and invisibly modernizing the UI only for the project lead to deny my PRs because they "like to keep the amount of Javascript low".
I'm no fan of JS, but I didn't add any frameworks, just some vanilla functions.
About 25% of the initial git commit (in 2004) is still part of the current HEAD. Current version of the project is 1.0-rc11. I have backups from late 2016 of version 1.0-rc1.
The entire project is a zombie. I need to resume porting it to Laravel.
seven_seacat@reddit
now I want to know which project 👀
BalticSprattus@reddit
Flyspray
Caraes_Naur@reddit
My original comment contains enough info to figure it out.
voteyesatonefive@reddit
Surely you wouldn't port it to the worst framework from scratch but instead use the best, symfony.
XenonBG@reddit
I'm forced to work with Laravel and this resonates haha.
Heck, even Laravel uses Symfony.
Galactic_Neighbour@reddit
Kinda reminds me of OpenStreetMap website and how they wouldn't add a dark theme for like 5 years, because they were afraid to add too much CSS. So they closed every PR that tried to implement it until they migrated to Bootstrap 5, which has built-in support for this.
Berkyjay@reddit
Process and homogeneity in code is important. It's especially important to large code bases and large dev teams. This is why things like PEP exist. We want the next developer to be able to come into a code base and understand what's going on as fast as possible. That means standardized coding practices. But the drawback to this is that once you establish a standard in a large code base, it takes a lot of work (money) to change it. So yes, you do get stagnation. But businesses will rarely prioritize modernization over stability and cost.
macca321@reddit
Blocking pr reviews before merge
Clairvoidance@reddit
it's just aesthetic
Ileana_llama@reddit
Maykey@reddit
I like it (OK, I actually like 90-characters limit) as my sight is far from perfect. Small width means I can read text easily without mixing ; and : and have some narrow window to the side.
azirale@reddit
Working on a data platform and every data transfer is in CSV format and must have a footer row with metadata for record counts and other metadata like a checksum for the preceding content.
This all made sense when data was being moved around with bash commands and you could just tail/head for the metadata or to cut it out. In our distributed cloud platform it was hell. The distributed model completely breaks the ability to replicate the checksum, and it had no concept of excluding a trailer row. The checksum was also pointless because you don't get random corruption during upload as the storage service checks correctness automatically.
We ended up having to have an extra single-machine "preprocessor" to handle all redundant checksum work and then rewriting a new copy of the file without the trailer, which could then finally go through the distributed processor.
It was a massive waste of time and resources for every transfer, just to appease some internal standard that had been practically defunct for years.
AssistanceNew4560@reddit
I loved the article. The turkey analogy is perfect for illustrating how in software engineering we often follow processes without question. It's a much-needed reminder that we should always ask ourselves the "why" behind what we do.
elmuerte@reddit
There isn't, because I banned them.