Laden...

Codeformatierung: Position bzw. Nutzung der geschweiften Klammern bei Methoden bzw. bei if

Erstellt von Tehral vor 10 Jahren Letzter Beitrag vor 10 Jahren 13.140 Views
T
Tehral Themenstarter:in
20 Beiträge seit 2013
vor 10 Jahren
Codeformatierung: Position bzw. Nutzung der geschweiften Klammern bei Methoden bzw. bei if

Hallo Zusammen,

Ich frage mich schon seit langem welche der folgenden Varainten "besser" ist?


void FunktionsName()
{

}

oder

void FunktionsName(){

}

Des Weiteren frage ich mich was sollte man verwenden?

if(Überprüfung)
   Code;

oder

if(Überprüfung)
{
   Code;
}

Danke für eure Hilfe,

Gruss,
Tehral

1.696 Beiträge seit 2006
vor 10 Jahren

Bei Methoden: Die 1., weil VS automatisch macht 😉

Bei Einzeilenanweisung die 1. (mit Einrückung), bei Mehrzeilen die 2.

Grüße

Ich bin verantwortlich für das, was ich sage, nicht für das, was du verstehst.

**:::

16.807 Beiträge seit 2008
vor 10 Jahren

Das sehe ich anders.

void FunktionsName()
 {

 }

ist in der C#-Welt normal.

if(Überprüfung)
   Code;

Halte ich für einen schlechten Stil, da es den Code unleserlicher macht.

Jedes mal wenn ich sowas sehe wie

if (!test) return;

könnte ich kot*** weil man so ein return einfach viel zu schnell übersieht.

Aber das hier ist eine Glaubensfrage, das ist wie "Glas halb voll oder halb leer" und eine absolute Antwort gibt es nicht.
Ingesamt sollte man sich an Codekonventionen für C# (C#-Programmierhandbuch) halten.

T
Tehral Themenstarter:in
20 Beiträge seit 2013
vor 10 Jahren

Danke für die Info, setze das nun auch so um 😃
Evtl. behalte ich aber mein System mit

if()
{

}

weiter da ich den Code so "lesbarer finde".

PS:
Die Frage enstand bei mir eigentlich nur, weil ich immer in allen Büchern

void FunktionsName(){

}

sehe.

Finde ich eigentlich schade weil meiner Meinung nach macht es den Code einwenig unübersichtlicher.

Gruss,

Tehral

EDIT: @Abt sehe ich auch so ^^

4.931 Beiträge seit 2008
vor 10 Jahren

In Büchern wird dies meistens so geschrieben, um Platz zu sparen, so daß der Code nicht so groß wird (bzw. erscheint).

P.S. Nimm für C#-Code hier im Forum die C#-Tags...

5.941 Beiträge seit 2005
vor 10 Jahren

Hallo zusammen

Ich bin da voll bei der Meinung von Abt.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

2.078 Beiträge seit 2012
vor 10 Jahren

Bei Methoden sehe ich das genauso. Die automatische Formatierung von Visual Studio ist Programm.

Bei if-Statements sehe ich das etwas anders.

Zum einen braucht man ja die geschweiften Klammern, wenn mehr als eine Zeile im if steht.
Bei einer Zeile lasse ich die geschweiften Klammern allerdings weg. Ist die eine Zeile sehr klein, dann schreibe ich das manchmal auch ohne Einrückung, meist aber mit.

Zu dem Argument von Abt:

So ein return im if übersieht man tatsächlich sehr leicht und genau deshalb halte ich mich an die Regel, dass in jeder Methode immer nur ein return steht und das steht am Schluss. Ich mache das dann so, dass ich am Anfang eine result-Variable erstelle, die im Laufe der Methode bearbeitet und am Schluss zurück gegeben wird.
So kann ich das return nicht übersehen.

Außerdem sind meine Methoden meist sehr klein gehalten, weshalb da der Überblick gut zu halten ist.

Edit:

Bei Methoden ohne Rückgabeparameter achte ich darauf, dass die Methode nicht irgendwo zwischendrin endet. Das Problem, dass man ein return leicht übersieht, hat man ja immer, egal ob in einem if, oder irgendwo anders, daher endet eine Methode bei mir grundsätzlich auch am Ende des Code-Blocks.

