Couple of feature suggestions
Maybe too late to add now but just thought I'd mention them. They are
mainly the result of nasty code generation output from the designer.
1. Removal of comments/summary tags
2. Removal 'this.' prepended by the designer
3. Exceptions for formatting braces
In more detail:
1. Pointless comments/summary tag removal
//
// _callIcon
//
this._callIcon.ImageIndex = 0;
What is the point of this?
We can see it's the _callIcon why does the designer insist on inserting
this junk. Also I have no desire for code to be littered with summary
tags and regions. Source files are for code not documentation. And
comments are excuses for writing bad code. If you need a comment then
you need to do an extract method and convert the comment to the method
name. Regions just hide the fact that the class needs refactoring.
Of course if you refactored form generated code once you went back into
the designer and changed something it would regenerate everything and
ignore the refactorings but it would be a start.
2. Not sure why the designer insists on prepending this. for every field
but this (:) could easily be sorted.
3. Exceptions for formatting braces
The designer adds code like this:
this.toolbar.Buttons.AddRange(new ToolBarButton[] {
this._callIcon,
this._optionsIcon,
this._helpIcon});
It would be nice for ReSharper to format this in a different way from
other brace styling. For example I prefer:
this.toolbar.Buttons.AddRange(new ToolBarButton[] {this._callIcon,
this._optionsIcon, this._helpIcon});
(In case this got wrapped I meant for the whole thing to be on a single
line). You could then let Visual Studio deal with the wrapping
(hopefully VS.NET 2005 will handle word wrapping better).
Finally, I'd just like to add that I've never seen so many formatting
options. It caters for every coding style (just about) and it's
fantastic. Great tool! Cheers.
Regards,
Phil Thompson
Please sign in to leave a comment.
Unfortunately, the form designer is sensitive to the contents of the
InitializeComponents(): for example, it does not allow replacing constant
literals with contants (or you will not be able to edit the form in the
design mode any more). Moreover, the form designer recreates code in
InitializeComponents() every time you edit a form in the design mode, and
ReSharper would have to reformat the code continuously. Actually, we have
requests not to show warnings for the contents of InitializeComponents().
--
Andrey Simanovsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Phil Thompson" <phil@electricvisions.com> wrote in message
news:cba8o9$4r6$1@is.intellij.net...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
"Andrey Simanovsky (JetBrains)" <ands@jetbrains.com> wrote in message news:cbbl40$erb$1@is.intellij.net...
>> 2. Removal 'this.' prepended by the designer
in addition,
if you remove redundant cast created by designer, it(designer) gets very confused in some cases..
e.g.:
removing cast ISupportInitialize from StatusBarPanel.
Andrey Simanovsky (JetBrains) wrote:
Yes I realise this. I guess I just really don't like the idea of not
being able to refactor a huge pile of auto-generated code but Microsoft
don't seem to see this as a problem.
A colleague suggested doing all the GUI design first then not use the
designer again but I don't think this would work either as you don't
know what changes/additions to the interface you'll need to make until
you've finished the project but I used to write code for all my GUI work
so maybe it would be ok just to use the designer once to get the basic
framework going.
I've only just started learning C#.NET and will find ways to work. At
least it's not MFC hey?! A hundred lines of auto-generated code is
better than thousands!!
Regards,
Phil
P.S. Anyone else found this to be a problem or is everyone quite happy
to let the designer do it's thang?
I personally would be very happy to let the designer do its thing if only it
did it properly. VS forms designer drives me crazy. It sometimes very often
to prevent myself from smashing my monitor when I use it.
--
Valentin Kipiatkov
Chief Scientist, Vice President of Product Development
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Phil Thompson" <phil@electricvisions.com> wrote in message
news:cbf3qn$i6k$1@is.intellij.net...
constant
and
have
InitializeComponents().
>
>
>
>
>
On Tue, 22 Jun 2004 22:40:43 +0100, Phil Thompson
<phil@electricvisions.com> wrote:
"Source files are for code not documentation. And comments are excuses for
writing bad code." - hmm...I'm sure I'm not the only one who totally
disagree with this.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Noli San Jose wrote:
It's ok to disagree if you have a valid argument. Just because it's
always been done this way. Doesn't make it right.
There are two points in my original statement. Let me just clarify them:
1. Source file are for code not documentation
I think perhaps it's ok when you are writing a library that other
developers will need to write against but the number of times I've seen
Java API libraries with JavaDoc containing only the stubs and no useful
comments I wonder what the point is. Of course I've never written a
library so I cannot comment from experience.
However, when writing on your own or in a team that shares the codebase
there is no need for documentation type comments. People who need to
read documentation to understand how a program works is not a developer
and so developers should not write documentation if possible. My point
is that the two tasks should be separated to avoid rewording method
names to make the documentation.
2. Comments are excuses for writing bad code.
This is completely different from point 1 and I stand by this
wholeheartedly. Take a look here for reasons not to comment code:
http://c2.com/cgi/wiki?TreatCommentsWithSuspicion
I work with a team of 20-30 other developers on a project I started four
and a half years ago. I used to comment code. If I look at some of the
few remaining comments and then look at the corresponding code the
comments are complete lies. This is because people change code but not
comments. Because comments are not compiled, tested or asserted they can
become invalid without anyone noticing.
For an alternative to commenting, lookup Unit Testing or Test Driven
Design. Unit tests provide a way to describe how something should work
and fail a test if it doesn't. A tool for unit testing in C# is
available here (http://www.nunit.org) and you can integrate this with
Visual Studio by downloading this addin
(http://sourceforge.net/projects/nunitaddin/).
Please feel free to comment :)
Regards,
Phil