Josh Hurst wrote: > On 7/4/07, Peter Memishian <[EMAIL PROTECTED]> wrote: > > * 113-143: Please reformat to be 80-column friendly. > > Why? It may be appropriate for the 60' of the last century but today > is 2007! /. had recently an article about this problem: > http://ask.slashdot.org/askslashdot/07/07/07/1931246.shtml > "Dating back to the venerable DEC VT100, the 80 column terminal has > served us well for over 25 years. Even now, many open source projects > and common conventions require lines of code and documentation to fit > on that terminal. I am not alone, judging by code I've seen in and out > of the open source world, in finding that number insufficient for > coding, much less more verbose writing. Given that modern graphical > displays (and all popular editors) are capable of far more, is it time > we came up with a new standard-sized terminal? If so, what should the > new standard be?" > > After lots of discussion it looks that a 132-column limit may be > better for humans and quality of the code
Erm, we had that discussion a while ago. See http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/014944.html for the discussion. And I have to agree with the "cstyle" rules (including the 80 column limit ([1])) because it is much much better to have coding style rules when several thousand people work on the same codebase... otherwise everyone would use his/her preferred style and even try to (intentionally or unintentionally) reformat other people's code which quickly becomes messy (see Mozilla.org, Gnome or Xorg for projects which really suffer from the lack of codeing style rules). [1]=Well, question is whether the 80 column limit can be applied to other languages, too. For example it's getting "tight" in C++ code (imagine nested classes/methods and/or |try { ... } catch { ...}|-blocks etc.) and POSIX shell scripts AFAIK don't support line continuation for string literals (in ksh93 you can use the '+='-operator to append string literals to string variables, however this can only be used as a workaround (for example it won't help you for localiseable string literals (e.g. $"foo") or ANSI/C-like string literals (e.g. $'foo')), making it sometimes tricky to handle this problem (but that issue is (again) offtopic and an issue for the shellstyle thing I am currently working on...). Another issue are large tables and similar data where I am not sure whether it's always a good idea to force the code within an 80 column limit (but such cases are rare _exceptions_ and not the standard). ---- Bye, Roland P.S.: Setting Reply-To: to [email protected] since this issue is very offtopic for the ksh93-integration code review (and "yes", I am going to follow the cstyle/Makefile-style rules...). -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
