5 ms·

I'm a beginner dev and I find it very odd both that vscode tries to limit my commit messages to 50 or 55 characters, and also that python linters want to make m

I'm a beginner dev and I find it very odd both that vscode tries to limit my commit messages to 50 or 55 characters, and also that python linters want to make my lines of code so small. What's the reason behind this? Old small monitors of the past? I also don't get why fediverse, mastodon seem to limit characters on a post, mimicking the stupid twitter, which is a niche social network. I way be wrong about the limit (never tried), but these platforms feel for ignorant outsiders like twitter-clones with a different infrastructure.

funcDropShadow 3y ago
> tries to limit my commit messages to 50 or 55 characters The tools try to limit the summary line of Git commit message to 50 characters. Not the whole message. That is a useful convention. The usual convention is described here: https://git-scm.com/docs/git-commit#_discussion https://git-scm.com/docs/git-commit#_discussion
wodenokoto 3y ago
Yes, old monitors are the reason why we have line lengths as they are. The reason why we still have them is a mix between inertia, it’s hard to read long lines and it’s nice to be able to have two files side by side. Mastodon is a twitter clone, with different infrastructure.
- gverrilla 3y ago
  I'm only a begginer, of course, but it seems to be long lines are better than broken ones. `MyDict[family][subfamily][element][property_a][value]` is much better imo than: ``` MyDict[family][subfamily][element][property_a][ value ] ``` Probably the data format is what's wrong here in the first place, lol, but anyhow.
  - wodenokoto 3y ago
    When using pandas in Python you are encouraged to keep each “chained operation “ on its own line. (MyDict [family] [subfamily] [element] [property_a] [value] ) I honestly think all suggestions here are equally bad in their own regards.
  - cerved 3y ago
    If a long line can't be hardwrapped nicely at 80 chars, it typically means there's room for improvement in the actual code.
  - yungporko 3y ago
    i'd say that this is much nicer than both. there is always a better option than an abnormally long line. personally i limit my lines to 120 characters MyDict [family] [subfamily] [element] [property_a] [value]
    - gverrilla 3y ago
      it's very clear indeed, but makes the code much harder to navigate in my opinion, and makes it look more complex than it really is, particularly for absolute beginners. In python, specifically, where indents matter, these line breaks seem very confusing for those starting to learn.
      - Brian_K_White 3y ago
        Significant whitespace is a python problem not a whitespace problem. I am not one of the ones who cry about Make, but many do and for that reason primarily.
  - broscillator 3y ago
    I don't think the first example is a long line. Imagine opening a book, and to have to read sentences that span both pages rather than just one. It's uncomfortable for the eye and it makes it harder to keep track of the motion of finishing one line on the right, and starting the next one on the left. Similar to how websites employ a lot of white space, imagine if instead the text went from the first pixel on the left to the last one on the right, it feels awkward.
  - addicted 3y ago
    The solution to long lines isn’t to break up the line. The solution would have been (let’s say JS since that’s the most “beginner”ish language where this could even have a perf impact”): const myElement = myDict[family][subfamily][element]; const propValue = myElement[property][value];
  - dsego 3y ago
    Ideally, you would never access deep props like that. First it's easy to make a mistake, and secondly each of those keys can fail if the dict doesn't contain that prop. You probably want to de-structure it first, depending on the language, or use a path getter that has a fallback value (or even better, use strictly defined object types). Long lines are usually a code smell and harder to visually parse and understand. I don't adhere to 80 chars, but somewhere around 100-120 is comfortable.
  - _ZeD_ 3y ago
    both of the lines you've showed are poorly readable. not for the length itself, but for the attached mental needs needed to understand the `MyDict` data structure (that is the only variable here in your expression). that said, having a max-length, apart from the eyesight reasons, have this nice side effect that make it blatantly obvious that one expression is definitely too complex, as you've shown in your second example
