An 80 (non-whitespace) character limit is sensible because it improves source code readability.
A regular argument for a higher limit is that it is more modern. Our displays are bigger and the limit comes from punch cards where it made physical sense. But does that history make the limit bad? And does the available screen real estate change anything?
We read code more than we write it. For prose typography recommends line lengths of 40 to 80 (sometimes 100) characters. And that has not changed with modern display sizes since our eyes and brains have not changed. One can argue that code is not prose, but both want to be understood by humans. One major difference is that code uses a lot of whitespace for indentation. A (sensible) nesting level of 5 and a default tab width of 4 adds ~20 whitespace characters. This results in 60 to 100 (sometimes 120) characters. Ideally our tools would allow for that distinction. Sadly, they don’t. Nonetheless: 80 characters are in the sensible range.
Is our screen real estate thus wasted? No. Modern displays make it possible to read code side-by-side. For example to review diffs (e.g. git or pull requests) or to open two files together (e.g. implementation and test). With the standard font size of 12 pt two tabs in Visual Studio Code can show 156 characters. A more legible 16 pt reduces that to 118 characters. Another reason to keep the character limit sensible. Otherwise one has to start scrolling left and right to read everything. This makes it harder to understand because one can never see everything. Ideally all tools would be responsive and wrap lines at the edge of the viewport dynamically (like e.g. Xcode). Sadly, they don’t.
In summary: a limit of 80 non-whitespace characters makes sense. To account for indentation I recommend a limit between 80 and 120. Everything else makes your code harder to read and understand.
Please be aware that this is an easy topic to discuss ad nauseam. Often everybody has a (strong) opinion about it. If you ever discuss this longer than 15 minutes, you are likely bike-shedding. Choose a value - even a random one - and stick with it. That consistency will help readability more than the difference between 90 and 110.
Examples to illustrate the point:
RUN \
--mount=type=cache,target=/var/cache/apk,sharing=locked \
apk add \
git \
make
# vs.
RUN --mount=type=cache,target=/var/cache/apk,sharing=locked apk add git make
_logger.LogInformation("Client timestamp for {}: {}",
connectionId,
webSocketRequest.ClientTimestamp);
# vs.
_logger.LogInformation("Client timestamp for {}: {}", connectionId, webSocketRequest.ClientTimestamp);
I really enjoyed this talk, the pacing was great, the examples were highly understandable and I really like his explanations of all the trade-offs you meet every day.
PS And what I love most is that his new book is not dogmatic in the title. It does not tell you what to do, it asks you: Tidy First?
PPS The question mark is so powerful in every day problem solving. It does not think for you; it guides your thinking to hopefully better results. It’s sadly very effortful (since it requires turning on the slow part of your brain) and I have not found a great way to convince teams of their effectiveness yet.
If you ever have to work with a (virtual) machine that has restricted internet access, you can use this little trick to use your local host as a SOCKS proxy during your SSH session. This requires the server to allow TCP forwarding.
I believe I found this this talk in the comment section of a Hacker News post. I first watched the 2014 version of it. Since then I found out that Christophe Pettus gives this talk yearly.
It’s a long talk, but he talks about almost everything there is to know about Postgres. For advanced stuff he gives just enough starting points for figuring it out yourself.
Watch out! The slides links in the video description don’t work. But you can find them on thebuild.com.
RebelLabs by ZeroTurnaround (the company behind JRebel) does a yearly developer survey. And it is always accompanied by great write-ups. This time they wrote three blog posts:
I like these kind of reports since they give you a birds-eye view of the “vocal” community. “Vocal” community in the sense of people that fill out surveys. So always take these reports with a grain of salt. Use the trends as a guideline on what you should checkout rather than what you have to adopt.
I found this talk in a comment by larsiusprime in the comment section of a Hacker News post. Lis Pardi did a survey on whether people of certain age groups can identify icons that reference old objects such as the floppy disk. I found the data pretty interesting (majority can identify successfully) and her arguments that try to explain it are sound (context gives meaning).