Probleme mit Daten die in entsprechende Klassen unter zubringen !

Reverent hat gesagt.:
Dank an euch beiden für eure Antworten,
und cosmo was hat das mit der Collection auf sich, mit der kenne ich mich noch nicht aus und um was neues zulernen wär das ja nicht schlecht. Ich bitte um einen kleinen Überblick.
Working with collections in the .NET Framework
:google: = http://www.codeproject.com/info/sea...it1=Search&author=&sd=11/15/1999&ed=11/9/2005

Reverent hat gesagt.:
Und wo liegt da der Unterschied zu meinem, OK eine Auto hat auch Funktionen, wie z.B. 'Bremsen' und Funktionen kommen in meinen Klassen nicht vor, nur halt die gleichen Variablen.
Der Unterschied lag darin, dass Du alles miteinander vererbt hattest.
In deinem Fall würde sich aber eine abstrakte Basisklasse für "Beschreibung & idBesitzer" anbieten.
Code:
abstract class BaseData{
	protected string sDescription;
	protected string sOwnerID;
}

class csNotitz : BaseData { /*TODO*/ }
MfG, cosmo
 
cosmochaosmaker hat gesagt.:
Bei einem gemeinsamen Projekt werden diese sowieso abgesprochen, dachte ich.
Unter Zeitdruck und bei unterschiedlichen Lokationen der Entwickler findet sich keine Zeit für Styleguide-Absprachen.
cosmochaosmaker hat gesagt.:
Aus dem Link von MS entnehme ich nicht mehr als ich schon weiss.
Ausserdem find ich einige der Vorschläge Intellisense feindlich.
Die da genau wären?
cosmochaosmaker hat gesagt.:
Und wenn ihr euch die Tutorials von TheCodeProject anschaut,
haben die auch dort entweder keinen oder so einen ähnlichen wie ich gepostet hatte.
90% der Tutorials von TheCodeProject zeigen lediglich wie eine bestimmte Sache funktioniert und sind definitiv nicht sauber programmiert - um dies mal festzuhalten. Sich also von dort einen Style abzugucken, sehe ich eher als gefährlich.
cosmochaosmaker hat gesagt.:
Mit dem Syleguide von ic#code macht man sich als Programmierer im Team eher Feinde.Was'n das? :eek:

Oder meintest Du einen anderen?
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?

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.
 
Hallo cosmo,
gute Idee, ich habe noch mal nach gelesen, die CollectionBase ist zum verwalten der erzeugten Objekte, wenn ich das richtig verstanden habe!

Und mit der 'abstract class' könnte ich es dann z.B. so lösen.

Code:
abstract class BaseData{
	protected string sDescription;
	protected string sOwnerID;
}
Code:
class csNotizen : BaseData
Code:
public class csAufgabenErinnerung : BaseData

public DateTime Tag;
Code:
public class csTermine : BaseData

public DateTime Zeit;
public DateTime Tag;
Ich wollte eine seperate Klasse erzeugen die die Einträge im Terminplaner verwaltet.
Bis Dann
 
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. :D
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. :confused:
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: :eek: 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. :D
 
Ein kleiner Auszug. Die wichtigen Passagen wurden fett dargestellt:

Generally the use of underscore characters inside names and naming according to the guidelines for Hungarian notation are considered bad practice.

Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used in early Windows programming, but now is obsolete or at least should be considered deprecated. Using Hungarian notation is not allowed if you follow this guide.

And remember: a good variable name describes the semantic not the type.

An exception to this rule is GUI code. All fields and variable names that contain GUI elements like button should be postfixed with their type name without abbreviations. For example:

Meiner Meinung nach ist es nicht IntelliSense feindlich. Wieso auch? Die wichtige Information befindet sich vorne, hinten dann der Typ. Lange Bezeichnungen haben durchaus einen Vorteil: Auch nach einem halben Jahr weiß man noch, was wo genau enthalten ist. Ausserdem kannst du Intellisense nutzen und musst das ohnehin nicht ausschreiben.

Weiters:
Nehmen wir ein Beispiel.
a) txtName
b) nameTextBox

Eingabe im Visual Studio:

txtNa + [Tab]
na + [Tab]

Wo muss man weniger tippen? Und warum soll ich "txt" eingeben, wenn ich eigentlich nach dem Namensfeld suche?

Wie gesagt, es gibt unterschiedliche Ansätze und jeder hat zu wählen. Aber wie gesagt, ich nehme lieber einen Styleguide, der weitestgehend verwendet wird.

Gewisse Dinge sind einfach eine Unart und haben sich eingebürgert. Deswegen sind sie aber nicht gut bzw. vorteilhaft - genauso wie Klassennamen mit "cs" anzufangen. Wird nirgends so gemacht, einige machen es dennoch so. Das ist übrigens noch ein Kritikpunkt an die obige Klassenstruktur ;-)
 
Zuletzt bearbeitet:
Norbert Eder hat gesagt.:
Wo muss man weniger tippen? Und warum soll ich "txt" eingeben, wenn ich eigentlich nach dem Namensfeld suche?
Das hab ich jetzt verstanden. :)
Ich sehe es ein. :-(
Norbert Eder hat gesagt.:
Gewisse Dinge sind einfach eine Unart und haben sich eingebürgert. Deswegen sind sie aber nicht gut bzw. vorteilhaft - genauso wie Klassennamen mit "cs" anzufangen. Wird nirgends so gemacht, einige machen es dennoch so. Das ist übrigens noch ein Kritikpunkt an die obige Klassenstruktur ;-)
*zustimm* ;-)
 
Gut das wir das HIER Ausdiskutieren,

man hätte auch ein NEUES THEMA dafür aufmachen können, oder IHR unterhaltet euch über irgend einen Messenger. (Das geht SCHNELLER)

Ich möchte hier nämlich nicht über einen Syleguide reden, wenn ich das wollte hätte ich ein THEMA mit der Überschrift ' Syleguide ' erstellt, ODER!

Sonst noch IRGEND welche Anmerkungen zu meinem Problem, sonst frage ich hier mal den Administrator, ob man die Überschreift hier nicht in ' Syleguide ' um ändern könnte und ich versuche es noch mal mit einem neuen THEMA und jetzt möchte ich hier nichts mehr von ' Syleguide ' lesen, können wir uns darauf einigen!
Sonst benutzt bitte den Messenger Link!

Bitte um weitere Stellungnahmen zu meiner überarbeiteten Überlegung !

Bis Dann
 
Deine Angelegenheit wurde ohnehin schon lange geklärt, warum also diese Aufregung? Wie gesagt (auch in einer meiner letzten Posts angemerkt), das "cs" vor deinen Klassennamen solltest du noch entfernen, dann passts.

Und zum Thema Styleguide: sei froh, lernst noch was.
 
Zurück