![]() ![]() The star of the time, dominating the industry, was IBM’s 80 columns by 12 rows card. Back in that time, when the first terminals were designed, people working with anything computer-like primarily knew one common storage media: punched cards. Sure, the state of 1960s display technology had definitely some impact as well, but the choice was ultimately made out of habit rather than necessity. Considering we’re talking about the late 1960s here, it seems plausible that display technology simply wasn’t advanced enough to make it feasible to have bigger screens and longer lines, and that’s how they ended up with 80 characters. There were exceptions in either direction, 72 and 132 for example, but 80 was the most common one. Yes, since the early days of terminals, the screen size was indeed mostly limited to 80 characters. Well that didn’t help at all now, did it? So let’s take a few steps back. It all just seems to magically come together somehow, and that’s how things are, period. ![]() The 80 characters are just all around us - there are these devices of yesteryear with their 80 character displays, your terminal emulator’s default width comes preset to 80 columns, and of course all those coding style guides that keep bringing up the 80 character line limit. ![]() Where does that limitation come from anyway? It seems like one of those things everyone knows about and follows without questioning or really understanding it. But he has a point does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020? Of course, all to a certain extent, and obviously doesn’t call for abolishing line breaks altogether. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.Īllowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. ’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time. In case of the Linux kernel, that’s of course, who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. But larger projects that are accustomed to a multitude of random contributors will typically have one defined, which was either worked out by the core developers, or declared by its benevolent dictator for life. If no official style guide exists, the graceful thing to do is to simply adopt the code base’s current style when contributing to it. The situation can get a bit more complex in open source projects though, depending on the structure and size of a project. In a professional environment, a style guide was ideally worked out collaboratively inside or between teams, and input and opinions of everyone involved were taken into consideration - and if your company doesn’t have one to begin with, the best step to take is probably one towards the exit. Regardless of taste, the worst decision is having no decision, and even if you don’t agree with a specific detail, it’s usually best to make peace with it for the benefit of uniformly formatted code. Latest when there’s more than one developer collaborating, it’s time to find a common agreement in form of a coding style guide, which might of course require a bit of compromise. Others seem more of a personal preference at first, but can end up equally fundamental on a bigger scale - like which character to choose for indentation, where to place the curly braces, or how to handle line breaks. Some of them can be fundamental to a project - like choice of language or the programming paradigm to begin with. Software developers won’t ever run out of subjects to argue and fight about. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |