string vs. String - coding style ?

heiho,

wie ihr alle wist ist ja in c# mit dem .net das "string" ein alias zu "System.String"
das selbe mit int zu Int32 usw usf

ich seh sehr oft das es gemischt verwendet wird

also

string bla = String.Empty;

oder

string knack;
String.IsNullOrEmpty(knack);

man kann ja genauso

String bla = String.Empty; 

oder

string bla = string.Empty;

schreiben

zweiteres hab ich ueberall in benutzung - also direkt

 int, uint, bool, string

usw
dadurch wirds aber in meinen methoden recht bunt sag ich mal

public void Bla(string knack, OwnObject fasel)

da waere String allein von der farb gebung doch angenehmer

visual studio fuer sein teil erstellt wenn man ihn dazu auffordert methoden immer mit einem kleinen s fuer string

ich frag mich - was sich bei euch coding style maessig so durchgesetzt hat ?

(wozu gibt es eigentlich das "Void" wo man es gar nicht verwenden darf [compiler heult] ?)

Hallo

Ich konnte mich bisher auch nicht entscheiden, ob ich jetzt immer "string" schreibe, oder für statische Methode davon, die Klassen-Schreibweise.

Also:

string foo = "Peter";
bool bar = String.IsNullOrEmpty(foo);

vs:

string foo = "Peter";
bool bar = string.IsNullOrEmpty(foo);

Es gab aber irgendwo schon mal einen Thread zu diesem Thema, nur finde ich den nicht mehr...

Gruss Peter

Hallo.
Siehe: Unterschied zwischen string und String
Dank der besseren Intellisence-Unterstützung habe ich mich für die in der Sprache C# festgelegte Variante (also kleingeschrieben) entschieden.
Die Methoden sollte ich dennoch besser mit der grossen Variante verwenden, aber eigentlich ist das nur ein theoretisches Problem.

wozu gibt es eigentlich das "Void" wo man es gar nicht verwenden darf [compiler heult] ?

Es ist für die Rückgabewerte der Funktionen gedacht.
Das einzige was man verwenden darf ist typeof(void).
Hab mich auch schon gewundert.

mfg
SeeQuark

Hallo Mr Evil.

ich verwende statt string und object immer die großgeschrieben Klassennamen String und Object (eben weil ich die beiden mehr als Klasse als als Basisdatentyp sehe) und ansonsten immer die kleingeschriebenen Schlüsselworte int, double, ...

herbivore

Hallo,

Ob man in Methoden jetzt string oder String verwendet ist ziemlich egal, solange man Einheitlich bleibt!

Wo es jedoch wichtig und auch von Microsoft "vorgeschrieben" ist: Methoden und Klassennamen. Dort soll man immer den Klassennamen verwenden.
Also "ToString" und nicht "Tostring", "ToInt32" und nicht "Toint".
Richtlinien für die Benennung

Gruß
Juy Juka

Hallo,

ich verwende immer die groß geschriebene Variante, also String, Object, Int32, Double usw..

Es sind ja schließlich Klassen (bzw. Structs) wie alle anderen auch. Warum sollte man also dort Ausnahmen machen nur weil es möglich ist.

Aber im Prinziep gebe ich meinem Vorposter recht, solang man eine Variante konsequent durchzieht ist es gleich.

Schöne Grüße

Ich verwende immer die kleingeschriebene Version, wel ich die schöner finde. Ich finde, das man ein Schlüsselwort auch benutzen soll. Es hat sich bestimmt jemand dabei auch Gedanken gemacht. 😁 Hoffe ich zu mindest. 🤔

Es ist wohl Geschmackssache.

Gruß pdelvo

Ich finde, das man ein Schlüsselwort auch benutzen soll. Es hat sich bestimmt jemand dabei auch Gedanken gemacht. 😁 Hoffe ich zu mindest. 🤔