kingkongjaffa 3y ago
Its mostly tribal knowledge at this point built on the echo of “studies show 80 is the best for comprehension and understanding” 80 should be fine for most single lines of good code in most languages. Comments can usually be longer so I have my linter ignore comment length. Some discussion here: https://stackoverflow.com/questions/578059/studies-on-optimal-code-width https://stackoverflow.com/questions/578059/studies-on-optima... For me it’s one of those things without a “scientific” answer, but the status quo is good enough that it’s easier to just go with it and never think about it again. Like linting and autoformatting, tabs vs spaces, all trivial stuff that detracts energy from building a product for customers.
- KronisLV 3y ago
  > 80 should be fine for most single lines of good code in most languages. It feels like what's doable in one language, might be a bit more restrictive and annoying to follow in another one. For example, Java, when written in an idiomatic way, with verbose variable names etc.
- DrBazza 3y ago
  > 80 should be fine for most single lines of good code in most languages. C++ with even a modest template will flow over 80 without much effort. I'm now using the condensed width font Iosevka font [1] with 160 chars as my max width in clang-format and indents at 1. After a few days of using it, I'm converted. It was a bit odd looking at first, but I guess that's brain plasticity at work. 1. https://github.com/be5invis/Iosevka/releases https://github.com/be5invis/Iosevka/releases
- joshka 3y ago
  I've written a lot of code in a lot of different languages and have preferences for each that are based on the general type of code that tends to be written. E.g. what length are the identifiers and standard function names, what is the standard spacing, how are idiomatic language features used. My subjective opinions on a few of them: Java I find works well with a soft 100, hard 120. The language and library tends to prefer and encourage longer class and function names, and these are often repeated multiple times in a single line. C# seems to work well with 100. Rust I find well works with 100, and this is the default out of the box format for rustfmt. Javascript (especially with 2 spaces) works well with 80 characters. When writing code for documentation sites (e.g. https://ratatui.rs/tutorials/hello-world/ https://ratatui.rs/tutorials/hello-world/), often the code block fits in an area which is surrounded by prose with a width optimized for reading. The resulting width of the code block tends to be ~80 or less. It's worth making this tweak to your formatting for such example code.
JimBlackwood 3y ago
Hah, this reminds me of my C++ professor requiring a max line width of 80 characters. My first question was “why not more!?” aswell. He would have the homework submissions compiled to LaTeX and printed out - then he would write comments by hand. 80 characters was what would fit on a line. If you had more characters, lines wrapped wrongly and you’d get incorrect looking code - so he refused to grade. I’ve since warmed up to the max line width idea. It’s nice to be able to read code on a small width window (I’ll rarely have a single full screen window with just code) and ensure each line is a valid syntax (and not unreadable due to softwrap in the editor). But I still think 80 chars is a bit extreme. 120 is nicer in my opinion.
- sgarland 3y ago
  On my docked laptop with a quad-split 43” 4K, I am definitely in the camp of wider is better. Then I pull out my 13” Air and remind myself that there are reasons for limits. For Python, I just default to black, which is 88 chars. Easier to not argue with people that way. Plus, I’m free to write it with super wide columns if I want, and then let my precommit hook fix it.
  - i80and 3y ago
    Opinionated formatters are the way out of this. Black, as you mention, is a godsend. I'm really disappointed by how weak the dotnet formatter is in comparison.
