From: Eric Sosman on
On 3/1/2010 4:32 PM, Julienne Walker wrote:
> On Mar 1, 4:15 pm, ralt...(a) (Richard Bos) wrote:
>> Julienne Walker<happyfro...(a)> wrote:
>>> On Feb 24, 2:21=A0pm, Fred<fred.l.kleinschm...(a)> wrote:
>>>> On Feb 24, 11:10=A0am, Julienne Walker<happyfro...(a)> wrote:
>>>>> On Feb 24, 1:35=A0pm, Poster Matt<postermatt(a)> wrote=
>>>>>> 4. Does anyone care where the pointer * is? I prefer keeping to next =
>>>>>> to the type, rather than next to the variable name.
>>>>>> EG. I like: char* firstName; and not so much: char *firstName;
>>>>> Just make sure you're consistent and nobody will care. :-)
>>>> Except that it is very error-prone to do so.
>>> It's only error prone if you have multiple variables in a declaration
>>> statement (which the OP's example did not). That itself is often
>>> viewed as an unsafe practice.
>> Incorrectly. I would much rather see
> I'm sorry you disagree. Perhaps if you made it clear to everyone in
> the world what you'd rather see, they'll change their beliefs to suit
> your style. ;-)

I'm with Richard on this one. When you have a bunch of
"obviously related" variables of the same type, there's little to
be gained and something to be lost by strewing the declarations
over multiple lines.

double rx, ry, rz; /* position */
double vx, vy, vz; /* velocity */
double ax, ay, az; /* acceleration */

.... is, to my eye, a lot more readable than

/* position */
double rx;
double ry;
double rz;
/* velocity */
double vx;
double vy;
double vz;
/* acceleration */
double ax;
double ay;
double az;

Even when there are only two variables

int compare(const void *pp, const void *qq) {
const struct jimjam *p = pp, *q = qq;

.... seems preferable to the one-per-line alternative: It moves
briskly past the boiler-plate preliminaries and helps the
attention proceed to the business at hand.

On the other hand, I'd agree that

int count, statusflag, i, modelnumber, j, k, errno_save;

.... is objectionable.

Eric Sosman
From: Ike Naar on
In article <vsTin.1958$qi1.782(a)>,
Scott Lurndal <slp53(a)> wrote:
>Personally, I dislike like if expressions that evaluate with side
>effects, I would
>declare temps and move the scanfs outside the if statement. It improves the
>readability too.

But that was not the point; the point was to make the if condition too
large to fit on a single line. The expressions were chosen more or less
at random just to illustrate that point.
From: Nick Keighley on
On 1 Mar, 21:50, Ian Collins <ian-n...(a)> wrote:
> Julienne Walker wrote:

> > I'm sorry you disagree. Perhaps if you made it clear to everyone in
> > the world what you'd rather see, they'll change their beliefs to suit
> > your style. ;-)
> Eh?  He did!

some people think there's a world outside clc!

From: Nick Keighley on
On 27 Feb, 17:50, Casper H.S. Dik <Casper....(a)Sun.COM> wrote:
> Nick Keighley <nick_keighley_nos...(a)> writes:
> >On 27 Feb, 13:56, Casper H.S. Dik <Casper....(a)Sun.COM> wrote:
> >> i...(a) (Ike Naar) writes:
> >> Things I absolutely hate in some c-styles are:
> >> if(condition)
> >> "if" is a not a *function* it shouldn't look like one.
> >I write it like this
> >   if (condition)
> >       some_func (x); /* <-- NOTE WELL */
> >and 'if' still doesn't look like a function to me
> It is fine with the space but not without (if() vs if ())

the point I was making was that I put the space in front of the
bracket BOTH for 'if' AND for a function invocation.
From: Nick Keighley on
On 27 Feb, 16:39, Rich Webb <bbew...(a)mapson.nozirev.ten> wrote:
> On Sat, 27 Feb 2010 08:30:16 -0800 (PST), Nick Keighley
> <nick_keighley_nos...(a)> wrote:
> >On 27 Feb, 08:39, James Harris <james.harri...(a)> wrote:

> >> Windows Notepad users are stuck with 8. Windows Wordpad users seem to
> >> be stuck with 6. These are not earlier than the 1980s.
> >> Come to think of it, apart from those two programs what do Windows
> >> users use to enter and edit source code?
> >the IDE, ConText, emacs, Word
> vi! Nowadays likely in its gvim incarnation, of course.

the editor of the beast

First  |  Prev  |  Next  |  Last
Pages: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Prev: integer
Next: shared memory question