Counter in C#
- Ersteller paulpils
- Erstellt am
Public int Richtige = 0;
Public int Insgesamt = 0;
.
.
.
if (true) then {
Richtige++;
}
else {
...
}
Insgesamt++;
.
.
.
Wichtig ist sie Global zu deklarieren, da du sie wahrscheinlich in mehreren Methoden brauchst...
das ++ zählt eins dazu, alternativ kann man auch:
Richtige = Richtige + 1;
Danach einfach noch irgendwie diese Variablen ausgeben.
Public int Insgesamt = 0;
.
.
.
if (true) then {
Richtige++;
}
else {
...
}
Insgesamt++;
.
.
.
Wichtig ist sie Global zu deklarieren, da du sie wahrscheinlich in mehreren Methoden brauchst...
das ++ zählt eins dazu, alternativ kann man auch:
Richtige = Richtige + 1;
Danach einfach noch irgendwie diese Variablen ausgeben.
SoDaTierchen
Commodore
- Registriert
- Feb. 2011
- Beiträge
- 4.472
Mit was willst du anzeigen? Console? WinForms? WPF? 3D?
Ansonsten: Zählervariable vom Typ Integer nach jeder richtigen Frage hochzählen lassen, anschließend auf dem Bildschirm ausgeben. Welcher Teil ist unklar?
Ansonsten: Zählervariable vom Typ Integer nach jeder richtigen Frage hochzählen lassen, anschließend auf dem Bildschirm ausgeben. Welcher Teil ist unklar?
@SoDaTierchen mit console. Unklar ist was ich für einen code eingeben muss, da ich erst seit kurzem programmiere und mich noch nicht so gut auskenne.
Also ich habs so eingegeben aber es funktioniert nicht.
Es steht da das nach der Zahle mit richtig++ ein } erwartet wird obwohl da eins ist und dass in den letzten beiden Zeilen ein Syntaxfehler ";"
Ergänzung ()
Also ich habs so eingegeben aber es funktioniert nicht.
PHP:
int richtig = 0;
int falsch = 0;
...
if (true) then;
{
richtig++;
}
else
{
falsch++;
}
...
Console.WriteLine("Du hast " +richtig " Fragen richtig beantwortet");
Console.WriteLine("Du hast " +falsch " Fragen falsch beantwortet");
Ergänzung ()
Es steht da das nach der Zahle mit richtig++ ein } erwartet wird obwohl da eins ist und dass in den letzten beiden Zeilen ein Syntaxfehler ";"
The Ripper
Lt. Commander
- Registriert
- Juni 2012
- Beiträge
- 1.969
schau dir bitte bevor du hier weitermachst die ersten paar Seiten in einem C# Tutorial an 
Drexel
Lt. Commander
- Registriert
- Jan. 2012
- Beiträge
- 1.612
paulpils schrieb:
So sollte es richtig sein. If then gibts nur in Visual Basic und das Semikolon benutzt man nur zum abschließen von Befehlen.
Die Verkettung der Strings war auch nicht richtig. Oder Du machst es direkt richtig C# style mit String.Format.
I'm unknown
Rear Admiral
- Registriert
- Feb. 2005
- Beiträge
- 5.500
Man sollte das tatsächlich nur auf erforderliche Dinge eingrenzen. Es gibt allerdings diverse Anwendungsfälle in der Globale Variablen auch in einer objektorientierten Programmiersprache sinnvoll sind.Precide schrieb:
The Ripper
Lt. Commander
- Registriert
- Juni 2012
- Beiträge
- 1.969
Bitte untermauere deine Behauptung mit Begründung und Beispiel.
andy_m4
Vice Admiral
- Registriert
- Aug. 2015
- Beiträge
- 7.010
Ich finde ja die Unterscheidung zwischen globalen und lokalen Variablen etwas .... schwierig. Nicht differenziert genug. Weil es gibt noch jede Menge Abstufungen dazwischen. Man denke nur an Attribute von Objekten. Das sind ja weder globale Variablen (worldwide-visible) noch wirklich lokal. Eher sowas wie globale Objektvariablen (weshalb das auch nicht unumstritten ist, weils gegen die Regel verstößt so lokal wie möglich zu bleiben).The Ripper schrieb:
Andererseits hast Du auch andere Platzhalter für Daten die global zugänglich sind. Ich denke da nur an Dateien. Gut, sind jetzt keine Variablen im herkömmlich gemeinten Sinne. Aber eine Möglichkeit einen Zustand global zugänglich zu speichern und warum sollte man sie dann anders behandeln als Variablen im umgangssprachlichen Sinne.
Aber um auf Deine konkrete Frage zurückzukommen, besonders in kurzen Skripten verwendet man gerne globale Variablen. Weils einfacher ist und vom Aufwand nicht gerechtfertigt ist das extra zu kapseln und weil aufgrund der Kürze kaum echter Bedarf besteht. Der Code ist halt übersichtlich genug, als das einen da globale Variablen vor Probleme stellt (und das ist ja das Ziel von möglichst weitgehender Lokalität; Probleme zu vermeiden; insofern ist das kein Selbstzweck).
The Ripper
Lt. Commander
- Registriert
- Juni 2012
- Beiträge
- 1.969
global -> kannst du überall darauf zugreifen
Zwischen global und nicht global existiert eine ziemlich strikte Trennung.
Inwiefern sind Properties umstritten?
Umstritten mag das vielleicht sein, wenn nur eine Methode eine Abhängigkeit braucht, von der man ausgeht, dass der Aufrufer diese zur Verfügung stellen könnte.
Und sonst?
Im Gegenteiligen Fall, oder den Fällen, dass semantisch ein Parameter übergeben wird oder, dass mehrere Methoden der Klasse semantisch auf die selbe Abhängigkeit zugreifen müssen, ist es ziemlich eindeutig.
Auf Dateien global zuzugreifen ist sowieso i.d.R. ein Antipattern.
Objektorientierte Programmierung in C# ist unpassenderweise alles andere als ein kurzes Script.
andy_m4
Vice Admiral
- Registriert
- Aug. 2015
- Beiträge
- 7.010
Hast Du verstanden, was ich geschrieben hab? Falls ja, warum beziehst Du Dich nicht darauf. Falls nein, warum fragst Du nicht nach sondern ignorierst es?The Ripper schrieb:
Sorry falls das jetzt etwas fies klingt, aber ich hab das Gefühl wir reden aneinander vorbei. Und das bringt keinem was. Also lieber klären.
Schrieb ich doch: Weil die die Regel verletzt, so lokal wie möglich zu deklarieren.The Ripper schrieb:
Ich fühle mich gerade etwas verschaukelt.
Ich versuche es mal mit einem konkreten Beispiel zu veranschaulichen:
Code:
class Person { String name; String firstname;
//
public String getName() { this.name; }
public String getFirstname() { this.firstname; }
//
}Die Feinheiten (das man getter bei C# z.B. weglassen (besser gesagt implizit erzeugen lassen) kann) übersehen wir mal einfach, weil das für das was gesagt wegen soll nebensächlich ist.
Die Instanzvariablen name und firstname sind im gesamten Objekt sichtbar. Es hindert mich also keiner daran, in der Methode getFirstname auf this.name zuzugreifen oder sowas.
Sie sind zwar gekapselt durch das Objekt. Aber innerhalb des Objektes von überall her zugreifbar.
Man kann sagen, die Instanzvariablen sind objekt-global.
Du hast also innerhalb eines Objektes genau die gleichen Probleme mit diesen globalen Variablen wie Du sie auch mit echten (program-wide-accessible) globalen Variablen hast. Nur eben aufs Objekt beschränkt. Dadurch ist es übersichtlicher bzw. Du hast den Bereich eingegrenzt, in dem das für Probleme sorgen kann. Das hilft natürlich schon weiter aber beseitigt die Problematik nicht vollends.
Und das ist der Knackpunkt. Nichtsdestotrotz kann das natürlich ein Kompromiss sein mit dem man gut Leben kann. Heißt aber eben nicht, dass das Problemfeld durch OOP völlig aus der Welt ist.
Wieder beschleicht mich das Gefühl, Du hast nicht verstanden worum es ging.The Ripper schrieb:
Deshalb versuche ich es noch mal mit anderen Worten zu erklären.
Dateien kann man auch irgendwie als globale Variable betrachten. Denn überall im Programm, wo Du Dateioperationen zur Verfügung hast steht es Dir natürlich frei irgendwie ne bestimmte Datei zu öffnen/lesen/schreiben/whatever.
Und das sogar klassenübergreifend. Und unabhängig von irgendwelchen private-Deklarationen die Dir da überhaupt nix helfen.
Und erstmal besteht kein wirklicher Grund Datenbehälter wie Variablen anders zu behandeln als Datenbehälter wie Dateien. Das eine liegt im RAM das andere auf Disk. Das wars denn aber auch schon mit den Unterschieden.
Und eigentlich gibts ja keinen Grund, weshalb z.B. eine Konfigurationsdatei von anderen Stellen im Programm lesbar sein sollte außer eben von der Funktion die die Konfigurationsdatei einliest und in eine interne datenstruktur überführt (und dann von mir aus noch ne weitere Funktion die die Konfiguration speichert).
Klar kann man jetzt lapidar sagen, dass man das ja auch nicht macht. Aber ein expliziten Schutz dafür gibt es auch nicht. Den hat man nur bei Variablen. Und nachvollziehbar ist es nicht: Warum das bei Variablen gut ist und bei Dateien (oder anderen alternativen Datenbehältern) eben nicht.
Es gibt aber noch andere sogenannte objektorientierte Sprachen als C#The Ripper schrieb:
Ich denk da z.B. an Sprachen wie Python oder Ruby deren Anwendungszweck u.a. auch kurze Skripte sind. Sozusagen als Drop-in-replacement für klassische Batchdateien oder Bash-Skripte etc (nur um den Eindruck vorzubeugen, es ging hier um irgendwelche konstruierten Szenarien).
The Ripper
Lt. Commander
- Registriert
- Juni 2012
- Beiträge
- 1.969
Ja, aber der Bereich ist soweit begrenzt, dass genug da ist, um die Aufgabe der Klasse zu erfüllen.
Ich bin mir nicht sicher, aber agumentierst du eigentlich gegen OOP an sich? Wenn nicht, wie soll das denn in deinem Beispiel gelöst sein, dass man keine lokalen Variablen hat? Dann landet man im Endeffekt bei prozeduralen Code.
Die Dateien sind nämlich im Rahmen der OOP so lokal wie möglich, und so "global" wie nötig.
Sind dann Funktionsparameter auch globale Variablen? Kannst du ja in der ganzen Funktion global benutzen. Ich verstehe nicht ganz wo du hinauswillst. Funktionale Programmierung?
andy_m4
Vice Admiral
- Registriert
- Aug. 2015
- Beiträge
- 7.010
Ich will auf gar nix hinaus. Globale Variablen werden kritisiert und das durchaus zu Recht. Ich wollte nur damit sagen, dass man durchaus immer noch viel mit globalen Variablen zu kämpfen hat.The Ripper schrieb:
Das muss jetzt nicht zwingend ein riesen Problem sein. Aber man sollte sich darüber im Klaren sein. Damit man halt nicht dem Trugschluss verfällt: Nu hab ich keine (Programm-)globalen Variablen mehr und automatisch damit alle damit im Zusammenhang stehenden Probleme gelöst.
Ja. Der Bereich ist begrenzt. Das hatte ich ja so auch gesagt. Nichtsdestotrotz hast Du natürlich noch Freuräume sprich Bereiche, wo Du auf solche Variablen zugreifen kannst, ohne das dies notwendig ist.The Ripper schrieb:
Und genau das will man ja eigentlich nicht.
Wie gesagt. Muss nicht zwingend ein riesen Problem darstellen, aber man hat es nun mal. Ich benenne es lediglich. Muss man nicht gleich als böse Kritik verstehen.
Nein. Aber wenn Du es schon mal ansprichst: Wenn es eines grundsätzlich zu kritisieren gäbe, dass OOP omnipräsent ist. OOP hat zweifelsohne seine Berechtigung. Nur hat es in gewissen AUfgabenbereiche seine Vorteile. In Anderen wiederum Nachteile. Und man hat irgendwie den Trend in den letzten Jahren (oder Jahrzehnten) gehabt alles irgendwie mit OOP zu lösen. Das drückt sich ja auch in Sprachen dieser Zeit, wie Java, aus. Wo es de-facto gar keine andere Möglichkeit mehr gibt als sein Programm irgendwie in ein OOP-Korsett zu zwängen.The Ripper schrieb:
Das muss den Erfolg kein Abbruch tun. Und beschränkte Mittel führen ja auch zu einer übersichtlichen Sprache. Muss aber trotzdem nicht immer sinnvoll sein.
The Ripper schrieb:
Wie gesagt. Dateien sind überall dort zugreifbar, wo Du Dateioperationen hast (also i.d.R. überall).
Es geht nicht um keine lokalen Variablen, sonderum so lokal wie möglich.The Ripper schrieb:
Na sie sind Funktions-global, wenn man so will. Da sie üblicherweise in der gesamten Funktion zur Verfügung stehen.The Ripper schrieb:
Eigentlich weniger. Aber wenn Du es schon ansprichst, kann ich ja auch ein zwei Sätze dazu sagen.The Ripper schrieb:
In funktionaler Programmierung hat man natürlich ähnliche Probleme mit globalen Variablen. Das wird aber dadurch entscheidend entschärft, dass Variablen dort typischerweise selten zum Einsatz kommen, sondern eher Konstanten. Sozusagen read-only-Variablen. Womit Du schon mal nicht das Problem hast, dass ein shared-state geändert werden kann.