- dahart 3y ago
  80 char limits used to be very common in school and business, I’m old enough that most of my professors preferred it, and most students actually did too. My first programming jobs required it as well. There were a few students who felt limited, or had fun intentionally acting flippant or incredulous about these limits when their screens were more than 80 chars wide. The rule is slightly anachronistic now, and originally came from the time when CRT terminals (and printers) were 80 columns of text, and there was no graphical window manager. The rule was primarily about making code comfortable to read for everyone involved, to meet the minimum display with of anyone in the group. If you have a wide display but I don’t then it sucks for me. Plus I’m pretty sure that when I first started programming, a lot of printers and text editors and a lot of software wasn’t very good at handling long lines and characters would get mugged or discarded. Almost everything today will just wrap and display reasonably, but that wasn’t always the case back in the days of ed/edlin and earlier. These days I hardly ever hear about width limits anymore, though it does come up every once in a while when people have to work a lot in terminal or ssh sessions. I do have to drop into Linux non-graphical mode all the time, and even edits files and build code sometimes, and code that’s wider than the display is less fun to wade through. People still like having a reasonable limit, like we’d definitely get complaints if we start writing code that’s 500 characters on a line, right? :P
thejosh 3y ago
Not sure if you mean the git commit "title" and the "body", but the way git works is that the first line is the summary/title and then a blank line, then the body/description. I really like this approach, a nice short message with a summary, followed by a longer description in the "body". One feature I really like from GitHub is you can set an option when merging a Pull Requests that when merging the commit title will be the Pull Request title, and the body of the PR as the message.
zaptheimpaler 3y ago
Yeah the git thing is just a dumb hangover from very old times that really should not exist anymore. The lines should be as long as they need to be, and the frontend like the git CLI or GitHub can wrap them if needed. Thats how we do it in literally any other sane context because the frontend has the information on the available display size. "ls" doesn't randomly force you into 80char columns it adjusts. I don't like break this comment every 50 chars either. Only in git world everyone accepts this insanity. Join me, ignore the dumb red lines and make your commit message as long as you like. Linters are usually easy to configure and set to wrap at e.g 120 as well.
- joshka 3y ago
  Github doesn't wrap them on code listing pages.
kissgyorgy 3y ago
The first line of the commit (the subject) should be short, succinct, but descriptive, because this way it will fit in all kinds of GUIs, CLI whatnot. There are a lot of interfaces for Git you doesn't even know about.
kzrdude 3y ago
mastodon instances can choose their own limit
heads 3y ago
There are plenty of good reasons for short line lengths. Two factors constrain the max line length down to something not much more than 80 columns: side-by-side diffs and waning eyesight. In-line diffs mix the flow of change in with the flow of execution, both going down the page. Side-by-side diffs makes those two axes orthogonal. With decorations (either in a terminal or a code review tool) even 80 column code requires a fairly small font. Editing two panes of code only needs 161 columns but a decorated patch might be more like 170. The point font size is its height in increments of 1/72”, and most fonts are half as wide as their point height. The largest font one can use on a 27” monitor (24” wide) is 20pt. My eyes get knackered at anything smaller than 18pt.
IshKebab 3y ago
Yeah it made sense for old monitors and then a lot of people got into their minds that it was some kind of rule that could never be changed. The limits you should observe today are more like: * Code line length: ~120-140 characters. Longer than that and it gets unwieldy especially in side-by-side views. But you don't need to be strict about it. It doesn't matter if the occasional line overflows. The best code formatting algorithm I know (the Prettier algorithm) doesn't have a strict limit. * Commit subject length: 72, because Github will overflow anything longer into an ellipsis. * Commit body line lines: No limit (unless you are developing the Linux kernel). I don't know of an interface other than email that doesn't wrap them. (You're going to get a lot of old farts disagreeing with this advice, but don't listen to them.)
- _ZeD_ 3y ago
  >>> (You're going to get a lot of old farts disagreeing with this advice, but don't listen to them.) "I used to be with 'it', but then they changed what 'it' was. Now what I'm with isn't 'it' anymore and what's 'it' seems weird and scary. It'll happen to you!" seriously, it's not "being old farts", it's being reasonable with your eyes and your tools: while you may have 20/20 eyes, you will agree with me that viewing a diff of two columns of code at 10px fonts is not an happy thing to do, as the difference may be just a comma or a dot, and those on a 15" 4k monitor are about 0.3mm. And you cannot really view the whole columns without scrollbars or overflows if you set the font much bigger.
