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 fun
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
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
Tom Browder wrote:
On Thu, Aug 13, 2009 at 15:56, Tim Abell 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 is in the eye of t
On Thu, Aug 13, 2009 at 15:56, Tim Abell 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
___
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 should
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
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
http://lists.gnucash.org/pipermail/gnucash-devel/2
> Charles Day 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 reduce lin
On Mon, Jun 8, 2009 at 8:14 AM, Christian Stimming wrote:
> Zitat von Derek Atkins :
>
>> Charles Day writes:
>>
>>> I strongly prefer -bl to -br.
>>>
>>
>> Me too. I prefer:
>>
>> if ()
>> {
>>
>> }
>> else
>> {
>>...
>> }
>>
>
> Agreed by me. I already wrote the same thi
Zitat von Derek Atkins :
Charles Day 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 this is a somewhat majority
opini
Charles Day 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 reduce line break
2009/6/5 Christian Stimming
> 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
13 matches
Mail list logo