Ausnahmen sind Exceptions, da versuche ich das dann so zu regeln, dass ich Exceptions entweder am Anfang werfe und die dann zusammen sortiert stehen (z.B. bei Parametern, die irgendwelche Bedingungen nicht erfüllen).
Ansonsten fallen Exceptions schon wegen der meiner Meinung nach auffälligen Schreibweise (throw new Exception(string)) auf.

2.207 Beiträge seit 2011
vor 10 Jahren

So ein return im if übersieht man tatsächlich sehr leicht und genau deshalb halte ich mich an die Regel, dass in jeder Methode immer nur ein return steht und das steht am Schluss. Ich mache das dann so, dass ich am Anfang eine result-Variable erstelle, die im Laufe der Methode bearbeitet und am Schluss zurück gegeben wird.
So kann ich das return nicht übersehen.

Das macht bei Listen beispielsweise Sinn. Die werden gefüllt, bearbeitete etc. Aber zb. bei boolschen Variablen ist das nur hinderlich.

Wenn du, wie du sagst, kleine Methoden hast (was sehr gut ist), diese noch richtig benennst (was noch besser wäre --> Clean Code), dann hat man auch mal ein return in einer Funktion, die sehr klein ist. Wie gesagt, meist beim bool


private void DoesMyObjectHasXyz(MyObject myobject)
{
      foreach(Things in myObject.Things)
      {
           if(things == KeineAhnungWas)
          {
               return true;
          }
      }
      return false;
}

(Linq und sowas mal ausser acht gelassen, das gilt nur als Beispiel). Kleine Methoden sind also keine Sicherheit kein return in einer Funktion zu haben.

Ich bin voll Abts Meinung: Geschweifte Klammern sind zu setzen. Punkt. Generell bin ich eher für absolute Regeln, weil es sonst, gerade in Teams, NUR Diskussionen gibt. (Auch wenn die Regeln irgendwo niedergeschrieben sind es gibt definitiv Diskussionen!).

Dann hat man es a) einheitlich und b) übersichtlich.

Gruss

Coffeebean

16.807 Beiträge seit 2008
vor 10 Jahren

.. und Exceptions würde die eigen Regel brechen, da sie ja mitten in der Methode die weitere Ausführung stoppt 😉

Ich hab lieber 700 Returns in einer Methode als ein viel zu viel geschachtelter Code. VS und die Productivity Tools helfen ja schon sehr bei der Erkennung von Ausstiegspunkten; aber bei inline-returns seh ich rot.

F
10.010 Beiträge seit 2004
vor 10 Jahren

Und für Fomatierung mal StyleCop anschauen und staunen wie viele "Fehler" man macht.

849 Beiträge seit 2006
vor 10 Jahren

Inline return oder Inline Irgendwas geht gar nicht.

Aber ich lasse auch gern die Klammer bei ein Statement Bedingungen weg.

Viel wichtiger ist wie ich finde die korrekte Einrückung (Egal ob mit oder ohne Klammern). Hat schonmal jemand Python programmiert? 😉

Wenn dann so etwas da steht krieg ich das ko****


if(mopped)
i++;

oder gar


if(mopped)

i++;

das würde ich einfach überlesen, und würde im ersten Moment vermuten das i++ immer ausgeführt wird.

2.078 Beiträge seit 2012
vor 10 Jahren

@Coffeebean: Eine Methode ohne Rückgabetyp kann kein bool zurück geben 😉

So würde ich das schreiben:

private bool DoesMyObjectHasXyz(MyObject myobject)
{
      var result = false;

      foreach (var in myObject.Things)
      {
           if (things == KeineAhnungWas)
               result = true;
      }

      return result ;
}

Das mag in so einem kleinen Beispiel etwas übertrieben wirken, ich finde es aber dennoch besser, da es einheitlich ist und ich genau weiß, wo der rote Faden der Methode beginnt und wo er endet.

Eine Exception reißt das System natürlich auseinander, aber wirklich vermeiden kann man das ja nicht. Der kleine Umfang der Methoden hilft dabei aber wieder, da zumindest bei mir bisher immer an Anfang schon klar ist, ob eine Exception auftritt, oder nicht. Die Methoden sind in so einem kleinen Umfang, das meist schon das Überprüfen der Parameter ausreicht um alle Fehler abzudecken und das steht dann direkt am Anfang leicht zu finden.