- matklad 3y ago
  >I don't know of an interface other than email that doesn't wrap them. Here are some common examples: 1. GitHub's single commit view word-wraps at monitor width, not at a reasonable line length: https://github.com/matklad/repros/commit/9351f5c91bd1d80dbcc37719d6ddd0f306b9c780 https://github.com/matklad/repros/commit/9351f5c91bd1d80dbcc... The result is completely unreadable. 2. `git log` in a full-screen terminal wraps at window width, not at a readable length. 3. In VS Code in Magit, lines are not wrapped at all by default. It is possible to enable wrapping, but then they are wrapped at the screen edge, not at a readable line length. I _think_ VS Code actually has a setting to visually wrap at column, but I wasn't able to make that work. Additionally, if you look at that commit message, you'll see that, to properly soft-wrap it, you'll need a markdown parser to recognize an indented bullet list. VS Code actually wraps that list correctly, but I expect very few other tools to do that.
Arch-TK 3y ago
> I'm a beginner dev and I find it very odd both that vscode tries to limit my commit messages to 50 or 55 characters, and also that python linters want to make my lines of code so small. What's the reason behind this? Old small monitors of the past? On my laptop with a 13.3" 1080p display I can fit two side-by-side terminals at 87 characters wide (two of these are used up by vim to display git symbols and linter markers, I don't use a number line). This is not because I can't afford a laptop with a bigger screen, but rather that I value portability, lightness and thinness over screen size. That being said, on larger desktop monitors I also value easy readability meaning that the font size is usually so large that I don't get much more than 90 characters per column. This means I can have a man-page or other form of documentation as well as an interpreter window on the right side of my screen (in two stacked windows) and the code on the left side of my screen. I really don't even quite understand how people handle the defaults of VSCode with its enormous directory tree column and the minimap. about 40% of horizontal screen space is wasted in the default VSCode configuration. I mean, to some extent, multi-monitor setups help solve this, but again, I value portability and while I do have a multi-monitor setup, I don't want to be reliant on it to be able to comfortably get work done. So, at least for me, there's an enormous amount of value in keeping things to 80 characters in width. This doesn't mean I never go over that limit, it just means that most of my code is comfortably readable both when using a small laptop and when using a larger desktop setup. The other main reason is making it easier to read. It's not that helpful or easy to keep track of a line which is 120 characters long. Not least of all because in my setup it would either end up off-screen or badly hard-wrapped. There's a reason newspapers still use columns and it's so it's easier to keep track of where you are in a paragraph. Now in code, it's not usually 10 120 character lines one after another, but usually it's still harder to make sense of what you're looking at when it's one really long line.
Vinnl 3y ago
It's useful in situations where you don't have the entire commit message expanded on screen. For example, when running `git blame` on a file, or the same functionality in a web UI like here: https://vincenttunru.com/img/Commits-are-documentation/annotations.png https://vincenttunru.com/img/Commits-are-documentation/annot... As for regular code, similarly, there are situations where the code doesn't take up the full screen, e.g. in split-screen mode, or viewing a side-by-side diff. That said, there's a balance to be struck between facilitating those use cases and facilitating the common use case of reading (or even writing) the code, and there's no clear "right" answer. Which is probably why there are so many debates on this.
- joshka 3y ago
  This is the correct answer
nemoniac 3y ago
You could break this up into two steps. The first is agreeing on a width limit, whatever that width might be. Such a limit might already be controversial but it seems to make sense. The second is the question of what that width limit should be. There's a fun story about the with of our railway gauges and roads and Roman chariots that has the lovely quote that if you"...wonder what horse's ass came up with it, you may be exactly right." https://www.snopes.com/fact-check/railroad-gauge-chariots/ https://www.snopes.com/fact-check/railroad-gauge-chariots/ When it comes to an 80(ish) character limit, that does indeed come from old monitors, which took it from older line printers before them. https://en.wikipedia.org/wiki/ADM-3A https://en.wikipedia.org/wiki/ADM-3A But it all goes back to Hollerith cards, which were invented in the late 19th century and used in a US census at around that time. https://en.wikipedia.org/wiki/Punched_card https://en.wikipedia.org/wiki/Punched_card

