Christian Stimming wrote:
Am Donnerstag, 13. August 2009 22:56 schrieb Tim Abell:
Late to the party, but currently I prefer tab indents to spaces as it
allows each developer to decide for themselves how big the indent is.
I'm afraid I don't agree to this one. Things like multi-line
And eventually I learnt one more weirdness about the indent program:
Am Montag, 13. Juli 2009 21:18 schrieb Christian Stimming:
Also, I discovered more issues with indent-2.2.9: This version seems to
insert a space after each asterisk `*' in pointer arguments, like so:
-gnc_hbci_gettrans
Am Donnerstag, 13. August 2009 22:56 schrieb Tim Abell:
Late to the party, but currently I prefer tab indents to spaces as it
allows each developer to decide for themselves how big the indent is.
I'm afraid I don't agree to this one. Things like multi-line function
declarations (or multi-line
On Thu, Aug 13, 2009 at 15:56, Tim Abellt...@timwise.co.uk wrote:
Late to the party, but currently I prefer tab indents to spaces as it allows
each developer to decide for themselves how big the indent is.
...
-ce Cuddle else and preceeding `}´.
Ugly!
-Tom
Tom Browder wrote:
On Thu, Aug 13, 2009 at 15:56, Tim Abellt...@timwise.co.uk wrote:
Late to the party, but currently I prefer tab indents to spaces as it allows
each developer to decide for themselves how big the indent is.
...
-ce Cuddle else and preceeding `}´.
Ugly!
-Tom
Ugliness
Late to the party, but currently I prefer tab indents to spaces as it
allows each developer to decide for themselves how big the indent is.
Tim
Christian Stimming wrote:
Now that we've come back to working on one single branch (trunk), we should
reconsider the idea from back in 2007: We
After a short discussion on this topic in June, it seems to me everyone is
more or less satisfied with the style proposed below. If this is the case, I
would volunteer to actually transform the code according to this style.
Regards,
Christian
Am Montag, 13. Juli 2009 20:53 schrieb Christian Stimming:
After a short discussion on this topic in June, it seems to me everyone is
more or less satisfied with the style proposed below.
Actually, now that I've tried this on real code, I see some unexpected issues.
Namely:
-ppi4 Nested
Charles Day ceda...@gmail.com writes:
I strongly prefer -bl to -br. Easier to visually match parens makes it
easier to read, harder to make mistakes. It adds lines, but is worth it in
my opinion. I like the rest, though personally I prefer two spaces for
indents rather than four. It helps
Charles Day ceda...@gmail.com writes:
I strongly prefer -bl to -br. Easier to visually match parens makes it
easier to read, harder to make mistakes. It adds lines, but is worth it in
my opinion. I like the rest, though personally I prefer two spaces for
indents rather than four. It helps
Zitat von Derek Atkins warl...@mit.edu:
Charles Day ceda...@gmail.com writes:
I strongly prefer -bl to -br.
Me too. I prefer:
if ()
{
}
else
{
...
}
Agreed by me. I already wrote the same thing in 2007 [1]: I prefer -bl
-bli0 over the proposed options. If
On Mon, Jun 8, 2009 at 8:14 AM, Christian Stimming stimm...@tuhh.de wrote:
Zitat von Derek Atkins warl...@mit.edu:
Charles Day ceda...@gmail.com writes:
I strongly prefer -bl to -br.
Me too. I prefer:
if ()
{
}
else
{
...
}
Agreed by me. I already wrote
Now that we've come back to working on one single branch (trunk), we should
reconsider the idea from back in 2007: We should re-indent the whole code
into one single indentation scheme. See
http://lists.gnucash.org/pipermail/gnucash-devel/2007-March/020099.html
Quote from there: I'd like to
2009/6/5 Christian Stimming stimm...@tuhh.de
Now that we've come back to working on one single branch (trunk), we should
reconsider the idea from back in 2007: We should re-indent the whole code
into one single indentation scheme. See
14 matches
Mail list logo
