Yes, you suggested abandoning coding standards designed for monospaced fonts, specifically maximum line length. While most programmers use monospaced fonts, you are bound to clash with someone and make their lives harder by dropping some standards.
Don't read too much into that part of what I wrote; I said it poorly. I'm quite aware that most people use monospaced fonts, and my code has to be just as readable in a monospaced font as in a proportional font, or it's no good.
I don't like excessively long lines any more than anyone else does, and I do pay attention to the column numbers. I just don't worry about them much, partly because my coding style naturally tends to produce shorter line lengths.
Compare:
function niftyExampleFunction( niftyExampleParameter, // nifty comment
anotherNiftyExampleParameter ) { // another comment
doStuff();
}
vs.
function niftyExampleFunction(
niftyExampleParameter, // nifty comment
yetAnotherNiftyExampleParameter // another comment
) {
doStuff();
}
That's a line width of 84 vs. 56 for the same code. Fair enough?
Just another thought that I forgot about last night. You were asking about teams and maximum line length. As I think back, most of the teams I've been on in recent years just weren't very worried about that. We all kept to short lines as a matter of readability, but didn't have any particular hard limit if a particular piece of code happened to be more readable with longer lines.
Of course this was long after the days of 80-column Teletypes, and we were mostly using various GUI editors that didn't have a hard restriction on line length.
But back in the days when I coded on a Teletype, I definitely kept all the lines shorter than 80 columns! :-)
Yes, of course, many times. And on teams with a variety of coding standards, some loose and some more strict.
Did the coding style I suggested seem unsuitable for team use?