Laden...

Codeformatierung in Visual Studion 2019 ändern

Erstellt von LittleTester vor 2 Jahren Letzter Beitrag vor 2 Jahren 421 Views
L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren
Codeformatierung in Visual Studion 2019 ändern

Standardmäßig macht Visual Studio den Code ja so:


            try
            {
                if(Foo == Bar)
                {
                    // Mach was
                }
                else
                {
                    // Mach was anderes
                }
            } catch (Exception ex)
            {
                // Fehler
            }

Ich hätte das aber gerne so:


            try {
                if(Foo == Bar) {
                    // Mach was
                } else {
                    // Mach was anderes
                }
            } catch (Exception ex) {
                // Fehler
            }

Natürlich kann ich das immer von Hand so umformatieren, aber wenn ich dann irgendwas ändere und wieder Enter drücke, kann es sein das Visual Studio das wieder anpasst.
Gibt es eine Möglichkeit das zu ändern? Ich finde den Codestil von mir besser lesbar. Außerdem verballert man als kleinen Nebeneffekt keine extra Zeile für ein {.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

309 Beiträge seit 2020
vor 2 Jahren

Hi,
ja in den Optionen von Visual Studio unter Text-Editor / C# / Formatierung / Neue Zeilen

D
261 Beiträge seit 2015
vor 2 Jahren

Ja siehe Screenshot im Anhang

4.931 Beiträge seit 2008
vor 2 Jahren

Ich finde deinen Codestil (K&R C und Java-Standard) aber viel schlechter lesbar, da man nicht auf Anhieb die Blöcke erkennt, d.h. welche offene zu welcher geschlossenen Klammer gehört.

Ich finde, man sollte sich bei C# an die offiziellen C# Coding Conventions halten.

T
2.219 Beiträge seit 2008
vor 2 Jahren

Sehe ich genau so.
Macht den Code schwer lesbar, was bei längeren Code Blöcken auch die Hilfe bei der Fehelrsuche erschwert.
Ebenfalls ist der Java Stil beim Klammern setzen immer ein Albtraum.
Hier nach der fehlenden Klammer zu suchen, hat mich schon 1-2 mal Nerven gekostet.
Mit einer Klammer in einer eigenen Zeile ist die Suche einfacher 🙂

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 2 Jahren

Wenn Du C# schreiben willst, solltest dich an die Konventionen halten.
Am Code Stil erkennt man sofort ob jemand die Sprache verstanden hat, oder nicht.

In professionelleren Projekten oder Open Source Projekten werden dich die Mitentwickeler hassen (zurecht) wenn Du deine eigenen Regeln mitbringst (Beispiel: Style Regeln vom ASP.NET Repository)
Bzw werden sie einfach deinen Code nicht akzeptieren, was man mit Regeln auch automatisieren kann und weit verbreitet ist.
Übrigens eines der ersten Dinge, die ich bei meinen Kunden-DevOps empfehle: C# Regeln mit allen Mitteln durchsetzen, und wenn sich jemand im Team weigert, dann muss man ihn halt aus dem Team nehmen.
Codeanalyse mithilfe von Roslyn-Analysetools - Visual Studio (Windows)
EditorConfig-Einstellungen - Visual Studio (Windows)

Und zurecht bekommst du wie hier das Feedback dass es Murks ist 🙂

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Also ich finde die Standardformatierung aus oben genannten Gründen nicht so toll. Als Argument kommt noch hinzu, dass der sich der Code unnötig in die Länge zieht. Mit "meiner" Methode ist er viel kompakter.

Ich denke da bin ich nicht der Einzige der "meinen" Codestil favorisiert, sonnst wäre das ja nicht in Visual Studio einstellbar, oder?

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

Ich kann Dir durchaus sagen, dass Du der absoluten Minderheit angehörst, die es für gut hälst C# nach Java-Stil zu formatieren. Vermutlich im 0,01 Promille-Bereich.
Und wie gesagt aus Erfahrung: machst Du sowas in etablierten C# Teams, machst Dir alles, aber keine Freunde 😉
Da helfen Dir Deine "Argumente" auch nicht, die doch eher subjektiv als objektiv sind.

Einstellbar ist vieles, vor allem aus historischen Gründen.
Die Naming + Style Guidelines gibts nicht umsonst.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Hmmm, es ist Java-Codestil? DAS wäre wirklich ein Argument von dem Stil Abstand zu nehmen. Wieso programmiert man in Java so und in anderen Programmiersprachen anders? Gibts da Gründe für?

Was das Programmieren in "etablierten" Teams angeht. So gut werde ich wohl nicht, als das ich da mitmischen könnte 😉. Bin ja froh, wenn ich mit meinem eigenen Code klar komme. - und ihr.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

Es gab genug Kriege, welcher Style der beste ist.
Letzten Endes hat sich herausgestellt: man sollte sich immer gemäß dem Ökosystem verhalten, egal ob in C, C++, Java, JavaScript, TypeScript oder C# aka You should never do the 3rd method
Aber ich merk schon; eine gewisse Beratungsresistenz ist da. Da bringt jede Empfehlung und Hintergrund-Erklärung nichts.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Ich möchte es nicht "Resistenz" nennen. Das klingt so nach "uneinsichtig" und "besserwisserisch". Ich komme mit dem Stil besser klar. Das ist alles. Ich habe sonnst keine "Dafür" oder "Dagegen" Gründe.

Ich will aber gucken dran zu denken den Code anzupassen, wenn ich im Forum stelle, damit ihr es einfacher habt. Seid mir aber bitte nicht böse, wenn ich es mal vergesse oder mal ne Klammer übersehe.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

190 Beiträge seit 2012
vor 2 Jahren

Wenn du einen älteren und von anderen Kollegen geschriebenen Code vor dir hast, der eine Unmenge an if's und Schleifen hat, teilweise sehr tief geschachtelt (hab ich gerade 😦 ), dann bist du glücklich, wenn er einigermaßen lesbar ist. Da interessiert es dich nicht, ob der Entwickler vor Jahren glücklicher war, weil er eine Zeile eingespart hat. Und deine Variante ist jetzt schon schwer zu lesen. Wenn die zusammengehörigen Klammern übereinander stehen, dann sieht man gleich, was zusammen gehört. Macht sich auch beim kopieren einfacher.

  • Wer lesen kann, ist klar im Vorteil
  • Meistens sitzt der Fehler vorm Monitor
  • "Geht nicht" ist keine Fehlermeldung!
  • "Ich kann programmieren" != "Ich habe den Code bei Google gefunden"

GidF