Hallo,

dass Visual Studio zwischen Methoden Trennlinien anzeigen kann, sieht man
schön bei vb.net Code. Kann man das auch für C#-Code aktivieren? Ich finde
das entsprechende Häkchen in den Optionen nicht...

tia,
Stefan

Stefan Simon schrieb:

> dass Visual Studio zwischen Methoden Trennlinien anzeigen kann, sieht
> man schön bei vb.net Code. Kann man das auch für C#-Code aktivieren? Ich
> finde das entsprechende Häkchen in den Optionen nicht...

Also mir ist nix derartiges bekannt. Wozu soll das denn bei C# gut sein?

MfG, Ulf

"Ulf Kadner" <dr_logic> schrieb im Newsbeitrag
news:l011
> Stefan Simon schrieb:
>
>> dass Visual Studio zwischen Methoden Trennlinien anzeigen kann, sieht
>> man schön bei vb.net Code. Kann man das auch für C#-Code aktivieren? Ich
>> finde das entsprechende Häkchen in den Optionen nicht...
>
> Also mir ist nix derartiges bekannt. Wozu soll das denn bei C# gut sein?

Aus dem selben Grund, aus dem es bei vb.net gut ist: es erhöht die
Übersichtlichkeit im Quellcode.

Stefan

Hallo Stefan,

> ... zwischen Methoden Trennlinien anzeigen ...
> Kann man das auch für C#-Code aktivieren?

Ja, früher in VBA/VB noch notwendig.
Im Visual Studio C#-Editor ist das nicht
nativ vorgesehen - es würde u.a.
Implementierungen fördern, die
gegen die Empfehlungen von gutem
Code-Design verstossen.
Etwa sollten Methoden eine gewisse
Zeilenanzahl nicht überschreiten.
Hält man diese Empfehlungen ein, ensteht
normal gar nicht erst die Notwendigkeit
von solchen Dingen.

Trotz allem gibt es dafür natürlich trotzdem
AddIns. Etwa:

[Lines between methods in the C# editor (CodeRush/DxCore plugin) «
Duncan Smart’s Weblog]
http://blog.dotsmart.net/2008/05/02/...dxcore-plugin/

[Microsoft - Source Code Outliner Power Toy]
http://www.codeplex.com/SourceCodeOutliner

Der SourceCodeOutliner ist für diesen Zweck
(nicht die Linien, aber die direkte Methoden-Navigation)
eher noch zu empfehlen, er befindet sich übrigens
unter Menü Ansicht/Weitere Fenster/Source Outliner ..
und kann zum Beispiel auf einen zweiten Desktop
ausgelagert werden, sodass der Platz gut genutzt wird.
Aber: nicht zu viele Zeilen in eine Methode,
und nicht zuviel in eine Klasse.


ciao Frank

Stefan Simon schrieb:

>> Also mir ist nix derartiges bekannt. Wozu soll das denn bei C# gut sein?
>
> Aus dem selben Grund, aus dem es bei vb.net gut ist: es erhöht die
> Übersichtlichkeit im Quellcode.

Ich schließe mich da Franks Aussage an das unübersichlichtlicher
Quellcode ein Zeichen eines nicht so sauberen Programmierstils ist.

Sowas braucht man nicht und sollte stattdessen überdenken wie man seinen
Code besser(übersichtlicher) aufbauen kann.

Aber vieleicht hilft Dir ja Bereits wenn Du einzelne Blöcke in Regionen
definierst. Damit läst sich unübersichliches durchaus noch etwas besser
überblickbar zusammen fassen und man kannst zusammenfalten.

#region Abc
?
?
#endregion

MfG, Ulf

Hallo Ulf,

>Aber vieleicht hilft Dir ja Bereits wenn Du einzelne Blöcke in Regionen
>definierst. Damit läst sich unübersichliches durchaus noch etwas besser
>überblickbar zusammen fassen und man kannst zusammenfalten.

ja, das würde ich auch machen, da das wesentlich besser zu handhaben ist
und auch viel übersichtlicher. Das war auch mein erster Gedanke, als ich
das Posting gelesen habe,...

Große Codeblöcke sind so viel übersichtlicher zu halten,...

Grüße

Kerem

