It depends; you have to use a good judgement - in general the further away from this 80-120 range the code is, the more doubtful the decision looks. I personall

It depends; you have to use a good judgement - in general the further away from this 80-120 range the code is, the more doubtful the decision looks. I personally prefer 80, but occasionally have to allow for longer lines. Initially 80 was a technical limitation - you could do more, but had to make much more efforts than seemed reasonable. Then GUI allowed for more - but there was some inertia of the habit. Gradually some started experimenting with longer lines, finding cases where that's more convenient. Then code guides started mentioning line length... On one hand, a shorter line is easier to follow with eyes - when you need to go from right side of a line to the left side of the next line, that next line is easier to find if the line itself is shorter. However the code is usually much easier to read in this aspect than prose - line lengths are varying naturally. Yet if you're trying to always keep descriptive names of variables and methods, you're not only adding some verbosity, but also more often have to split lines - and that adds to making code more "blockish". It seems there are natural limitations - but that still depends on the particular style of the code. Have variable names just right - and you won't need too much lines in a block, so long lines could be ok. Different languages, different conventions for external libraries... It seem to be hard to put a specific number that would be both a good match with existing libraries, work (look) well for all kinds of tasks and across different languages. Sometimes one doesn't even want to sacrifice inner structure of the line - e.g., when several similar lines have important differences which one wants to highlight some spaces are often added, leading to longer lines. Or sometimes line-by-line comments are really useful (say, Minix source code) - which definitely add to line lengths.