[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Problems with code formatter and legacy code - whatis possible at all?
|
Hi,
I was on vacation. That's why my reply is a bit late.
> > 1) Preformatted member lists
This would be possible, but requires some work. The CDT formatter is
derived
from the JDT formatter which supports this kind of member alignment.
> > 2) public/private alignment
The problem here is that the formatter works with one indentation unit
only.
I.e. every indentation can only be a multiple of that unit.
So, supporting this style would be a challenge.
> > 3) return type on extra line
This is supported, but the option is not available in the UI.
To have this enabled, derive your style from the built-in GNU style.
> > 4) Preformatted parameter lists
This is supported. You need to set the parameter indentation to "Indent
on column"
and the wrapping policy to "Wrap all but the first" (or similar).
> > 5) Column aligned comments
Not supported, but doable.
> > 6) Simple if clauses
Same problem as with 2)
> > 7) Inconsistent blanks
Not possible at the moment.
Some general notes:
Instead of formatting a complete file you can also format a selection.
"Correct Indentation" (Ctrl+I) only changes leading whitespace.
You can contribute your own implementation of a formatter. There are
also plugins
which integrate external code beautifiers, like e.g. the Astyle
formatter.
HTH
Toni
As a general note, you can also use "Correct Indentation"
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Achim Bursian
> Sent: Thursday, April 09, 2009 9:34 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Problems with code formatter and
> legacy code - whatis possible at all?
>
> Nobody with some internal formatter knowledge? Please, just give me a
> hint like "yes, go for it" or "don't even bother, won't work". Thanks.
>
> Achim wrote on 2009-04-06 13:19:
> > Hello,
> > we want to move a large C++ code base from XEmacs to Eclipse/CDT as
> > main editor. These are hundreds of thounds LOC, all under
> source code
> > control of course. I tried to find some settings to mimic our old
> > XEmacs formatting style in CDT, but with no luck. There are
> some areas
> > where I'm absolutely lost.
> >
> > I'm very willing to add some code to CDT to enhance the
> formatter, but
> > before I dive into the depth of the formatter, I wanted to
> hear your
> > opinions whether it is actually possible what I want to do.
> >
> > The main reason for this issue is that we want as few merge
> conflicts
> > as possible after formatting with CDT. Our code is maintained in
> > several branches to support patches for old releases, and only the
> > main branch will be moved to Eclipse. So the formatting
> between XEmacs
> > and Eclipse/CDT has to be consistent. I see several areas
> of problems
> > at the moment.
> >
> > 1) Preformatted member lists
> > ============================
> > Existing code:
> > class T
> > {
> > ICIpoState* ipoStateP;
> > BSChannelId chanId;
> > BSAlarmhandler* alarmP;
> > ICAxConfig axConfig ;
> > };
> >
> > All members are aligned to the same column.
> > After formatting with CDT:
> > class T
> > {
> > ICIpoState* ipoStateP;
> > BSChannelId chanId;
> > BSAlarmhandler* alarmP;
> > ICAxConfig axConfig;
> > };
> >
> >
> > 2) public/private alignment
> > ============================
> > Existing code:
> > class T
> > {
> > private:
> > ICIpoState* ipoStateP;
> > public:
> > ICAxConfig axConfig ;
> > };
> >
> > The private/public/protected keywords are indented 2 chars,
> while all
> > other indentation is 4 chars.
> >
> > After formatting with CDT:
> > class T
> > {
> > private:
> > ICIpoState* ipoStateP;
> > public:
> > ICAxConfig axConfig;
> > };
> >
> > Also possible with CDT:
> > class T
> > {
> > private:
> > ICIpoState* ipoStateP;
> > public:
> > ICAxConfig axConfig;
> > };
> >
> > Changing the indentation size to 2 chars wouldn't help, as
> if's etc.
> > shall be indented with 4 chars.
> >
> > 3) return type on extra line
> > ============================
> > Existing code:
> >
> > void
> > CPTestCl::reset()
> > {
> > return;
> > }
> >
> > After formatting with CDT:
> >
> > void CPTestCl::reset()
> > {
> > return;
> > }
> >
> > If the return type is on a line by itself, I don't want it to be
> > combined with the method name. But if it already is like
> > void CPTestCl::reset()
> > it shouldn't be split onto two lines either. Basically,
> just leave it
> > as it is.
> >
> > 4) Preformatted parameter lists
> > ===============================
> > Existing code:
> > void
> > CPTestCl::load(int v1,
> > int v2,
> > int mode
> > )
> > {
> > ...
> >
> > All params are aligned to the same column.
> >
> > After formatting with CDT:
> >
> > void CPTestCl::load( int v1, int v2, int mode )
> > {
> > ...
> > 5) Column aligned comments
> > ==========================
> > Existing code:
> >
> > if (oldAddedVel) // comment 1
> > {
> > if (aGisMCS->isResetPos()) // comment 2
> > return;
> >
> > After formatting with CDT:
> >
> > if (oldAddedVel) // comment 1
> > {
> > if (aGisMCS->isResetPos()) // comment 2
> > return;
> >
> > 6) Simple if clauses
> > ==========================
> > See code in 5). After the if without braces, the next line
> ("return")
> > should be indented 2 chars only, not 4 chars.
> >
> > 7) Inconsistent blanks
> > ======================
> > Existing code:
> >
> > class T
> > {
> > ICIpoState* ipoStateP;
> > ICAxConfig axConfig ;
> > };
> >
> > After formatting with CDT:
> >
> > class T
> > {
> > ICIpoState* ipoStateP;
> > ICAxConfig axConfig;
> > };
> >
> > Mind the space after axConfig. I would like to keep that as it is,
> > even if it is inconsistent :-(
> >
> >
> >
> > Maybe there is more, but these are the most prominent problems.
> > If you could comment on any or all of these issues whether
> it might be
> > possible to change the formatter to do what I want?
> > If the formatter only sees the AST, then maybe it isn't possible at
> > all to retain the whitespace as it is?
> >
> > BTW: Please, don't give me advice about good style, this is
> a bunch of
> > legacy code, it is as it is. And we want to keep it that way, to
> > reduce maintenance in our code repository to a minimum.
> > But not being ale to use the formatter of CDT would render
> Eclipse/CDT
> > less powerful than XEmacs, which would be a shame.
> >
> > Thanks in advance,
> > Achim
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