"Frank Dzaebel" <tcnt.Dzaebel> schrieb im Newsbeitrag
news:9b37
Hallo Stefan,

> ... zwischen Methoden Trennlinien anzeigen ...
> Kann man das auch für C#-Code aktivieren?

> Ja, früher in VBA/VB noch notwendig.

Mir erschließt sich nicht vollständig, warum das damals notwendig war und
heute nicht mehr. Ich bin erst recht Spät (mit VS 2005) in das
Microsoftlager gewechselt und habe die VB-Anfänge nicht mitgemacht (vom C64
mal abgesehen).


>Im Visual Studio C#-Editor ist das nicht
>nativ vorgesehen - es würde u.a.
>Implementierungen fördern, die
>gegen die Empfehlungen von gutem
>Code-Design verstossen.
>Etwa sollten Methoden eine gewisse
>Zeilenanzahl nicht überschreiten.

Das ist ein recht einfaches Projekt, mit grob überschlagen 500 Zeilen Code
in 20 Methoden aufgeteilt in 3 Klassen. Ich versuche schon, meinen Code
übersichtlich zu halten, aber an manche Dinge kann man sich echt gewöhnen.
Linien zwischen den Methoden gehören dazu. Geschweifte Klammern um jeden
Block eher weniger.

>Hält man diese Empfehlungen ein, ensteht
>normal gar nicht erst die Notwendigkeit
>von solchen Dingen.

Es geht mir auch nicht um Notwendigkeit, sondern eher um
Gewohnheit/Bequemlichkeit.
VB.Net Code liest sich wie ein englisches Buch, bei C# sehe ich auf den
ersten Blick nur Klammern. Mithilfe der Linien kann ich die Klammern
wenigstens sofort einer Methode zuordnen. Na gut, vielleicht habe ich ein
wenig übertrieben...

>[Lines between methods in the C# editor (CodeRush/DxCore plugin) «
>Duncan Smart’s Weblog]
>http://blog.dotsmart.net/2008/05/02/lines-between-methods-in-the-c-editor-coderushdxcore->plugin/

>[Microsoft - Source Code Outliner Power Toy]
>[..]

Danke,
Stefan

"Frank Dzaebel" <tcnt.Dzaebel> schrieb:
>> ... zwischen Methoden Trennlinien anzeigen ...
>> Kann man das auch für C#-Code aktivieren?
>
>Ja, früher in VBA/VB noch notwendig.
>Im Visual Studio C#-Editor ist das nicht
>nativ vorgesehen - es würde u.a.
>Implementierungen fördern, die
>gegen die Empfehlungen von gutem
>Code-Design verstossen.

Gegen welche denn?

>Etwa sollten Methoden eine gewisse
>Zeilenanzahl nicht überschreiten.
>Hält man diese Empfehlungen ein, ensteht
>normal gar nicht erst die Notwendigkeit
>von solchen Dingen.

Gerade bei kurzen Methoden sind die Trennlinien sinnvoll. Und außerdem
helfen sie auch, optisch lange Methoden zu erkennen und zu vermeiden.

Welchen Nachteil siehst Du?

"Stefan Simon" <s.simon> schrieb:
>> ... zwischen Methoden Trennlinien anzeigen ...
>> Kann man das auch für C#-Code aktivieren?
>
>> Ja, früher in VBA/VB noch notwendig.
>
> Mir erschließt sich nicht vollständig, warum das damals notwendig war und
> heute nicht mehr.

Methodentrennlinien waren früher genau so notwendig wie jetzt: Sie helfen,
Struktur schneller visuell zu erfassen.

"Ulf Kadner" <dr_logic> schrieb:
>>> Also mir ist nix derartiges bekannt. Wozu soll das denn bei C# gut sein?
>>
>> Aus dem selben Grund, aus dem es bei vb.net gut ist: es erhöht die
>> Übersichtlichkeit im Quellcode.
>
> Ich schließe mich da Franks Aussage an das unübersichlichtlicher
> Quellcode ein Zeichen eines nicht so sauberen Programmierstils ist.
>
> Sowas braucht man nicht und sollte stattdessen überdenken wie man seinen
> Code besser(übersichtlicher) aufbauen kann.

