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


6 comments
Comment actions Permalink

2. Removal 'this.' prepended by the designer

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...

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

>
>


0
Comment actions Permalink


"Andrey Simanovsky (JetBrains)" <ands@jetbrains.com> wrote in message news:cbbl40$erb$1@is.intellij.net...
>> 2. Removal 'this.' prepended by the designer

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().


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.


0
Comment actions Permalink

Andrey Simanovsky (JetBrains) wrote:

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().


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?

0
Comment actions Permalink

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...

Andrey Simanovsky (JetBrains) wrote:

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().

>

>

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?



0
Comment actions Permalink

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/

0
Comment actions Permalink

Noli San Jose wrote:

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.


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

0

Please sign in to leave a comment.