Ich könnte mir vorstellen, dass die Aliasse in C# eingeführt worden sind weil es diese Schreibweise in vielen anderen Programmiersprachen (C/C++, Java, ...) auch gibt 🙂.

Ich glaube ich benutze meistens die kleingeschriebene Variante. Ganz sicher bin ich mir da nicht, kommt so ein bisschen auf die Gefühlslage drauf an. Ich seh da kein Problem darin das auch innerhalb eines Quelltextes mal so und mal so zu machen.

Hallo onlinegurke,

naja, ein ernsthaftes Problem ist das Mischen innerhalb eines Quelltextes vielleicht nicht, aber anzustreben ist eine Einheitlichkeit schon.

herbivore

Die Coding-Konvention hier:

• bei Deklaration Kleinschreibung
• bei Bezug auf den Typ Großschreibung

private string m_Name;
private List<String> m_NameList;

Kann man meiner Meinung nach halten wie ein Dachdecker, solange man nicht dauernd hin- und herspringt.

LaTino

Ich halte es auch so wie LaTino. Bei Deklaration klein, beim direktem Bezug groß.

string bla = "";
if (String.IsNullOrEmpty(bla))

Ich verwende jeweils die kleingeschriebene Variante der Typen string, int, float, ...
So kenn ich das aus C, wo die primitiven Datentypen auch klein geschrieben sind.
Die Großgeschriebene Variante ist für mich die jeweilige Helferklasse für den primitiven Typ und daher verwende ich für Methoden davon die großgeschriebene Variante.

Also ich mische auf keinen Fall. Da ich aus der "Java-Welt" komme, schreibe ich lediglich Object und String mit großem Anfangsbuchstaben (also .NET-spezifisch) und die primitiven Datentypen (int, double ect.), also C#-spezifisch, bleiben dann wie sie sind. Ist in Java auch so. Was mich ein bißchen aufregt, sind die Generatoren, z.B. bei einer Dictionary<String, String>, dann wird immer = new Dictionary<string, string> in den Quellcode "reingebuttert". 😜

schreibe ich lediglich Object und String mit großem Anfangsbuchstaben (also .NET-spezifisch) und die primitiven Datentypen (int, double ect.), also C#-spezifisch, bleiben dann wie sie sind

Mach ich auch so, mit der Ausnahme statischer Methoden, also Double.Parse, Int32.TryParse.

Mir persönlich ist es absolut egal ob ich (oder jemand) das S im String groß oder klein schreibt. Anders sehe ich die Verwendung von int, long, ulong usw. Dort ist nie ersichtlich (programmiersprache und platformübergreifend), wie groß ein Integer jetzt nun ist (16 Bit oder 32 Bit). Deshalb verwende ich System.Int32, System.Int64 usw.

Ob man in Methoden jetzt :::

Mich würd interessieren, warum dir die Einheitlichkeit an dieser Stelle so wichtig ist. Es ist doch gehupst wie gedupst, was man verwendet.

Bei eigenen Klassennamesgebungen stimm ich dir 100% zu, alleine schon um gleich beim Lesen zu sehen, ob es sich um die Klasse MyThing oder eventuell um eine Variable myThing handelt. Aber bei string stört mich aber in keinster Weise ob ich da string oder String lese. Ist ja eh das Gleiche, und eins nur ein Alias für das Andere.

Ich würde immer string, int, long usw. verwenden. Das hat den Grund, dass String für mich implizieren würde, dass es sich um eine Klasse handelt. Klassen sind Referenztypen string ist aber keiner.

@Jelly
Rein technisch hast du recht allerdings wirkt der Code wesentlich aufgeräumter wenn alles einheitlich ist. Es geht ja eigenltich noch viel weiter. Du solltest ja auch möglichst immer den gleichen Code-Style verwenden damit du dich schneller in z.B. fremden Code zurecht findest. Dazu gehören so Banalitäten wie "wo setze ich die geschweiften Klammern"