Geschweifte Klammern mag ich nicht überall, eigentlich vermeide ich sie, solange in meinen Augen dabei nicht die Übersichtlichkeit verloren geht.
Daher habe ich bei dem foreach die geschweiften Klammern gelassen, obwohl nur ein kleines if im Anweisungsblock steht, einfach weil es sonst unübersichtlich werden würde.
Wenn sich soetwas noch weiter verschachtelt (mehrere Schleifen, oder if-Statements), dann kann ich das meistens in mehrere Methoden auf splitten.

16.807 Beiträge seit 2008
vor 10 Jahren

Genau das ist ein schwerer Fehler und genau so entstehen Peformance-Probleme.
Perfektes Beispiel für Coding Styles Horror

Angenommen Du hast 143826482340 Millionen Einträge in Deiner Liste und der erste ist bereits true: die Schleife wird komplett - und das sinnlos - durchlaufen.

Schleifen gehören so früh wie möglich unterbrochen und bei Dir gehört da MINDESTENS ein break rein, wenn nicht ein return!

Kürzer, übersichtlicher:


private bool DoesMyObjectHasXyz(MyObject myobject)
{
       foreach (var thing in myObject.Things)
       {
            if (thing == KeineAhnungWas)
            {
                return true;
            }
       }

       return false;
}

2.078 Beiträge seit 2012
vor 10 Jahren

Dann lieber ein break, aber ein return gehört für mich einsam ans Ende.

Aber danke für den Hinweis, ich hätte vermutlich auch bei einer Methode in einem tatsächlichen Projekt nicht daran gedacht, jetzt bin ich dafür erst einmal sesibilisiert. ^^

PS:

Eine Möglichkeit wäre ja auch, dass ich in der Schleife prüfe, ob das result zurück gegeben werden kann (bei einem Referenztyp z.B., ob nicht null) und breche die Schleife dann ab.

C
2.121 Beiträge seit 2010
vor 10 Jahren

Nach einem if oder for oder so kommt bei mir ein Zeilenumbruch. Sonst wirds wirklich unübersichlich.

Aber ich mache so viele return wie nur möglich. Eine Methode die zuerst mal 5 Dinge prüfen muss bevor sie weitermacht, kriegt von mir 5 returns am Anfang. Wenn in einer Schleife Schluss ist, gehts eben dort raus.
Hier zig Einrückungsebenen durchzuziehen halte ich für Wahnsinn. Wenns raus soll, dann gehts raus und wird nicht noch mit bools oder sonstigem verkompliziert.

Aber das sieht jeder anders 😃

Ich würd mir was angewöhnen das nicht zu exotisch ist, damit du mit fremdem Code nicht unnötig Probleme hast.

16.807 Beiträge seit 2008
vor 10 Jahren

Übrigens. Apples Sicherheitsbug der SSL Verbindung basiert auf genau dieser Frage des Themas.
Sicherheitslücke: Apples furchtbarer Fehler - wäre mit Klammern (wahrscheinlich) nicht passiert.

Hinweis von herbivore vor 10 Jahren

return oder nicht return ist nicht Thema des Threads. Bitte immer auf den Titel achten. Außerdem wurde das Thema return oder nicht, schon in anderen Threads ausführlich behandelt, z.B. in return mitten in einer Methode?. Erst recht soll das kein Sammel-Thread zu allen denkbaren Programmierkonventionen werden. Bitte bleibt beim Ausgangsthema, der Klammersetzung bei Methoden und bei ifs.

175 Beiträge seit 2010
vor 10 Jahren

Moin!

Also was nun "besser" ist.... Ich denke, da spielt so einiges zusammen.....

Vor einigen Jahren habe ich mal ein Buch über Code-Konventionen gelesen und darin hat der Autor auch beschrieben, wie eigentlich das Gehirn und der menschliche Sehapparat zusammenarbeiten. Der Autor schrieb, dass das Auge eigentlich nur horizontale und vertikale Balken/Blöcke sieht und das Gehirn daraus dann erst aufwendig ein "Bild" zusammenbasteln muss.

Aus diesem Grund kann man das Gehirn gut unterstützen, in dem man den Code bereits hirngerecht formatiert.

Daher ist


if (bla) {
   machdies();
   machdas();
}

