Re: [Syllable-developer] Everyone on holiday?

[Daniel G. <da...@fp...>]

On Thu, 2003-07-24 at 09:03, William Rose wrote:
> On Thu, 2003-07-24 at 11:10, Daniel Gryniewicz wrote:
> > Well, you would but why?  Personally, I've been removing things like
> > that, and replacing them with strict indenting.  I personally hate
> > things like that. :)
> 
> <bait>
> I thought you might ;-)  Come on, it helps with reading.  What do you do
> with splitting long lines?  What's this strict indenting you allude to
> so casually...
> </bait>

Yes, well I'm not religious, so I have to be a bigot about something,
and coding style appears to be it. :)

I split lines at the edge of my standard xterm, which is 90 characters. 
You're, of course, free to split wherever you want.  I beleive the
current version of sindent effectively doesn't split lines (ie it splits
at 1000 chars), so that you can split wherever you want and then run
sindent on it and get the correct results.

Strict indenting, as I was using it above, means that indenting rules
apply equally to everything.  Ie, if your indent is one tab, then all
indenting should be one tab, and never a tab-and-a-half, or lining up
with something else, or whatever else.  I'm a big fan of consistancy
when it comes to coding style.  This is why I fought for a consistant
curly-bracket format, rather than the "sometimes on the same line
sometimes after" thing.  But, of course, YMMV.  Obviously, those who
produce the most code should have the biggest say in the coding style.

> 
> The variable names lining up is not really necessary.  It's just
> pretty.  Helps quickly distinguish things when the type isn't
> highlighted (because it's not a builtin).

Hmm.  I've personally never had that problem.  The type is first, the
variables are next, seems clear to me.  I actually make use of the
highlighting vs. not to distinguish "builtin/library" types from "my"
types.

> <digression>
> Incidentally, what's your feeling on a return after the return type in a
> function definition, e.g:
> 
> int
> foo( int bar )
> {
>   return ++bar;
> }
> 
> I got used to this a while ago because it helps to locate the function
> name in the file (/^func-name goes straight there).  You are probably an
> advocate of the ctags solution though.  (Or am I assuming too much?)
> </digression>

I personally don't like that, but we use it at work (part of BSD KNF),
so I'm used to it.  You're half right, I'm an advocate of cscope, which
is like ctags on steroids. :)  It's just as easty to type ":ta
func-name", and it will be caught in any file it's in, not just the
current one.

<flamebait>
Incidentally, you've tickled one of my pet peeves above.  It's always
been my opinion that, if the return has side effects, it should be
enclosed in parens.  Don't ask me where I got this, as I don't feel
strongly about parens-in-returns one way or the other normally, and
you'll find my code both ways, but if there's side effects, I always put
parens in.
</flamebait>

Don't you love style discussions? :)

Daniel
-- 
Daniel Gryniewicz <da...@fp...>