Message: previous - next
Month: January 2015

Re: [trinity-devel] Codebase formatting discussion

From: Slávek Banko <slavek.banko@...>
Date: Thu, 1 Jan 2015 15:13:09 +0100
On Thursday 01 of January 2015 07:22:08 Michele Calgaro wrote:
> On 01/01/2015 04:27 AM, Timothy Pearson wrote:
> >> On 2014/12/31 02:13 PM, Timothy Pearson wrote:
> >>>>> Yes, we can wait a few days for your input. :-)
> >>>>>
> >>>>> The vast majority of this file was written in the style I prefer:
> >>>>>
> >>>>>dwaredevices.cpp?id=f27e71dcb162e37234ea98570379f60f8afdd8ea
> I noticed on quick glance that at least one alternate styles snuck in
> >>>>> over time, so the revision ID specified in that link is an older
> >>>>> version without many of the changes that introduced those alternate
> >>>>> styles.
> >>>>>
> >>>>> I find it very easy to read on mutiple screens, on the Web and in
> >>>>> Kate, from small laptops up to my main workstation. Comments are of
> >>>>> course welcome!
> >>>>
> >>>> If my vote still counts, I have only one request: please do not use 8
> >>>> spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
> >>>>
> >>>> Darrell
> >>>
> >>> I prefer hard tabs, this way each developer can set the space the way
> >>> they want to see it.
> >>>
> >>> Tim
> >>
> >> Tim, just wondering. What tool do you use to reformat existing code?
> >> Cheers Michele
> >
> > AStyle.  In fact I was working on this in late 2012:
> >
> >
> > Tim
> Hi Tim,
> well, first of all Happy New Year.
> I had a closed look at astyle and played around with it quite a while. I
> have attached an alternative option file, which generates code closer to my
> favorite style. These are just my preferences, it doesn't mean we need to
> use it exactly as it is. In particular the most important points are:
> 1) style: I prefer broken parenthesis instead of attached ones
> 2) hard tabs: ok with that. But use the force-tab option
> 3) no indent-cases blocks, too much indentations.
> 4) indent preprocessor defines on multiple lines
> 5) the "--break-blocks" is somehow optional. I have included it, but even
> without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer
> something like if (a == b)
>    rather than
>        if( a==b )
> 7) "--delete-empty-lines" ok if "--break-blocks" is used
> Everything else is quite minor.
> I have also attached the outputs created using the script currently in GIT
> and mine. Don't bother about the code itself, it was just made up for
> testing.
> Cheers
>   Michele

Only just for show I attach a style that I used in my projects.

As you can see, I'm used to small indentation => code did not run to the right 
side so quickly. I do not have infinitely wide screen :)

Unusually looking definition of function parameters is based from the days 
when it was not used automatic generation of documentation => description of 
the parameters was not in a separate documenting comment, but the definition 
is self-commenting. Simple symbols used in comments <=> mark parameters 
simultaneously input and output, <= mark output parameters and => mark input 
parameters. At the same time, I have kept the habit of the parameters order: 
at first 'i/o' parameters, then 'o' parameters and the last 'i' parameters.

One thing that might be useful for our common rules for TDE is - strictly 
habit always use braces - even in cases where the block is a single line.

As I said in the beginning - I attach it only as a demonstration of my habits. 
I am also flexible and ready to use the style that we will confirm as default 
TDE style.