funcDropShadow 3y ago

> tries to limit my commit messages to 50 or 55 characters The tools try to limit the summary line of Git commit message to 50 characters. Not the whole message. That is a useful convention. The usual convention is described here: https://git-scm.com/docs/git-commit#_discussion https://git-scm.com/docs/git-commit#_discussion

wodenokoto 3y ago

Yes, old monitors are the reason why we have line lengths as they are. The reason why we still have them is a mix between inertia, it’s hard to read long lines and it’s nice to be able to have two files side by side. Mastodon is a twitter clone, with different infrastructure.

gverrilla 3y ago
I'm only a begginer, of course, but it seems to be long lines are better than broken ones. `MyDict[family][subfamily][element][property_a][value]` is much better imo than: ``` MyDict[family][subfamily][element][property_a][ value ] ``` Probably the data format is what's wrong here in the first place, lol, but anyhow.
- wodenokoto 3y ago
  When using pandas in Python you are encouraged to keep each “chained operation “ on its own line. (MyDict [family] [subfamily] [element] [property_a] [value] ) I honestly think all suggestions here are equally bad in their own regards.
- cerved 3y ago
  If a long line can't be hardwrapped nicely at 80 chars, it typically means there's room for improvement in the actual code.
- yungporko 3y ago
  i'd say that this is much nicer than both. there is always a better option than an abnormally long line. personally i limit my lines to 120 characters MyDict [family] [subfamily] [element] [property_a] [value]
  - gverrilla 3y ago
    it's very clear indeed, but makes the code much harder to navigate in my opinion, and makes it look more complex than it really is, particularly for absolute beginners. In python, specifically, where indents matter, these line breaks seem very confusing for those starting to learn.
    - Brian_K_White 3y ago
      Significant whitespace is a python problem not a whitespace problem. I am not one of the ones who cry about Make, but many do and for that reason primarily.
- broscillator 3y ago
  I don't think the first example is a long line. Imagine opening a book, and to have to read sentences that span both pages rather than just one. It's uncomfortable for the eye and it makes it harder to keep track of the motion of finishing one line on the right, and starting the next one on the left. Similar to how websites employ a lot of white space, imagine if instead the text went from the first pixel on the left to the last one on the right, it feels awkward.
- addicted 3y ago
  The solution to long lines isn’t to break up the line. The solution would have been (let’s say JS since that’s the most “beginner”ish language where this could even have a perf impact”): const myElement = myDict[family][subfamily][element]; const propValue = myElement[property][value];
- dsego 3y ago
  Ideally, you would never access deep props like that. First it's easy to make a mistake, and secondly each of those keys can fail if the dict doesn't contain that prop. You probably want to de-structure it first, depending on the language, or use a path getter that has a fallback value (or even better, use strictly defined object types). Long lines are usually a code smell and harder to visually parse and understand. I don't adhere to 80 chars, but somewhere around 100-120 is comfortable.
- _ZeD_ 3y ago
  both of the lines you've showed are poorly readable. not for the length itself, but for the attached mental needs needed to understand the `MyDict` data structure (that is the only variable here in your expression). that said, having a max-length, apart from the eyesight reasons, have this nice side effect that make it blatantly obvious that one expression is definitely too complex, as you've shown in your second example

kingkongjaffa 3y ago

