Hi!
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.
The 80 char limit is IMO outdated
Roland Mainz <[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
>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.
>The 80 char limit is IMO o
>Roland Mainz <[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 l
[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
Roland Mainz <[EMAIL PROTECTED]> wrote:
> > (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 mak
On Sat, Apr 01, 2006 at 05:44:14PM +0200, Roland Mainz wrote:
> > I think you'll find that the C-style rules are not open for negotiation.
>
> What do other Sun engineers think about this ?
The same.
> Yes, I agree that using "cstyle" is a good idea and even that enforcing
> cstyle's rules is a
Keith M Wesolowski writes:
> On Sat, Apr 01, 2006 at 05:44:14PM +0200, Roland Mainz wrote:
>
> > > I think you'll find that the C-style rules are not open for negotiation.
> >
> > What do other Sun engineers think about this ?
>
> The same.
I hate to do a "me too" posting but, well, "me too."
James Carlson wrote:
>Keith M Wesolowski writes:
>
>
>>On Sat, Apr 01, 2006 at 05:44:14PM +0200, Roland Mainz wrote:
>>
>>
>>
I think you'll find that the C-style rules are not open for negotiation.
>>>What do other Sun engineers think about this ?
>>>
>>>
>>The s
On Sat 04/01/06 at 17:44 PM, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> >
> > 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
>You are wrong.
>1. Many of those tools support horizontal scrolling and continuation.
But many of the tools do not.
And horizontal scrolling does not help. It means that you can no
longer page through the code; you have to page in two directions.
>2. I did not say to reformat all existing cod
>I am definitely not willing to be forced to reduce to 80 columns for all cases.
>BTW: 80 is elso wrong. If you like to be 100% correct, then you would need to
>follow RFC-2822 and use 78 chars.
This is source code, not email.
I agree the limit is arbitrary; but any limit is; as far as arbit
[EMAIL PROTECTED] wrote:
> >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
>
> No, but I expec
[EMAIL PROTECTED] wrote:
>
> >I am definitely not willing to be forced to reduce to 80 columns for all
> >cases.
> >BTW: 80 is elso wrong. If you like to be 100% correct, then you would need to
> >follow RFC-2822 and use 78 chars.
>
> This is source code, not email.
>
> I agree the limit is a
Joerg Schilling wrote:
>
>
>BTW: I do not believe that code with > 79 characters is more readable
>but in a few exceptions, it is.
>
>What would happen if someone did write this:
>
> if (dp == ¬able) {
> /* BEGIN CSTYLED */
> printf("Manufacturer is unknown becau
The 80 rule is not going anywhere and the energy would be better spent
learning to live with it. It always takes effort to adjust to the new
environment, every one of us have gone through this and it didn't make
us or our code worse - other things did. The impact line width has on
the success
>If you argue with terminals, you need to reduce the width to 79 as many
>terminals cannot correctly display 80 columns.
80 is fine for the majority of software terminals.
>What would happen if someone did write this:
>
> if (dp == ¬able) {
> /* BEGIN CSTYLED */
>
[EMAIL PROTECTED] wrote:
> Then CSTYLE would not barf but your code reviewers might.
>
> In some cases, we have code which is formatted like this:
>
> if (dp == ¬able) {
> printf("Manufacturer is unknown because of the orange forum embargo.\n");
> printf("As the orange forum likes to get mo
>Looks more ugly then the long lines
>
>> But there's no particular reason, I think, why this can't be formatted like:
>>
>> if (dp == ¬able) {
>> (void) printf("Manufacturer is unknown because of the orange "
>> "forum embargo.\n"
>> "As the ora
[EMAIL PROTECTED] wrote:
But there's no particular reason, I think, why this can't be formatted like:
if (dp == ¬able) {
(void) printf("Manufacturer is unknown because of the orange "
"forum embargo.\n"
"As the orange forum likes to
On Sun, 2 Apr 2006, Joerg Schilling wrote:
if (dp == ¬able) {
/* BEGIN CSTYLED */
printf("Manufacturer is unknown because of the orange forum
embargo.\n");
printf("As the orange forum likes to get money for recent
information,\n");
>C99 mandates concatenation of adjacent string literals into one, GCC
Not just C99. ANSI C does too.
Casper
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
On Sun, 2006-04-02 at 06:03, Joerg Schilling wrote:
> There is a reason: This cannot be compiled anymore on HP-UX using the bundled
> compiler.
externally-maintained code which is merely imported as-is with minimal
changes into ON does not have to comply with cstyle, as this would get
in the way
On Tue, Apr 04, 2006 at 10:08:22PM +0100, Paul Jakma wrote:
> On Sun, 2 Apr 2006, Joerg Schilling wrote:
>
> > if (dp == ¬able) {
> > /* BEGIN CSTYLED */
> > printf("Manufacturer is unknown because of the orange forum
> > embargo.\n");
> > print
On Thu, 6 Apr 2006, Jonathan Adams wrote:
> You could also do:
> if (dp == ¬able) {
> printf(
> "Manufacturer is unknown because of the orange forum embargo.\n"
> "As the orange forum likes to get money for recent information,\n"
> "it may be that this media does not use illega
Rich Teer wrote:
On Thu, 6 Apr 2006, Jonathan Adams wrote:
You could also do:
if (dp == ¬able) {
printf(
"Manufacturer is unknown because of the orange forum embargo.\n"
"As the orange forum likes to get money for recent information,\n"
"it may be that this media does n
Alan Coopersmith writes:
> Hardcoding long strings in your source code is just a bad idea anyway,
> and makes it harder to internationalize.
Hardcoding shouldn't be an issue; that's just what gettext is for.
> Hide the strings off in a
> non-source file and be done with it.
I certainly wouldn'
James Carlson wrote:
(Spoken with the freedom of someone who has never had to run cstyle.)
:-/
Remember the ON exception for "follow the style of upstream when working
on source from outside Sun"? That pretty much covers 100% of the Solaris
code I've touched (X & CDE).
Reformatting to ON's
Alan Coopersmith writes:
> James Carlson wrote:
> >>(Spoken with the freedom of someone who has never had to run cstyle.)
> >
> > :-/
>
> Remember the ON exception for "follow the style of upstream when working
> on source from outside Sun"? That pretty much covers 100% of the Solaris
> code I'
29 matches
Mail list logo