für das Gehirn anstrengener zu interpretieren als beispielsweise ein


if (bla)
{
   machdies();
   machdas();
}

Hier ist der inhalt des if's viel deutlicher von Leerraum umgeben - der "Block" ist für das Gehirn eindeutiger zu identifizieren.

Wenn ich C# entwickle dann schreibe ich Code auch so - das habe ich schon zu C Zeiten so getan. Beruflich entwickle ich allerdings in Java und da haben wir im Team eine andere Konvention (nämlich die obere). Ich habe inzwichen mit beidem kein Problem. Viel wichtiger ist in diesem Zusammenhang, dass wir im Team uns alle an die gleichen Konventionen halten, damit man sich auch schnell in "fremdem" Code zurecht findet.

Code, der nicht zu den eigenen Konventionen passt kommt bei uns auch nicht durchs Code-Review. Also Code, wie ihn als Negativbeispiel unconnected gepostet hat, also


if (bla) i++;
// oder
if (bla)

i++;

Würde bei uns nicht einmal ansatzweise durch das Review kommen. ich würde sogar sagen, der Code würe bei uns durch StyleCop schon angemeckert werden und dann spätestens auf dem Integrationsserver Alarm auslösen.

Bleibt das Thema, was macht man bei if's mit nur einem Statement. Nach obiger "Lehre" müsste man dann auch die geschwungenen Klammern schreiben. Bei uns im Java-Umfeld sind die Klammern Pflicht. Bei C# verlangt StyleCop die Klammern glaube ich auch (da bin ich mir jetzt aber nicht sooo sicher - kann man ja auch ggf. ausschalten).

Ich pers. finde die Klammern aber an dieser Stelle überflüssig - wenn ich pures C programmiere dann lasse ich die Klammern auch weg - mache dann aber über und unter das if eine Leerzeile, damit das if nicht in der "Code-Suppe" untergeht. Beispiel:


machdies();
holedas();
if (jaja)
  trallalla();
machjenes();

Das geht so gar nicht! Ich schreibe dann:


machdies();
holedas();

if (jaja)
  trallalla();

machjenes();

Dadurch ist der if definitiv hervorgehoben (als "Block" erkennbar durch die Leerzeile über- und unterhalb) und geht beim Lesen m. E. nicht "verloren".

Was wenn man nun eine Anweisung dem if hinzufügen will? Dann ist der "Aufwand" natürlich größer, weil man dann erst einem "umständlich" (puh) die Klammern nachträglich setzten muss. Ich kenne tatsächlich Leute im Bekanntenkreis, die so denken und aus diesem Grund (und zwar nur aus diesem!) auch bei ifs mit nur einer Anweisung immer die geschweiften Klammern setzen.

Andere argumentieren, es ist mit den Klammern konsequenter....

Ein Argument gibt es ggf. noch für die if's ohne Klammerung - es passt halt mehr Code auf den Schirm:


if (jaja) {
  trallalla();
}

if (noe) {
  schwupps();
}

if (vielleicht) {
  kannstmichmal();
}

braucht halt mehr Platz (wenn man auf die Leerzeilen - so wie ich - nicht verzichten will) als


if (jaja)
  trallalla();

if (noe)
  schwupps();

if (vielleicht)
  kannstmichmal();

Sprich, es passt etwas mehr Code ins Editor-Fenster.

Ich denke, es ist fast egal was Du machst.... 😉 Aber selbst wenn Du nur privat entwickelst würde ich Dir auf jeden Fall anraten StyleCop zu verwenden! Damit kannst Du Dir selbst Deine Code-Konventionen aufdrücken/prüfen und so beknackter Code wie ihn beispielsweise unconnected gepostet hat kommt gar nicht erst ins Programm. StyleCop kann man in Grenzen an eigene Konventionen anpassen und auch prima in den Build-Prozess vom Visual Studio einbauen.

Bye,
Michael

P.S.: Grundsätzlich ist es aber eine gute Idee, sich über Code-Konventionen Gedanken zu machen. Denn Code wird viel öfter gelesen als geschrieben - daher muss der Code auf jeden Fall immer verständlich sein/bleiben und nicht nur in den 5 Minuten in denen man den Code runterhackt! 😉

Debuggers don't remove Bugs, they only show them in Slow-Motion.