Warum sollte Code mit langen Methoden durch Trennlinien übersichtlicher
werden? Die Trennlinien sind dann ja meist gar nicht zu sehen. Trennlinien
haben gerade dann den Vorteil, wenn sie kleine Codehäppchen, die sich gerade
im sichtbaren Ausschnitt des Codeeditors befinden, besser erkennen lassen.

> Aber vieleicht hilft Dir ja Bereits wenn Du einzelne Blöcke in Regionen
> definierst. Damit läst sich unübersichliches durchaus noch etwas besser
> überblickbar zusammen fassen und man kannst zusammenfalten.

Diese Möglichkeit würde ich bestenfalls auf Ebene über den Methoden nutzen,
um zusammengehörige Methoden (evtl. auch zahlreiche zusammengehörige
Überladungen) zu gruppieren.

Hallo Stefan,

> > ... zwischen Methoden Trennlinien anzeigen ...
> > Kann man das auch für C#-Code aktivieren?
> > Ja, früher in VBA/VB noch notwendig.
>
> Mir erschließt sich nicht vollständig, warum das damals
> notwendig war und heute nicht mehr. Ich bin erst recht
> Spät (mit VS 2005) in das Microsoftlager gewechselt
> und habe die VB-Anfänge nicht mitgemacht (vom C64
> mal abgesehen).

Es gibt (im Gegensatz zu früher) jetzt unter
..NET ein stark verbesserte wirkliche
Objektorientierung (falls man unter VB6 zum Beispiel
überhaupt davon reden konnte) möglich.
Dazu hat man die Möglichkeit von partial Klassen
und vieles mehr.
Man *kann* also wirklich seine Klassen und Methoden
klein halten (alles Empfehlungen für gutes Codedesign),
sie OOP-mässig strukturieren. Im Prinzip solltest
Du Deine Strukturierung also in der Projektmappen-
Ansicht wiederfinden.
Würde man jetzt solche Tools in den Standard mit
hineinbringen, ist das IMHO ein Fördern von
Spaghetti-Code. C# Design/Denken ist hier besonders
konsequent, weil in vielen Bereichen (z.B. Typsicherheit)
ganz konsequent auf solche Standard-Einstellungen
geachtet wird, um von vorneherein möglichst ein sauberes
Projekt- und Codedesign zu erzwingen.
Ein Pendant ist zum Beispiel bei der Typsicherheit
das Zuweisen von Werten zu Datentypen.
Du verstehst, es können manchmal Dinge temporär
sehr hilfreich sein, aber im Gesamtzusammenhang
doch zu vermeiden.

Aber was solls, wenn es für Dich
nicht anders geht, nimmst Du eben die Tools,
die ich Dir vorgeschlagen habe.



> Das ist ein recht einfaches Projekt, mit grob
> überschlagen 500 Zeilen Code in 20 Methoden
> aufgeteilt in 3 Klassen.

Methoden-Zeilenlänge ist in Ordnung, Klassen .. gut,
*wenn* es für Dich unübersichtlich wird,
kannst Du ja ein oder zwei zusätzlich
kapseln, oder ggf. partial machen und dann
in zwei cs-Dateien eine doppelt besseren
Überblick haben.
Mein empfohlener Source Outliner oder die ComboBox
rechts oben in einem *.sc Fenster zeigen dir
dann ~13 Methoden an. Oder 6 Methoden
in jeweils einer partial class.
Das reicht doch vollkommen und ist eine
hervorragende Überblick, als
in VB.NET sich den Mittelfinger heiss rollt
mit Trennlinien.





> Ich versuche schon, meinen Code übersichtlich zu
> halten, aber an manche Dinge kann man sich echt gewöhnen.

Klar, Gewöhnung ist immer erst mal ein wenig da.






> >Hält man diese Empfehlungen ein, ensteht
> >normal gar nicht erst die Notwendigkeit
> >von solchen Dingen.
>
> Es geht mir auch nicht um Notwendigkeit, sondern eher um
> Gewohnheit/Bequemlichkeit.

vielleicht hattest Du auch noch nicht die
ComboBox rechts oben und links oben entdeckt?




> >[Lines between methods in the C# editor (CodeRush/DxCore plugin) «
> >Duncan Smart’s Weblog]
> >http://blog.dotsmart.net/2008/05/02/lines-between-methods-in-the-c-ed...>plugin/
> >[Microsoft - Source Code Outliner Power Toy]
> >[..]
>
> Danke,
> Stefan

