On Tue, Oct 17, 2006 at 02:33:55PM -0600, Kevin Tew wrote:
> While exploring Parrot internals I started cleaning up some code.
> I'll post patches to the list, but here are some things that are not
> defined by the coding standards, but of which I'm a fan.
> So the question is are they acceptable in the parrot code base.
Thanks for making these explicit proposals. Answers below.
> 1) *s should go right next to the type in function declarations and
> definitions
No, in fact the opposite will be added to the coding standards as a rule.
Sadly the "*" next to the type is a common error propagated recently by
Bjarne Stroustrup (he makes the same mistake with "&"). The grammars of C
and C++ are what make this a misleading mistake. Consider:
char* p, q; /* bad */
Are p and q of the same type? No. Is q a char*? No. In contrast,
consider this:
char *p, q; /* not misleading, at least */
Here we see clearly expressed that both *p and q are of type char.
> 2) All structs should be typedefed
I'm hoping eventually to make Parrot compilable with C++, if only to support
making the Interpreter a COM object. This alters my usual ideal for
structure declarations. So the structure rules are:
a. All structures must have tags ("struct foo").
b. All structures should have typedefs.
c. The typedef and the tag should be the same.
(Structures inside functions can break all these rules.)
Here's my ideal structure definition:
typedef struct Foo {
...
} Foo;
Or, if forward declaration is important, the typedef and the struct can be
separated, e.g.:
typedef struct foo foo;
...
struct foo {
...
};
> 3) Single line if and elses are acceptable
No, sorry. I do that in my own Perl code, but in C it's too cutesie.
> 4) c89 allows declaration and initialization on the same line right?
> INTVAL counter = 0;
That's entirely legal & OK. But beware, it can be overdone. If you're not
careful, can end up doing a lot of work in your initializations, work that
may be entirely pointless if the given function takes an early return for
some reason.
--
Chip Salzenberg <[EMAIL PROTECTED]>
