You can use arrow keys to navigate in the map.
If this is applied, there should be an additional code complexity analysis to prevent high complexity code that can be caused.
80 characters allows to see two files side-by-side on all kinds of screens.
Long line lengths allow deeper nesting of loops and branch statements. This might encourage more complicated code.
Having so few columns available prevents developers from utilizing vertical spacing properly, which can be used to make the code more readable.
Having to break at 80 columns adds lots of tedious, manual work to break lines properly, especially with string literals when you need to take spacing between words into account.
Inexperienced or unfocused developers will have way more opportunities to not break lines nicely (for instance by using hanging indents, or even worse, nested hanging indents), making code less readable than the alternative.
Lots of line breaks, especially in string literals, make it difficult to search code, for instance when looking for where an error message comes from.
When lines are broken down into smaller pieces just for the sake of having short lines (which applies especially for string literals), patches and diffs become very difficult to read.
Leading members of the Python community, including Raymond Hettinger and Kenneth Reitz, prefer allowing code to go over 80 columns. Keeping consistent with the rest of the Python community helps make cross-project contributions frictionless.
Having more line breaks makes visually comparing lines of code more difficult.
This is a rule that newcomers often fail on with their first contributions. Getting rid of this limitation would decrease the friction they encounter when trying to get into open source development, and would let them focus on more important issues.
this is mostly due to string literals that exceed the 80 column width.
Static analysis tools typically do not generally apply different line lengths based on line content, but eventually they will, and some already do for URLs.