gerne.


ciao Frank

Herfried K. Wagner [MVP] schrieb:

>> Sowas braucht man nicht und sollte stattdessen überdenken wie man seinen
>> Code besser(übersichtlicher) aufbauen kann.
>
> Warum sollte Code mit langen Methoden durch Trennlinien übersichtlicher
> werden?

Ja das frage ich mich auch.

> Die Trennlinien sind dann ja meist gar nicht zu sehen.
> Trennlinien haben gerade dann den Vorteil, wenn sie kleine Codehäppchen,
> die sich gerade im sichtbaren Ausschnitt des Codeeditors befinden,
> besser erkennen lassen.

Das mag vieleicht für VB gelten aber bei C# gibts die ja nicht und obs
damit in C# übersichtlicher wird kann ich nicht beurteilen. Aber bisher
hab ich derartiges nicht gebraucht und nicht die Übersicht verlohren.

>> Aber vieleicht hilft Dir ja Bereits wenn Du einzelne Blöcke in Regionen
>> definierst. Damit läst sich unübersichliches durchaus noch etwas besser
>> überblickbar zusammen fassen und man kannst zusammenfalten.
>
> Diese Möglichkeit würde ich bestenfalls auf Ebene über den Methoden
> nutzen, um zusammengehörige Methoden (evtl. auch zahlreiche
> zusammengehörige Überladungen) zu gruppieren.

Genau darum gings. Zumindest verstand ich die Frage des OPs so.

MfG, Ulf

"Frank Dzaebel" <tcnt.Dzaebel> schrieb:
>
>Es gibt (im Gegensatz zu früher) jetzt unter
>.NET ein stark verbesserte wirkliche
>Objektorientierung (falls man unter VB6 zum Beispiel
>überhaupt davon reden konnte) möglich.
>Dazu hat man die Möglichkeit von partial Klassen
>und vieles mehr.
>Man *kann* also wirklich seine Klassen und Methoden
>klein halten (alles Empfehlungen für gutes Codedesign), [...]

Das konnte man in Classic VB ebenfalls, aber natürlich teilweise auf anderem
Wege.

>Würde man jetzt solche Tools in den Standard mit
>hineinbringen, ist das IMHO ein Fördern von
>Spaghetti-Code.

Belege, warum.

> Im Prinzip solltest Du Deine Strukturierung also in der
> Projektmappen-Ansicht wiederfinden.

Wenn ich mich gerne aus dem Fenster lehnen würde, würde ich jetzt behaupten,
daß gerade das den Spaghetti-Code fördert, da man, wenn man über die
Projektmappenansicht geht, die Codelänge gar nicht mehr mitbekommt.

> C# Design/Denken ist hier besonders
> konsequent, weil in vielen Bereichen (z.B. Typsicherheit)
> ganz konsequent auf solche Standard-Einstellungen
> geachtet wird, um von vorneherein möglichst ein sauberes
> Projekt- und Codedesign zu erzwingen.

C# ist eine Programmiersprache. C# kennt, genau so wenig wie VB,
Trennlinien. VS kennt sie (optional) bei VB-, nicht aber bei C#-Code.

Trennlinien sorgen, genau so wie Codegliederung (und Einrückungen und
Leerzeilen) für eine bessere Übersicht über den Quellcode -- gerade dadurch,
daß sie Dinge trennen bzw. als Zusammengehörig auszeichnen.

>Mein empfohlener Source Outliner oder die ComboBox
>rechts oben in einem *.sc Fenster zeigen dir
>dann ~13 Methoden an. Oder 6 Methoden
>in jeweils einer partial class.
>Das reicht doch vollkommen und ist eine
>hervorragende Überblick, als
>in VB.NET sich den Mittelfinger heiss rollt
>mit Trennlinien.

Du vergleichst Äpfel mit Birnen. Was haben die Trennlinien mit Überblick
darüber zu tun, welche Mitglieder eine Klasse besitzt? Trennlinien helfen in
der Codeansicht (und sonst nirgendwo), die Grenzen zwischen einzelnen
Mitgliedern/Bereichen zu erkennen.

Hallo Herfried,

