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