D
27 Beiträge seit 2009
vor 10 Jahren

Hallo,

bei uns in der Firma haben uns bei C# entschieden die öffene Klammer immmer auf eine neue Zeile zusetzen und das auch bei einzeiligen Blöcken immer Klammern gesetzt werden. Wir waren uns einig, dass das so übersichtlicher und besser lesbar ist.

Da wir auch **Javascript **programmieren, wollten wir auch dort Coderegeln festlegen. Leider sind wir uns in diesem Falle nicht mehr so einig, was die Positionierung der Klammern angeht.
Einige sagen das auch hier die öffene Klammer auf eine neue Zeile gehört, da es eben lesbarer ist. Andere sagen, dass die öffene Klammer nicht auf eine neue Zeile soll, weil das die gängige Konvention in Javascript ist.

Die Frage ist also benutzt man im Team bestimmte Coderegeln, weil Sie einen Vorteil bringen, was Übersicht und Lesbarkeit angehen, dann aber auch sprachübergreifend? Oder benutzt man Regeln weil Sie von einer Mehrheit benutzt werden und somit eine allgemeine Konvention darstellen und das je nach Programmiersprache?

mfg

16.807 Beiträge seit 2008
vor 10 Jahren

Man benutzt i.d.R. die gängigen Konventionen einer Programmiersprache, auch, wenn diese sich im Falle von C# und JavaScript in gewissen Situationen unterscheiden.

5.941 Beiträge seit 2005
vor 10 Jahren

Hallo Tehral

Die Leute bei Micosoft haben sich schon was dabei überlegt, als sie Konventionen aufgestellt haben. Am besten schaust du dort. Auch was andere Fragen in die Richtung angeht.
Tools wie StyleCop oder Resharper unterstützen auch standardmässig die Microsoft Konventionen.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

M
171 Beiträge seit 2012
vor 10 Jahren

Ich könnte jedes mal kot**** wenn ich sowas sehe:


if (x==0)
{
   y = 17;
}

weil ich überflüssigen Noise eben zum kot*** finde, da es den Code aufbläht und somit unleserlich macht. Scheint also wohl Geschmackssache zu sein. O.g. Beispiel fällt für mich in dieselbe Kategorie wie


if(myBoolean == true)

... würg

Hinweis von herbivore vor 10 Jahren

Mehr Informationen dazu gibt es in [Tipp] Anfängerfehler == true / == false, so dass wir diesen Punkt hier nicht weiter behandeln brauchen und sollten.

B
357 Beiträge seit 2010
vor 10 Jahren

Bei einzeiligen if-Blöcken haben wir aus gutem Grund inzwischen die Klammerpflicht eingeführt. Gab da so einen Kollegen, der seine if-Block-Erweiterung einfach druntergehängt hat, ohne dann die Klammer zu setzen. Das Ergebnis war dementsprechend toll und die Fehlersuche war recht anstrengend, weil an so was nun wirklich keiner dachte. Weniger Codezeilen gut und schön, aber solche Fehlersuchen sind die paar Klammerzeilen wirklich nicht wert.

2.078 Beiträge seit 2012
vor 10 Jahren

Ich kann im Großen und Ganzen m.knigge nur zustimmen.

Einen kleinen Unterschied gibt es aber:

if-Statements sind bei mir (fast) immer durch eine Leerzeile vorher und nachher vom restlichen Code hervor gehoben, außer wenn sehr viele if-Statements mit öhnlichem Zweck aufeinander folgen.

So prüfe ich z.B. Übergabeparameter einer Methode immer am Anfang und lasse dann auch mal die Leerzeile zwischen den ifs weg, vor dem ersten if und nach dem Letzten bleibt aber ein Leerzeichen. So springt mir der Block dann direkt ins Auge.

Die Klammersetzung bei Java finde ich persönlich sehr hässlich. Das mag Gewohnheitssache sein, aber ich verliere da irgendwie immer den Überblick, weshalb meine erste Amtshandlung bei der Arbeit mit Java-Code darin besteht, die öffnenden geschweiften Klammern in eine neue Zeile zu setzen.

Klammern bei nur einer Anweisung im if finde ich nun nicht zum kotz***, aber ich finde es unschön. Hauptsächlich, weil der ganze Code dadurch mit viel Luft aufgebläht wird, ohne dass es Vorteile bringt, da ich ifs ja sowieso vom restlichen Code durch Leerzeilen trenne.