Its mostly tribal knowledge at this point built on the echo of “studies show 80 is the best for comprehension and understanding” 80 should be fine for most single lines of good code in most languages. Comments can usually be longer so I have my linter ignore comment length. Some discussion here: https://stackoverflow.com/questions/578059/studies-on-optimal-code-width https://stackoverflow.com/questions/578059/studies-on-optima... For me it’s one of those things without a “scientific” answer, but the status quo is good enough that it’s easier to just go with it and never think about it again. Like linting and autoformatting, tabs vs spaces, all trivial stuff that detracts energy from building a product for customers.

KronisLV 3y ago
> 80 should be fine for most single lines of good code in most languages. It feels like what's doable in one language, might be a bit more restrictive and annoying to follow in another one. For example, Java, when written in an idiomatic way, with verbose variable names etc.
DrBazza 3y ago
> 80 should be fine for most single lines of good code in most languages. C++ with even a modest template will flow over 80 without much effort. I'm now using the condensed width font Iosevka font [1] with 160 chars as my max width in clang-format and indents at 1. After a few days of using it, I'm converted. It was a bit odd looking at first, but I guess that's brain plasticity at work. 1. https://github.com/be5invis/Iosevka/releases https://github.com/be5invis/Iosevka/releases
joshka 3y ago
I've written a lot of code in a lot of different languages and have preferences for each that are based on the general type of code that tends to be written. E.g. what length are the identifiers and standard function names, what is the standard spacing, how are idiomatic language features used. My subjective opinions on a few of them: Java I find works well with a soft 100, hard 120. The language and library tends to prefer and encourage longer class and function names, and these are often repeated multiple times in a single line. C# seems to work well with 100. Rust I find well works with 100, and this is the default out of the box format for rustfmt. Javascript (especially with 2 spaces) works well with 80 characters. When writing code for documentation sites (e.g. https://ratatui.rs/tutorials/hello-world/ https://ratatui.rs/tutorials/hello-world/), often the code block fits in an area which is surrounded by prose with a width optimized for reading. The resulting width of the code block tends to be ~80 or less. It's worth making this tweak to your formatting for such example code.

JimBlackwood 3y ago

Hah, this reminds me of my C++ professor requiring a max line width of 80 characters. My first question was “why not more!?” aswell. He would have the homework submissions compiled to LaTeX and printed out - then he would write comments by hand. 80 characters was what would fit on a line. If you had more characters, lines wrapped wrongly and you’d get incorrect looking code - so he refused to grade. I’ve since warmed up to the max line width idea. It’s nice to be able to read code on a small width window (I’ll rarely have a single full screen window with just code) and ensure each line is a valid syntax (and not unreadable due to softwrap in the editor). But I still think 80 chars is a bit extreme. 120 is nicer in my opinion.

sgarland 3y ago
On my docked laptop with a quad-split 43” 4K, I am definitely in the camp of wider is better. Then I pull out my 13” Air and remind myself that there are reasons for limits. For Python, I just default to black, which is 88 chars. Easier to not argue with people that way. Plus, I’m free to write it with super wide columns if I want, and then let my precommit hook fix it.
- i80and 3y ago
  Opinionated formatters are the way out of this. Black, as you mention, is a godsend. I'm really disappointed by how weak the dotnet formatter is in comparison.
dahart 3y ago
80 char limits used to be very common in school and business, I’m old enough that most of my professors preferred it, and most students actually did too. My first programming jobs required it as well. There were a few students who felt limited, or had fun intentionally acting flippant or incredulous about these limits when their screens were more than 80 chars wide. The rule is slightly anachronistic now, and originally came from the time when CRT terminals (and printers) were 80 columns of text, and there was no graphical window manager. The rule was primarily about making code comfortable to read for everyone involved, to meet the minimum display with of anyone in the group. If you have a wide display but I don’t then it sucks for me. Plus I’m pretty sure that when I first started programming, a lot of printers and text editors and a lot of software wasn’t very good at handling long lines and characters would get mugged or discarded. Almost everything today will just wrap and display reasonably, but that wasn’t always the case back in the days of ed/edlin and earlier. These days I hardly ever hear about width limits anymore, though it does come up every once in a while when people have to work a lot in terminal or ssh sessions. I do have to drop into Linux non-graphical mode all the time, and even edits files and build code sometimes, and code that’s wider than the display is less fun to wade through. People still like having a reasonable limit, like we’d definitely get complaints if we start writing code that’s 500 characters on a line, right? :P