void methode(){
}

ist ja auch das Gleiche wie

void methode()
{
}

Trozdem sollte man sich auf eine Variante wegen der besseren Übersicht einigen.

Das mit den geschwieften Klammern seh ich ja noch ein. Dazu gehören ja auch Koneventionen zur Namensnennung von Klassen und Methoden (Dingwörter und Tuwörter). Aber die konsequente Bennnung von string oder String find ich, ehrlich gesagt, persönlich schon etwas zu perfektionistisch. Oder anders ausgedrückt: ich denke nicht, dass irgendjemand einen Code nur dadurch schlechter lesen kann, nur weil nicht durchgängig string oder String genutzt wurde.

Jelly, ein Argument wären die Colorcodes im Visual Studio: klassen türkis, primitives blau. Das scheint mir aber selbst zu weit hergeholt 😉.

LaTino
Substantive und Verben, bitte. Dingwörter und Tuwörter gibt es bis zur Grundschule 😉

@Zebes

string ist ein referenztyp.

@JAck30lena

Hmmm dann sollte doch folgendes gehen

void methode(){
    string s = "bla";
    bearbeiteString(s);

    Assert.That(s, Is.EqualTo("fasel"));
}

void bearbeiteString(string s){
    s = "fasel";
}

Dass mein Assert nun zutrifft wäre mir neu oder sehe ich das falsch? Ich bin mir recht sicher, dass s nach dem Methodenaufruf immer noch "bla" beinhaltet weil es eben kein Referenztyp ist.

Wobei meine vorherige Aussage nicht auf object und Object zutrifft, da sich dort ja alles hinter verbergen kann.

@Jelly

Das mit den geschwieften Klammern seh ich ja noch ein.

Naja ich glaube nicht das der Code dadurch wesentlich unleserlicher wird, aber es ist halt eine Konvention genau wie bei string und String.

schau dir mal den reflector an. string ist eine klasse.
string ist ein referenztyp. das besondere an string ist: es ist immutable.

daher trifft dein assert nicht zu obwohl string ein referenztyp ist.

Ok dann hast du aus technischer Sicht recht. Allerdings aus Anwendersicht bleibt es ein valuetype.

Wieder was dazu gelernt ^^.

Hallo Zebes,

Ich bin mir recht sicher, dass s nach dem Methodenaufruf immer noch "bla" beinhaltet weil es eben kein Referenztyp ist.

Auch mit anderen Klassen wirst Du keine Änderung sehen, wenn Du sie in der Unterfunktion neu erzeugst und ohne ref bzw. out übergeben hast. Genau das machst Du hier nämlich.

Guter Einwand. Lag wohl mit Referenztyp etwas daneben, kann ja mal Passieren. Allerdings verhält sich ein string nicht wie ein typisches Objekt auf das ich Mehtoden anwenden kann halt weil es nicht zu ändern ist.

Naja wie gesagt. Wieder was dazu gelernt.

das selbe verhalten hat auch ein multicastdelegate, der bei events eingesetzt wird.

es verhält sich wie ein typisches objekt, nur das es "Immutable" ist, genauso wie string.

(

Liegt wohl an meinen beiden 6 und 8 jährigen Mädels, mit denen ich vielleicht zuviel pauke 😁 Die wissen noch nicht was ein Verb und Substantiv ist.

Hast natürlich recht 👍

schau dir mal den reflector an. string ist eine klasse.
string ist ein referenztyp. das besondere an string ist: es ist immutable.

daher trifft dein assert nicht zu obwohl string ein referenztyp ist.

reflektor brauchst du dazu nicht - einfach rechtsklick auf string und "Go to definition" - schon hast du die klasse (struktur whatever) vor dir

@Mr Evil
ja, aber nur entweder den objectbrowser oder nur die metainformation, solange es nciht dein eigener code ist. interessant hier ist aber die konkrete implementierung.