There's been some discussion on IRC about using the indent program to
reformat the sources into something consistent from file to file. I'd
like to propose the following options as a starting point for
discussion. I think some of these options will be agreed upon by all,
and I'm s
On Thu, Mar 08, 2007 at 11:46:53PM -0500, David Hampton wrote:
> There's been some discussion on IRC about using the indent program to
> reformat the sources into something consistent from file to file. I'd
> like to propose the following options as a starting point for
>
I also recommend
-T ExampleType
for every 'typedef', so that you get:
example(int foo, char *bar, ExampleType *aligned_here)
and not
example(int foo, char *bar, ExampleType * aligned_here)
-- Peter
David Hampton wrote:
>
> There's been some discussion on IRC a
On Fri, 2007-03-09 at 01:17 -0500, Chris Shoemaker wrote:
> I would recommend adding -ss, and I would have defaulted to -cli0,
> which is also K&R, but I don't feel strongly about it.
+1 on -ss .
--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]
signatur
On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote:
> I also recommend
>
> -T ExampleType
>
> for every 'typedef', so that you get:
:( We have nearly a thousand typedefs in the code some are relatively
anonymous, but most aren't... I wonder if there's a way to say '-T *',
or something si
Am Freitag, 9. März 2007 05:46 schrieb David Hampton:
> There's been some discussion on IRC about using the indent program to
> reformat the sources into something consistent from file to file.
>
> Of the above list of options, the ones I feel strongly about are lining
> u
latively
> anonymous, but most aren't... I wonder if there's a way to say '-T *',
> or something similar?
There is no way to say '-T *', because indent cannot figure out which
identifiers are type names (if there were, then there would be no need
for '-T' opt
ething similar?
>
> There is no way to say '-T *', because indent cannot figure out which
> identifiers are type names (if there were, then there would be no need
> for '-T' options). Only identifiers of the form *_t are automatically
> recognized as types
That'
Am Samstag, 10. März 2007 19:28 schrieb Peter Selinger:
> > On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote:
> > > I also recommend
> > >
> > > -T ExampleType
> > >
> > > for every 'typedef', so that you get:
>
> Th
for every 'typedef', so that you get:
> >
> > There is no way to say '-T *', because indent cannot figure out which
> > identifiers are type names
> >
> > Actually, there are 1580 typedef's in the code. I guess it's best to
> > read t
becomes redundant. HACKING should be
updated to include the details.
Social mechanisms are probably the best enforcement. I don't think we
want to automate running indent on every commit or anything.
--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PRO
On Sat, 10 Mar 2007, Peter Selinger wrote:
> in lib/goffice-0.0.4/goffice/utils/go-regression.c. I don't think
This mass indenting should not touch any external libraries that are
included with gnucash.
goffice was removed I guess, but if there are any others don't indent
them
On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote:
> -l80 Line width of 80.
This one I find problematic. I understand the arguments for it, and
have made them myself. But identifiers and type names are just too long
these days. An 80-char limit can cause frequent and unnatural
line-breaki
On Fri, Mar 09, 2007 at 10:16:47AM -0500, Josh Sled wrote:
> On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote:
> > -l80Line width of 80.
>
> This one I find problematic. I understand the arguments for it, and
> have made them myself. But identifiers and type names are just too long
)?
-nlp will tell indent not to indent to the open parenthesis. I'm not
sure if there is an argument to to force a carriage return after an open
parenthesis. With -nlp, this may look like the above, or may look like
this:
foo_is_a_short_name = but_these_names_are_rather_too_long(argum
On Fri, 2007-03-09 at 15:46 -0500, Chris Shoemaker wrote:
> Let me speak up in favor of the 80-char limit. However, I'm okay with
> treating it as "strongly encouraged" rather than rigorously enforced.
I think after discussion in #gnucash that we've come to consensus that
the goal is an 80-column
16 matches
Mail list logo