thejosh 3y ago

Not sure if you mean the git commit "title" and the "body", but the way git works is that the first line is the summary/title and then a blank line, then the body/description. I really like this approach, a nice short message with a summary, followed by a longer description in the "body". One feature I really like from GitHub is you can set an option when merging a Pull Requests that when merging the commit title will be the Pull Request title, and the body of the PR as the message.

zaptheimpaler 3y ago

Yeah the git thing is just a dumb hangover from very old times that really should not exist anymore. The lines should be as long as they need to be, and the frontend like the git CLI or GitHub can wrap them if needed. Thats how we do it in literally any other sane context because the frontend has the information on the available display size. "ls" doesn't randomly force you into 80char columns it adjusts. I don't like break this comment every 50 chars either. Only in git world everyone accepts this insanity. Join me, ignore the dumb red lines and make your commit message as long as you like. Linters are usually easy to configure and set to wrap at e.g 120 as well.

joshka 3y ago
Github doesn't wrap them on code listing pages.

kissgyorgy 3y ago

The first line of the commit (the subject) should be short, succinct, but descriptive, because this way it will fit in all kinds of GUIs, CLI whatnot. There are a lot of interfaces for Git you doesn't even know about.

kzrdude 3y ago

mastodon instances can choose their own limit

heads 3y ago

There are plenty of good reasons for short line lengths. Two factors constrain the max line length down to something not much more than 80 columns: side-by-side diffs and waning eyesight. In-line diffs mix the flow of change in with the flow of execution, both going down the page. Side-by-side diffs makes those two axes orthogonal. With decorations (either in a terminal or a code review tool) even 80 column code requires a fairly small font. Editing two panes of code only needs 161 columns but a decorated patch might be more like 170. The point font size is its height in increments of 1/72”, and most fonts are half as wide as their point height. The largest font one can use on a 27” monitor (24” wide) is 20pt. My eyes get knackered at anything smaller than 18pt.

IshKebab 3y ago

Yeah it made sense for old monitors and then a lot of people got into their minds that it was some kind of rule that could never be changed. The limits you should observe today are more like: * Code line length: ~120-140 characters. Longer than that and it gets unwieldy especially in side-by-side views. But you don't need to be strict about it. It doesn't matter if the occasional line overflows. The best code formatting algorithm I know (the Prettier algorithm) doesn't have a strict limit. * Commit subject length: 72, because Github will overflow anything longer into an ellipsis. * Commit body line lines: No limit (unless you are developing the Linux kernel). I don't know of an interface other than email that doesn't wrap them. (You're going to get a lot of old farts disagreeing with this advice, but don't listen to them.)

_ZeD_ 3y ago
>>> (You're going to get a lot of old farts disagreeing with this advice, but don't listen to them.) "I used to be with 'it', but then they changed what 'it' was. Now what I'm with isn't 'it' anymore and what's 'it' seems weird and scary. It'll happen to you!" seriously, it's not "being old farts", it's being reasonable with your eyes and your tools: while you may have 20/20 eyes, you will agree with me that viewing a diff of two columns of code at 10px fonts is not an happy thing to do, as the difference may be just a comma or a dot, and those on a 15" 4k monitor are about 0.3mm. And you cannot really view the whole columns without scrollbars or overflows if you set the font much bigger.
matklad 3y ago
>I don't know of an interface other than email that doesn't wrap them. Here are some common examples: 1. GitHub's single commit view word-wraps at monitor width, not at a reasonable line length: https://github.com/matklad/repros/commit/9351f5c91bd1d80dbcc37719d6ddd0f306b9c780 https://github.com/matklad/repros/commit/9351f5c91bd1d80dbcc... The result is completely unreadable. 2. `git log` in a full-screen terminal wraps at window width, not at a readable length. 3. In VS Code in Magit, lines are not wrapped at all by default. It is possible to enable wrapping, but then they are wrapped at the screen edge, not at a readable line length. I _think_ VS Code actually has a setting to visually wrap at column, but I wasn't able to make that work. Additionally, if you look at that commit message, you'll see that, to properly soft-wrap it, you'll need a markdown parser to recognize an indented bullet list. VS Code actually wraps that list correctly, but I expect very few other tools to do that.

