[EMAIL PROTECTED] wrote: > > >While working on the "isaexec" patch I stumbled over the following > >issue: > >-- snip -- > >% cstyle -pP isaexec.c > >isaexec.c: 67: line > 80 characters > >-- snip -- > >I'd like to propose to relax this limit, making 132 characters the > >maximum line length in OS/Net. > > NO WAY.
Why ? I did not suggest to reformat all existing code - I am just begging for the option that people can choose to use a little bit wider width, maybe even optionally via setting a flag in the source code header explicitly. > >The 80 char limit is IMO outdated and it may be less annoying to use a > >slightly larger boundary here (the isaexec patch itself is no good > >example why the 80 char limit is bad, but there are other examples where > >the readability can be seriously damaged by the enforcement of the > >current length limitation). > > Sorry; my xterms are still 80 characters and for good reason. > > It allows me to have many more xterms open side-by-side so I can see much > more stuff at the same time. > > By relaxing the limit to 132 characters you are *forcing* everybody to > switch to 132 wide xterms. You are wrong. 1. Many of those tools support horizontal scrolling and continuation. 2. I did not say to reformat all existing code. I just asked for the option to allow wider character widths on demand when it is usefull. 3. I do not expect that everyone will use all 52 (= 132 - 80) additional characters to the full extend > (Or to face code which is much less readable > than code formatted to fit 80 columns; 132 wrapped to 80 is just not > a pretty sight. I agree. But if you look at the existing code it's usually only a few extra characters which are needed to make the code MUCH more readable. > And while you argue that "132 columns is more readable", the 80 column > viewer is exposed to code which is much less readable. > > I don't think "modern" comes into this in anyway; if your lines need > to be 132 columns wide you may be nesting code too deeply, may be using > identifiers which are too verbose. The problems I've seen to far are string literals. Another bunch of good examples could be found in mozilla.org's (see content/ and layout/ - an enforcement of the ON cstyle would have devastating effects for the maintability of the code) and KDE's codebase. > I think you'll find that the C-style rules are not open for negotiation. What do other Sun engineers think about this ? > While I don't agree with some of them (such as the () required for return > and the space after sizeof, in years I have learned to appreciate why > the rules are there: they give consistent code; this code is consistently > readable. Variations in style hamper the accessibility and maintainability; > the style was fixed in stone precisely because the maintainers vary over > time. Yes, I agree that using "cstyle" is a good idea and even that enforcing cstyle's rules is a good thing. I did not argue that. My primary complait is the fixed line length which is very ugly. We're not in the days of Fortran 77 anymore... or are we ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list [email protected]