Bool auf true oder false zu vergleichen geht aber tatsächlich gar nicht. Das ist so überflüssig wie hässlich und fliegt bei mir gleich raus. 😄

Ich muss dazu aber sagen:

So wie ich das mit ifs handhabe, mache ich es mit fast allem, was einen eigenen Code-Block besitzt. Also Schleifen und usings.
Geschweifte Klammern setze ich dann, wie ich dann schon einmal erwähnte, trotzdem, wenn sich solche Blöcke verschachteln, wobei ich vorher erst einmal schaue, ob ich die Verschachtelung nicht irgendwie umgehen kann, indem ich etwas sinnvoll auslagere. In der Regel kann ich da meistens etwas aus lagern, weshalb das Problem gar nicht mehr da ist.

F
10.010 Beiträge seit 2004
vor 10 Jahren

@Mallett:
Coding Conventions haben nicht nur etwas mit aussehen zu tun, sondern sollen auch dazu dienen Fehler im Ansatz zu vermeiden.
Und wenn du mal so Kollegen wie bredator hattest lernst du das schnell zu schätzen.

Und wer dann Tools wie das AStyler Addin für VS.NET benutzt und da


--style=allman --indent=spaces=4 --indent-classes --indent-switches --indent-cases --indent-namespaces --indent-labels --indent-preprocessor --indent-col1-comments --pad-oper --unpad-paren --break-closing-brackets --add-brackets --mode=cs

Als Optionen setzt kann auch schnell jeglichen Code so haben wie man ihn z.b. StyleCop braucht.
Oder eben so anpassen wie die Firmeneigenen Rules es erwarten.

M
171 Beiträge seit 2012
vor 10 Jahren

StyleCop ist für mich auch nur ein Manntageverbrennungsprogramm. Entwickler, die ein Gespür dafür haben, wie guter und lesbarer Code aussehen muss, brauchen keine Gängelung durch ein Tool, Programmierer, die dieses Gespür nicht haben, finden auch so Wege die Regeln eines Tools auszuhebeln.

Die Illusion, dass alle Entwickler qualitativ gleichwertigen Code produzieren, wenn ein Tool wie Stylecop eingesetzt wird, ist für mich eines der vielen BWL-Märchen, mit denen man über die Jahre so konfrontiert wird.

16.807 Beiträge seit 2008
vor 10 Jahren

FxCop / StyleCop haben zurecht in der .NET Welt ihren Platz gefunden und sollten sinnvoll angewandt werden.

Wir schweifen immer mehr vom eigentlichen Thema ab und befassen uns zu sehr mit eigenen Meinungen, die teilweise sehr sehr vom empfohlenen und erprobten Vorgehen abweichen.

H
523 Beiträge seit 2008
vor 10 Jahren

Die Frage enstand bei mir eigentlich nur, weil ich immer in allen Büchern

void FunktionsName(){  
  
}  

So wird doch standardmäßig in Java formatiert, oder? Die IDE Netbeans macht das jedenfalls so.

2.078 Beiträge seit 2012
vor 10 Jahren

Ich kann es mangels Erfahrung nicht verallgemeinern, aber ich glaube, dass das tatsächlich die empfohlene Formatierung bei Java ist. Bei C++ ist sie glaube auch recht verbreitet, aus C-Zeiten noch, aber sicher bin ich mir da nicht.

Ich weiß nur: Ich hasse sie, diese Art die Klammern zu setzen 😄
Und es wurde ja auch schon erwähnt, dass das für das Gehirn schwerer aufzunehmen ist, als die typische Formatierung bei C#.

3.511 Beiträge seit 2005
vor 10 Jahren

Hallo,

ich beziehe mich immer auf die Style Guidelines der jeweiligen Sprache. Soll heißen unter c#


public void Bla() 
{

}

unter JavaScript


function Bla() {
}

Es ist reine Gewöhnungssache. Wenn ich jemanden JavaScript vorschmeiße, der nie oder selten mit JS arbeitet, wird es schwerer haben zu lesen, wie jemand der täglich mit JS arbeitet. Genauso umgekehrt mit c# oder was weiß ich.

Ansonsten kann ich mich nur Abt und Peter Bucher anschließen.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)