Arch-TK 3y ago

> I'm a beginner dev and I find it very odd both that vscode tries to limit my commit messages to 50 or 55 characters, and also that python linters want to make my lines of code so small. What's the reason behind this? Old small monitors of the past? On my laptop with a 13.3" 1080p display I can fit two side-by-side terminals at 87 characters wide (two of these are used up by vim to display git symbols and linter markers, I don't use a number line). This is not because I can't afford a laptop with a bigger screen, but rather that I value portability, lightness and thinness over screen size. That being said, on larger desktop monitors I also value easy readability meaning that the font size is usually so large that I don't get much more than 90 characters per column. This means I can have a man-page or other form of documentation as well as an interpreter window on the right side of my screen (in two stacked windows) and the code on the left side of my screen. I really don't even quite understand how people handle the defaults of VSCode with its enormous directory tree column and the minimap. about 40% of horizontal screen space is wasted in the default VSCode configuration. I mean, to some extent, multi-monitor setups help solve this, but again, I value portability and while I do have a multi-monitor setup, I don't want to be reliant on it to be able to comfortably get work done. So, at least for me, there's an enormous amount of value in keeping things to 80 characters in width. This doesn't mean I never go over that limit, it just means that most of my code is comfortably readable both when using a small laptop and when using a larger desktop setup. The other main reason is making it easier to read. It's not that helpful or easy to keep track of a line which is 120 characters long. Not least of all because in my setup it would either end up off-screen or badly hard-wrapped. There's a reason newspapers still use columns and it's so it's easier to keep track of where you are in a paragraph. Now in code, it's not usually 10 120 character lines one after another, but usually it's still harder to make sense of what you're looking at when it's one really long line.

Vinnl 3y ago

It's useful in situations where you don't have the entire commit message expanded on screen. For example, when running `git blame` on a file, or the same functionality in a web UI like here: https://vincenttunru.com/img/Commits-are-documentation/annotations.png https://vincenttunru.com/img/Commits-are-documentation/annot... As for regular code, similarly, there are situations where the code doesn't take up the full screen, e.g. in split-screen mode, or viewing a side-by-side diff. That said, there's a balance to be struck between facilitating those use cases and facilitating the common use case of reading (or even writing) the code, and there's no clear "right" answer. Which is probably why there are so many debates on this.

joshka 3y ago
This is the correct answer

nemoniac 3y ago

You could break this up into two steps. The first is agreeing on a width limit, whatever that width might be. Such a limit might already be controversial but it seems to make sense. The second is the question of what that width limit should be. There's a fun story about the with of our railway gauges and roads and Roman chariots that has the lovely quote that if you"...wonder what horse's ass came up with it, you may be exactly right." https://www.snopes.com/fact-check/railroad-gauge-chariots/ https://www.snopes.com/fact-check/railroad-gauge-chariots/ When it comes to an 80(ish) character limit, that does indeed come from old monitors, which took it from older line printers before them. https://en.wikipedia.org/wiki/ADM-3A https://en.wikipedia.org/wiki/ADM-3A But it all goes back to Hollerith cards, which were invented in the late 19th century and used in a US census at around that time. https://en.wikipedia.org/wiki/Punched_card https://en.wikipedia.org/wiki/Punched_card