From: Rainer Weikusat on
Keith Thompson <kst-u(a)mib.org> writes:
> Rainer Weikusat <rweikusat(a)mssgmbh.com> writes:
>> Poster Matt <postermatt(a)no_spam_for_me.org> writes:
> [...]
>>> 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;
>>
>> C knows about three kinds of derived types, arrays
>>
>> char a[];
>>
>> Pointers to functions
>>
>> char (*a)();
>>
>> and pointers
>>
>> char *a;
>
> Array types, structure types, union types, function types, and pointer
> types are all derived types (C99 6.2.5).

Exercise for the reader: Which of the six types defined above are
irrelevant for this statement about 'declaration of derived types'
because they belong to a different syntactical class than the three
examples? Which type is irrelevant because it cannot directly appear
in a variable declaration? Which other class of types should appear
instead because they can?

>> Don't special-case on of these three cases because of a lack of
>> understanding of the C type system.
>
> But it might be acceptable to special-case on some cases *with*
> an understanding of the C type system. I prefer "char *a;" myself,
> but there's a valid argument that "char* a;" makes it more obvious
> that's meant (that a is of type char*).

A type 'char*' doesn't exist. A type named 'char' does, and assuming
that T names an existing type, an object can be declared as 'pointer
to a T' by using the syntax

T *o;

'Pointerness' is an attribute of the object, not of the type. This is
also consistent with the original intention behind this syntax, namely
that 'declaration should resemble use'.

[...]

>> Lastly, please don't ask questions like this in public.
>
> Why not? Or are you just being rude?

They are bound to end up as quite useless quarrels between people
who desire to write "beautiful" code and people who desire to write
readable code.
From: Keith Thompson on
scott(a)slp53.sl.home (Scott Lurndal) writes:
> Poster Matt <postermatt(a)no_spam_for_me.org> writes:
[...]
>> 1. Having been programming in higher level languages for the last 15
>> years, I'm finding it hard to get used to DEFINES in all
>> capitals. Is it really frowned on not to do so? Is CamelCase
>> acceptable?
>>
>> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.

I agree that MAXNUMFILES is harder to read than MaxNumFiles. The
solution is to write it as MAX_NUM_FILES.

> Well, defines are macros, not constants, so I try to avoid them for this use.
> With C99 and C++, one should probably use static const
> <type> (where type a signed or unsigned integer of the appropriate width).
[...]

Even in C99, the name of a static const object cannot be used as a
constant expression. This:

static const int max = 42;
int arr[max];

is valid in C99, but only because arr is a VLA (though the compiler
might implement it exactly as if it were a non-VLA). But max can't be
used in other contexts that requires a constant expression, such as
case labels.

A common trick is to use enum:

enum { max = 42 };

This has the drawback that it can only be of type int.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Keith Thompson on
Keith Thompson <kst-u(a)mib.org> writes:
[...]
> His convention apparently is to use camelCase for variables and
> PascalCase for functions. It's not necessarily a style I'd use, but
> it's not obviously horrible (and it's more or less the style I use
> at work).

On re-reading, I realize that sounds a bit odd. What I meant is that
it's not necessarily a style I'd use *voluntarily*, but I have no
problem using it if it's necessary to conform to the existing style of
the code I'm working on.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: ImpalerCore on
On Feb 24, 5:04 pm, William Hughes <wpihug...(a)hotmail.com> wrote:
> On Feb 24, 4:53 pm, BruceS <bruce...(a)hotmail.com> wrote:
>
> > I would like to add that, as long as you're trying to use good style,
> > for God's sake don't use the wrong indentation style.  If you put your
> > opening braces on the same line as your conditional, you'll just look
> > like a fool in front of your friends and colleagues.
>
> You need to fix your misprint.  Clearly you meant
>
> If you *dont* put your  opening braces on
> the same line as your conditional, you'll
> just look like a fool in front of your
> friends and colleagues.
>
>                   - William Hughes

You both are wrong. It's best to mix the two styles, to get the best
of both worlds.

if ( conditional ) {
// line of code
} else {
// line of code
}

if ( conditional )
{
// multiple
// lines
// of
// code
}
else
{
// multiple
// lines
// of
// code
}

if ( conditional ) {
// line of code
}
else
{
// multiple
// lines
// of
// code
}

and yes this is actually my personal style :P
From: Keith Thompson on
Rainer Weikusat <rweikusat(a)mssgmbh.com> writes:
> Keith Thompson <kst-u(a)mib.org> writes:
>> Rainer Weikusat <rweikusat(a)mssgmbh.com> writes:
>>> Poster Matt <postermatt(a)no_spam_for_me.org> writes:
>> [...]
>>>> 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;
>>>
>>> C knows about three kinds of derived types, arrays
>>>
>>> char a[];
>>>
>>> Pointers to functions
>>>
>>> char (*a)();
>>>
>>> and pointers
>>>
>>> char *a;
>>
>> Array types, structure types, union types, function types, and pointer
>> types are all derived types (C99 6.2.5).
>
> Exercise for the reader: Which of the six types defined above are
> irrelevant for this statement about 'declaration of derived types'
> because they belong to a different syntactical class than the three
> examples? Which type is irrelevant because it cannot directly appear
> in a variable declaration? Which other class of types should appear
> instead because they can?

You said that "C knows about three kinds of derived types". In fact,
there are six. I was disputing the accuracy of your statement, not
its relevance.

>>> Don't special-case on of these three cases because of a lack of
>>> understanding of the C type system.
>>
>> But it might be acceptable to special-case on some cases *with*
>> an understanding of the C type system. I prefer "char *a;" myself,
>> but there's a valid argument that "char* a;" makes it more obvious
>> that's meant (that a is of type char*).
>
> A type 'char*' doesn't exist. A type named 'char' does, and assuming
> that T names an existing type, an object can be declared as 'pointer
> to a T' by using the syntax
>
> T *o;
>
> 'Pointerness' is an attribute of the object, not of the type. This is
> also consistent with the original intention behind this syntax, namely
> that 'declaration should resemble use'.

Wrong. char* is a type. Specifically, it's a derived type and a
pointer type. See C99 6.2.5, particularly paragraph 20.

If char* is not a type, can you explain what exactly you mean when you
use the word "type"? Your usage appears to be inconsistent with the
usage in the C standard.

You might have a valid point in there somewhere, but your misuse of
terminology makes it difficult to discuss it.

(And for the record, I agree that "T *o;" is preferable to
"T* o;"; I just don't agree that it's a huge deal.)

> [...]
>
>>> Lastly, please don't ask questions like this in public.
>>
>> Why not? Or are you just being rude?
>
> They are bound to end up as quite useless quarrels between people
> who desire to write "beautiful" code and people who desire to write
> readable code.

Perhaps, but we've also seen some useful discussion in this thread,
particularly the point about the importance of conforming to whatever
coding standard is used for an existing project.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Prev: integer
Next: shared memory question