This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 133909 - C/C++ reformatting settings and action issues
Summary: C/C++ reformatting settings and action issues
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Editor (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: Alexander Simon
URL:
Keywords:
Depends on: 130923 135699
Blocks: 154590
  Show dependency tree
 
Reported: 2008-04-25 09:30 UTC by mfwiniberg
Modified: 2010-02-26 08:31 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mfwiniberg 2008-04-25 09:30:28 UTC
Firstly, various quirks in the C/C++ Formatting Style settings tab:

Selecting a setting often shows the wrong sample code, for example:

Change the selection for braces placement/switch, and the sample code without a switch statement is displayed. You have
to change a setting for, say, Absolute Label Placement, to see the effect of the switch setting changes.

Creating a duplicate setting allows you to create more than one with the same name. Also the new setting doesn't remain
selected when changing options unless you save it by closing the options dialog and then reopen it and reselect your new
definition - this seems to be intermittent and is hard to reproduce consistently.

Now issues with the reformatter itself:

If you ask for spaces within parentheses for if statements eg:

if ( a==b )

reformatting code with a unary operator in the if statement omits the space after the opening '(':

if (!a) will reformat to if (!a )

Braces that are all on one line as part of an array initialiser for example, get realigned if you have braces set
to be placed on a new line, but not if there is an empty pair as part of a definition. I would expect the rule to be
that braces that are on one line are left alone:

int emptyfunction(void) {}

remains the same when reformatting, but

somestruct array[] = {
                     { 0, 1, 2 ,3 },
                     { 1, 1, 2, 3 },
                     };

usually reformats to

somestruct array[] = {
                     { 0, 1, 2 ,3
                     },
                     { 1, 1, 2, 3
                     },
                     };

but - depending on the complexity of the initialisers - sometimes not all braces get moved. I can provide some sample
code from a real app that demonstrates this if needed.

Comments: A useful option for the reformatter would be to either leave trailing comments at their current columns unless
they have to be pushed right, or to force them all to start on a specific column. Having them one space after the
trailing ';' can make them unreadable in complex code with many levels of indentation.

Apologies if this is the wrong topic, but seems to be the most relevant...

Mike
Comment 1 Jesse Grodnik 2008-05-09 18:45:34 UTC
Multiple defects. Escalated to P2.
Comment 2 Alexander Simon 2008-05-27 11:30:49 UTC
fixed "braces placement/switch" example
http://hg.netbeans.org/main/rev/3696e86699ff
Comment 3 Quality Engineering 2008-05-27 16:27:59 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #221 build
Changeset: http://hg.netbeans.org/main/rev/3696e86699ff
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixing: IZ#133909:C/C++ reformatting settings and action issues
- extend example
Comment 4 Alexander Simon 2008-06-05 20:50:27 UTC
Example:
if (!a) will reformat to if (!a )
was fixed in:
http://www.netbeans.org/issues/show_bug.cgi?id=135699
Comment 5 Alexey Vladykin 2008-07-28 14:04:51 UTC
Half of this bug is already fixed. Downgrading to P3.
What still needs to be fixed: duplicate formatting style name and braces formatting.
Comment 6 Alexey Vladykin 2008-07-29 10:53:55 UTC
Fixed another part of this issue: prevented creation of styles with duplicate names.
http://hg.netbeans.org/main/rev/84c6b82fcfc7

What still needs to be fixed: braces formatting.
mfwiniberg, could you please provide examples of code that are formatted incorrectly?
Comment 7 mfwiniberg 2008-07-29 12:45:10 UTC
Hi

Here is a single piece of code from one of my objects that indicates the inconsistency quite well. As the first
initialiser is large, I have elided all but the first and last two lines, the second one I have left alone (sorry about
the wrap)...

    field_data ff [] ={
        { nFRCODE,  &farecode,  0,  "FARECODE",     'C',    3,  0   }, // User defined fare code
        { nFRDESC,  &descr,     0,  "DESCR",        'C',   40,  0   }, // and matching description
        { nFRSTO,   &sto,       0,  "STO",          'D',    8,  0   }, // STO dates
        { 0, 0, 0, 0, 0, 0, 0}
    };

    tag_data ft [] ={
        { &fareroute,"FARROUTE", "ROUTE", 0, 0, 0 },
        { &faresec,  "FARESEC",  "ROUTE+DTOC(VFROM,1)+FARECODE", not_del, 0, 0 },
        { &farebest, "FAREBEST", "ROUTE+DTOC(VFROM,1)+STR(99999.99 - ADULT,8,2)", "ISPAX .AND. .NOT. (FCLASS='E' .OR.
FCLASS='S') .AND. .NOT. SPECIAL .AND. .NOT. WEBONLY", 0, 0},
        { &fareval,  "FAREVAL",  "ADULT", not_del, 0, r4descending },
        { &faredisc, "FAREDISC", "DTOC(VFROM,1)+ROUTE+FARECODE", "(FCLASS='E' .AND. SUBSTR(TAXACC,3,1)='D') .AND. .NOT.
DELETED()", 0, 0},
        { &farechgs, "FARECHGS", "DTOC(VFROM,1)+ROUTE+FARECODE", "(FCLASS='E' .AND. SUBSTR(TAXACC,3,1)<>'D') .AND. .NOT.
DELETED()", 0, 0},
        { &farextra, "FAREXTRA", "ROUTE+DTOC(VFROM,1)+FARECODE", "(FCLASS='E') .AND. .NOT. DELETED()", 0, 0},
        { 0, 0, 0, 0, 0, 0 }
    };

reformats to:

    field_data ff [] = {
        { nFRCODE, &farecode, 0, "FARECODE", 'C', 3, 0}, // User defined fare code
        { nFRDESC, &descr, 0, "DESCR", 'C', 40, 0}, // and matching description
        { nFRSTO, &sto, 0, "STO", 'D', 8, 0}, // STO dates
        { 0, 0, 0, 0, 0, 0, 0}
    };

    tag_data ft [] = {
        { &fareroute, "FARROUTE", "ROUTE", 0, 0, 0
        },
        { &faresec, "FARESEC", "ROUTE+DTOC(VFROM,1)+FARECODE", not_del, 0, 0
        },
        { &farebest, "FAREBEST", "ROUTE+DTOC(VFROM,1)+STR(99999.99 - ADULT,8,2)", "ISPAX .AND. .NOT. (FCLASS='E' .OR.
FCLASS='S') .AND. .NOT. SPECIAL .AND. .NOT. WEBONLY", 0, 0},
        { &fareval, "FAREVAL", "ADULT", not_del, 0, r4descending
        },
        { &faredisc, "FAREDISC", "DTOC(VFROM,1)+ROUTE+FARECODE", "(FCLASS='E' .AND. SUBSTR(TAXACC,3,1)='D') .AND. .NOT.
DELETED()", 0, 0},
        { &farechgs, "FARECHGS", "DTOC(VFROM,1)+ROUTE+FARECODE", "(FCLASS='E' .AND. SUBSTR(TAXACC,3,1)<>'D') .AND. .NOT.
DELETED()", 0, 0},
        { &farextra, "FAREXTRA", "ROUTE+DTOC(VFROM,1)+FARECODE", "(FCLASS='E') .AND. .NOT. DELETED()", 0, 0},
        { 0, 0, 0, 0, 0, 0
        }
    };

The wrap is making it harder to see what happens, but in the second initialiser, some lines have the brackets moved and
some don't - it's not immediately obvious why (to me anyway!)...

The first initialiser gets reformatted much as I would expect, although it would be really nice to be able to set where
the comments begin (the full source has 40 lines of varying length in that first initialiser and the comments become
very hard to read). It would be even nicer to be able to specify that the formatter position to, say, the next tab stop,
after each comma in such a list 8)

thanks

Mike
Comment 8 Alexey Vladykin 2008-11-13 13:09:56 UTC
Reassigning to our formatting guru for evaluation :)
Comment 9 Alexander Simon 2008-11-18 11:15:26 UTC
The rest part of issue rather is enchantment "adaptive formatting".
I.e. detect user formatting style on fly.