On Thursday 01 of January 2015 21:43:08 Timothy Pearson wrote:
> > 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/tde
> >> >>>>>har 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
>
> You are correct about always using braces; this I want to see strictly
> enforced.
>
> Unfortunately those detached indented braces make this extremely hard for
> me to read. This looks similar to the style used in kwin?
>
> In my experience even if the brace is "invisible" after an if the presence
> of a control statement plus indentation (and combined with the braces
> always used rule) are more than sufficient as replacement cues. In effect
> what I like about placing the brace at the end is that the control
> statement and brace form a single "statment"; i.e. my eye only has to jump
> one line to read the next chunk of control flow instead of having to jump
> two with the second containing a good bit of whitespace. That same
> whitespace causes my eye to sometimes miss the initial statement of the
> next code, forcing a retrack and often pushing something else out of
> working memory in the process--this is the main reason I tend to mess up
> the control flow in twin commits and have to go back to fix it.
>
> If I were to excercise the power of the BDFL on this project and override
> the braces to the way I want to see them would this be a major problem?
>
> Tim
>
Wow, indentation in twin is yet another - I would say, very confusing -
because the brackets are at the same level of indentation as the block, so is
lost completely. Awful.
I am aware that the more popular now are brackets at the end of lines. And I,
as well as Michele, earlier mentioned that we are flexibile and we have no
problem adapt to it. In fact, it was enough for the pleasure to me knowing
that along with Michele we have the same preference :)
But what would prefer a smaller indentation in the switch cases - as featured
Michele. Unfortunately I do not know whether astyle can be set to such a
manner. See attachment.
--
Sl�vek
Attachments: