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 33334 - Auto-generated code/documentation disregard editor settings
Summary: Auto-generated code/documentation disregard editor settings
Status: NEW
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker with 2 votes (vote)
Assignee: issues@guibuilder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-01 11:02 UTC by s690716
Modified: 2006-10-25 17:03 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 s690716 2003-05-01 11:02:18 UTC
The auto-generated code from formeditor and auto-comment 
disregard the settings from options/editor-settings.

An example is the text limit count (i.e 80 chars).
the generated code often is longer than this limit count.

printing with more than 80 chars per line is difficult...

another nice feature would be the placement of the 
attribute definitions of form editor. many programmers 
(like me) place attribute definitions on top in the source
(uml-like)
Comment 1 Tomas Pavek 2003-05-02 16:08:37 UTC
The text limit count is used only to display a vertical delimiter
line, AFAIK. Only thing I know about is that form editor does not
reflect indentation engine set in editor (or just several properties
only). We should probably implement some additional formatter that
would adjust generated code (e.g. wrap lines, replace FQN with
imported short names - see issue 7781) to reflect all relevant settings.

As for placement of the generated variables definitions, you mean it
should be configurable?
Comment 2 s690716 2003-05-04 22:03:31 UTC
Yes, I meant the configurability. But this would be an 
(nice) enhancement.

First of all, the "Java Indentation Engine" settings and 
the "Java Editor" settings (like text limit count) from 
Options should be kept.

For example, the "Auto-Comment" tool notice the text limit 
count setting but not the "Add leading star in comment" 
setting, and so the comment lines are longer than text 
limit count. If you try to print the source code, many 
lines are to long.

Modules like Jalopy can't change the protected code areas.
Comment 3 Tomas Pavek 2003-07-04 09:09:13 UTC
Sorry, but this is not a defect. Why do you think it is, 
or what thing exactly?
Comment 4 s690716 2003-10-17 09:10:41 UTC
I think it's a defect because the "Java Indentation Engine" settings 
and the "Java Editor" settings (like text limit count) from 
Options is disregared by the gui and/or the editor component.

When an user select 80 as text limit count (or such Identation engine 
stuff), then it should be noticed by these components.

I also mean protected blocks created by gui editor. Why there is the 
ability to change formating rules and other editor setting, if they 
are disregarded?
Comment 5 rationalpi 2006-10-25 17:03:26 UTC
Code generated by tools within the IDE (e.g. Matisse) should conform to the
editor settings for formatting, line lengths, variable names, etc.

In our shop we run coding standards tools (e.g. Checkstyle) against our entire
code base. That results in a significant number of coding standard violations in
 the reports generated by Maven. While it's possible to exclude sections of code
from coding standards in Checkstyle, it's painful to say the least since it
involves line numbers that change.

Lines longer than 80 columns also cause problems when we have occasion to print
source code files.

Joshua Smith