I don't get it. 80 columns was always short but it forced you to think about your code when it got too long. Contextually local variable names which go far abo

I don't get it. 80 columns was always short but it forced you to think about your code when it got too long. Contextually local variable names which go far above 10 characters and contextually local function names which go far above 20 characters are almost always misnamed. Nobody should struggle to fit at least within about 100 characters when they're focusing their code on clarity and simplicity. Obviously this doesn't mean that you should rename your buf_size variable to bsz or s. But you buf_size variable in a function called read_line shouldn't need to be called line_buffer_size and if there's only one buffer should potentially just be called size. Then there's people in this post claiming that research relating to readability of text don't apply to code because people don't read whole lines. I only have to wonder if these people have ever read code they didn't write on that same day or from a codebase they're already very familiar with. I read a lot of code, it's part of my job, I need to read the whole lines so I can verify that there's nothing horribly wrong. It makes it incredibly difficult to read expressions when they can't fit within my visual field. Yes, hard-wrapping code is not great, it should be avoided and only done with a good bit of experience, insight and awareness of how it's going to affect the code. Regularly making your code 150 lines long because your variables are repeatedly telling me information I could have just gathered from looking two lines up and because your function names are descriptions of the behaviour of the code they contain isn't a great look either. Although I still think that my least readable experience was having to read and work with code which used a 2 space indent (and an editor which wouldn't let me fix this in any way) which regularly went 10 levels deep and 100s of lines long.