>>Würde man jetzt solche Tools in den Standard mit
>>hineinbringen, ist das IMHO ein Fördern von
>>Spaghetti-Code.

> Belege, warum.

Ich versuche mal die Belegschaft:

A) Trennlinien sind ein VB-Feature.

B) In VB ist der Zwang, Spaghetti-Code zu schreiben, explizit
eingebaut.

Aus A und B folgt:
Trennlinien zwingen einen, Spaghetti-Code zu schreiben.

C) Trennlinien sind kein C#-Feature.

D) In C# ist die Möglichkeit, Spaghetti-Code schreiben, potenziell
eingebaut.

Aus C und D folgt:
Das Fehlen von Trennlinien verhindert Spaghetti-Code.

>> C# Design/Denken ist hier besonders
>> konsequent, weil in vielen Bereichen (z.B. Typsicherheit)
>> ganz konsequent auf solche Standard-Einstellungen
>> geachtet wird, um von vorneherein möglichst ein sauberes
>> Projekt- und Codedesign zu erzwingen.

> C# ist eine Programmiersprache. C# kennt, genau so wenig wie VB,
> Trennlinien. VS kennt sie (optional) bei VB-, nicht aber bei C#-Code.

Ja mei... ist doch ganz einfach: Ein VB-spezifisches Feature kann
einfach nicht gut sein.

</Ironie>

(Huch - habe ich doch versehentlich zu Anfang das <Ironie> vergessen -
bitte nachtragen!)


Viele Grüße

Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de (Chefredakteur)
"ABOUT Visual Basic" - http://www.aboutvb.de (Herausgeber)

Hallo Harald,

> A) Trennlinien sind ein VB-Feature.

nein, eine voreingestellte IDE-Ansicht
des Visual Studio Editors für VB-Quellcode.




> B) In VB ist der Zwang, Spaghetti-Code zu schreiben, explizit eingebaut.

nein, Trennlinien "fördern" nur IMHO
unstrukturierten Code (kein Zwang, das
hast Du falsch wiedergegeben).
Wenn eine Trennlinie nötig werden würde,
ist eher eine OOP-Kapselung oder andere
saubere Architektur-Umordnung angesagt.




> Aus A und B folgt:
> Trennlinien zwingen einen, Spaghetti-Code zu schreiben.

falsch wiedergegeben, Trennlinien "fördern" das nur,
genauso, wie andere "Features", die unstrukturierten
Code irgendwie versuchen in ein Pseudo-Schema
zu packen. IMHO besser, das Unglück an der Wurzel beseitigen.





> C) Trennlinien sind kein C#-Feature.

nein, andere IDE's könnten durchaus
Trennlinien haben (das ist nicht verboten durch
die C# Spezifikation). Das gilt nur für den
Visual Studio Editor für C#. Es ist vom
C# Design und Ansatz aber so, dass man
keinen unstrukturierten Code (schon im Standard)
fördern möchte.





> D) In C# ist die Möglichkeit, Spaghetti-Code schreiben, potenziell
> eingebaut.

in allen Programmiersprachen ist es möglich,
Spaghetticode zu schreiben.
Nur "fördern" bestimmte Design-Massnahmen
unstrukturierten Code mehr.
Für gut strukturierten Code mit empfohlenen
Richtlinien von Microsoft sind normal keine
zusätzlichen Hilfmittel notwendig, da ist die
Klassen und Methoden-Auswahl der VS-IDE
vollkommen ausreichend.




> Aus C und D folgt:
> Das Fehlen von Trennlinien verhindert Spaghetti-Code.

Leider nicht, es fördert nur gute eigene OOP-Kapselung/Architektur.
Aus: "aus A folgt B" dürfte man eh nicht "aus B folgt A" folgern.
Ausserdem müsste A wahr sein ;-)

Was solls, wenn jemand die haben möchte, nimmt er
die von mir am Anfang vorgeschlagenen Tools.

Ich habe vor vielen Jahren auch von VB6 auf C#
gewechselt, zunächst vermisste ich die durch
Gewohnheit genauso, bis ich merkte, dass durch
bessere OOP-Möglichkeiten und Sprach-Features
unter .NET solche Hilfsmittel nicht mehr nötig waren.

Ich denke, ich beende da meinen Beitrag zur Diskussion.



ciao Frank