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:
> >>>>> https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehar
> >>>>>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:
> > https://git.trinitydesktop.org/cgit/scripts/tree/astyle
> >
> > 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.
--
Sl�vek
Attachments: