Guten Morgen!
Norbert Eder hat gesagt.:
Cosmo, sei nicht gleich sauer, weil einer deiner Ratschläge etwas kritisiert wurde. Schau dir die Dinge einfach einmal an, ohne sie deinerseits zu kritisieren. Denk drüber nach, schlaf eine Nacht und urteile dann.
Bin net sauer, meine Stacheln waren diesmal noch angelegt.
Mal im Ernst, ich hab nichts gegen das Pascal Casing, das verwende ich ja auch.
Norbert Eder hat gesagt.:
Ich meine genau diesen. Nun, dieser Styleguide wird z.B. bei der Entwicklung von SharpDevelop, MonoDevelop und einigen anderen großen Projekten eingesetzt. Was ist daran also team-feindlich?
Code:
System.Windows.Forms.Button cancelButton;
System.Windows.Forms.TextBox nameTextBox;
So hab ich mal angefangen und ich glaube echt nicht das das der Styleguide für so ein Projekt sein soll.
Ich würd ne Meise bekommen wenn ich andauernd die überlangen Namen reinziehen müsste, ergo auch Intellisensefeindlich.
Hinter die hier geprädigte typisierung muss Ja noch ein verbaler Bezeichener hinter.
Ich unterscheide zwischen der Benennung privater/geschützter/lokaler und öffentlichen Membern.
Ersteres benenne ich Typorientiert und zweites nach aussen hin verbal mit Pascal Casing.
So wie die Objekte im Framework halt gestaltet sind.
Um den Intellisense noch besser ausreitzen zu können,
unterscheide ich innerhalb extra zwischen Membern (m_) und Werttypen (v_).
Das TypKürzel bringt dann noch schneller zum Ziel.
Ich find das 100 mal übersichtlicher als das oben gezeigte Camel Casing.
So bekomm ich gleich 3 Infos auf einem Blick.
Das Camel Casing verwende ich sowieso nur innerhalb,
sofern die Klasse diesen Typ nur einmal anbietet,
ansonsten halt [post=1069488]abgekürzt[/post]. So hab ich das gemeint.
Mal ne frage, setzt Du das Camel Casing strikt durch bzw schreibst den Typ immer aus?
Blähen sich nicht die genzen Namen dadurch auf oder muss man das in Kauf nehmen
wenn man im Team Arbeitet?
Mir wurde von dem Wirtschaftsinformatiker der mir die Grundlagen zu c# vermittelt hat gesagt,
ich solle die TypNamen innerhalb abkürzen.
Das war auch noch nie Problematisch, da ich bisher nie mit jemand gemeinsam an einer Klasse garbeitet habe,
sondern wir sie und bisher immer nur zugereicht haben.
Geht es denen jetzt um die Wartbarkeit? Das ein nachfolgender Progammierer die Bezeichner versteht?
Warum schreiben die den Typ dahinter?
@Reverent:
Ließt Du überhaupt mit?
Norbert Eder hat gesagt.:
Weiters: Keine Membervariablen öffentlich zugänglich machen. Immer Properties (Getter/Setter unter Java) verwenden. Cosmo hats dir eh ganz nett vorgemacht,
Beitrag überarbeiten, hopp hopp.