Ich wollte mal eure Meinung hören
Ist es so in Ordnung? sollte ich was dran verändern?
Wie kann ich den Code verbessern?

als aller erstes:
'programmWarten' hat in einer Klasse 'Konto' mit Sicherheit nichts zu suchen!

'KontoInfos' ist gernzwertig, aber finde ich ok, auch wenn du wahrscheinlich noch andere Meinungen dazu hören wirst.
(Eine Alternative ist eine freie Funktion, die ein Konto übergeben kriegt und vielleicht einen allgemeinen stream).

Im Konstruktor Initalisierungslisten verwenden.
Und befremdlich finde ich, dass der Default-Konstruktor so konkrete Werte anlegt.

Namenskonventionen nicht einheitlich (einmal (), dann (void), KontoInfos gross, sonst klein)

Woher kennt er string im Header? namespace std global bekannt gemacht?

Gut ist auf jeden Fall, dass die getter const sind.
Edit:
Bzw. doch nicht. Warum getter, wenn die Member alle public sind?
Die sollten (im Zweifel) private sein, dann machen die getter auch wieder Sinn.

struct Konto{
  string bank;
  string inhaber;
  string methode;
  int kto;
  int guthaben;
  Konto(void) : bank("..."), inhaber("..."), methode("..."), kto(12345678), guthaben(123){};
  infos(void) const { 
    cout << bank << endl 
     << kto << endl
     /*... usw ...*/
     << guthaben << endl;
  }
  void warten(void) const { /* ... */ }
};

Hi,

als aller erstes:
'programmWarten' hat in einer Klasse 'Konto' mit Sicherheit nichts zu suchen!

'KontoInfos' ist gernzwertig, aber finde ich ok, auch wenn du wahrscheinlich noch andere Meinungen dazu hören wirst.
(Eine Alternative ist eine freie Funktion, die ein Konto übergeben kriegt und vielleicht einen allgemeinen stream).

Im Konstruktor Initalisierungslisten verwenden.
Und befremdlich finde ich, dass der Default-Konstruktor so konkrete Werte anlegt.

Namenskonventionen nicht einheitlich (einmal (), dann (void), KontoInfos gross, sonst klein)

Woher kennt er string im Header? namespace std global bekannt gemacht?

Gut ist auf jeden Fall, dass die getter const sind.
Edit:
Bzw. doch nicht. Warum getter, wenn die Member alle public sind?
Die sollten (im Zweifel) private sein, dann machen die getter auch wieder Sinn.

Ich habe die Klasse nicht in eine Header Datei geschrieben aber sonst finde ich
deine Kritik gut

(mit aus Bequemlichkeit abgekürzten Bezeichnern)

struct Konto{
  string bank;
  string inhaber;
  string methode;
  int kto;
  int guthaben;
  Konto(void) : bank("..."), inhaber("..."), methode("..."), kto(12345678), guthaben(123){};
  infos(void) const { 
    cout << bank << endl 
     << kto << endl
     /*... usw ...*/
     << guthaben << endl;
  }
  void warten(void) const { /* ... */ }
};

Das ist schwer lesbar

also return guthaben anstatt return this->guthaben

Ich wollte mal eure Meinung hören
Ist es so in Ordnung?

Ich hasse Denglisch. Ich kann es schon nicht ausstehen, wenn jemand deutsche Bezeichner verwendet, aber dann kommst du auch noch mit gemischten Bezeichnern wie getKontonummer(). Wie kann das sauber sein?
Lass das (void) weg, das braucht man in C++ nicht.
Dass Infos irgendwas über cout ausgibt, finde ich schlecht. Kann man zum Test mal machen, aber das hat in so einer Klasse nichts verloren. Logik und Darstellung muss man strikt trennen.

Lass das (void) weg, das braucht man in C++ nicht.

Mit (void) erkennt man auf einen Blick, ob es sich um eine leere Parameterliste oder um einen Funktionsaufruf mit leerer Argumentliste handelt, und das finde ich vorteilhaft. Ist natürlich Geschmacksfrage.

Mechanics schrieb:

Mit (void) erkennt man auf einen Blick, ob es sich um eine leere Parameterliste oder um einen Funktionsaufruf mit leerer Argumentliste handelt

Mach mal ein Beispiel, mir ist spontan nicht ganz klar, wie du das genau meinst.

Da erkennt man aber auch auf einen Blick, dass es sich um eine leere Parameterliste handelt.

Ich mach es zwar mittlerweile auch ohne extra void in der Klammer, da ich möglichst reduzierten (auch optisch) Code bevorzuge (sonst krieg ich Krämpfe im Kopf), finde die Konsistenz aber an sich ganz schnicke.

Addendum:
Im Endeffekt aber wieder völlig nichtiges Thema, hauptsache man macht es konsistent.

wenn ich foo() in meinem Code sehe, sehe ich sofort, daß das keine Deklaration ist, und wenn ich foo(void) sehe, weiß ich sofort das Gegenteil.

Würde ich für beides "foo()" schreiben, dann bräuchte ich Kontext, bspw., was vor dem "foo()" steht - ein Klassenbezeichner, ein Gleichheitszeichen, ein Operator oder was Anderes.
Das wäre mir eine unnötige Einbuße an Codelokalität - und Codelokalität ist mir wichtig

Also bleibt's beim (void).

Namenloser324 schrieb:

Ich mach es zwar mittlerweile auch ohne extra void in der Klammer, da ich möglichst reduzierten (auch optisch) Code bevorzuge (sonst krieg ich Krämpfe im Kopf), finde die Konsistenz aber an sich ganz schnicke.

Addendum:
Im Endeffekt aber wieder völlig nichtiges Thema, hauptsache man macht es konsistent.

nein. sowas nichtiges sollte man schon so machen wie alle anderen.

Ich hasse Denglisch. Ich kann es schon nicht ausstehen, wenn jemand deutsche Bezeichner verwendet, aber dann kommst du auch noch mit gemischten Bezeichnern wie getKontonummer(). Wie kann das sauber sein?

Es ist sauber. Wenn man deutsche Bezeichner nimmt, und dafür gibt es durchaus gute Gründe, dann ist getKotonummer vollkommen ok.

Namenloser324 schrieb:

Namenloser324 schrieb:

Ich mach es zwar mittlerweile auch ohne extra void in der Klammer, da ich möglichst reduzierten (auch optisch) Code bevorzuge (sonst krieg ich Krämpfe im Kopf), finde die Konsistenz aber an sich ganz schnicke.

Addendum:
Im Endeffekt aber wieder völlig nichtiges Thema, hauptsache man macht es konsistent.

nein. sowas nichtiges sollte man schon so machen wie alle anderen.

Hauptsache man macht es konsistent steht da. D.h. arbeitet man in einem Projekt einigt man sich entweder auf eine Variante oder folgt halt der Masse falls du mit deiner Implikation, dass es alle so machen würden, recht hast.
Arbeitet man alleine macht man es halt wie man möchte nur eben konsistent. Seitenweise (Achtung: Übertreibung) drüber zu diskutieren ist halt massive Zeitverschwendung.

volkard schrieb:

Namenloser324 schrieb:

Namenloser324 schrieb:

Ich mach es zwar mittlerweile auch ohne extra void in der Klammer, da ich möglichst reduzierten (auch optisch) Code bevorzuge (sonst krieg ich Krämpfe im Kopf), finde die Konsistenz aber an sich ganz schnicke.

Addendum:
Im Endeffekt aber wieder völlig nichtiges Thema, hauptsache man macht es konsistent.

nein. sowas nichtiges sollte man schon so machen wie alle anderen.

Hauptsache man macht es konsistent steht da. D.h. arbeitet man in einem Projekt einigt man sich entweder auf eine Variante oder folgt halt der Masse falls du mit deiner Implikation, dass es alle so machen würden, recht hast.
Arbeitet man alleine macht man es halt wie man möchte nur eben konsistent.

nein. sowas nichtiges sollte man schon so machen wie alle anderen.

Namenloser324 schrieb:

Seitenweise (Achtung: Übertreibung) drüber zu diskutieren ist halt massive Zeitverschwendung.

Kein Vergleich zur Zeitverschwendung, die dadurch entsteht, daß man sich hier einen unüblichen Stil angewöhnt und jedes Stück Code, was man posten will, vorher bereinigen muss, damit das obligatorische "(void) ist in C++ nicht mehr nötig" nicht kommt. Oder gegen den Effizienzverlust, wenn der unwissende Chef (void) in den Styleguide reinschreibt, und jeder Mitarbeiter tagelang drüber stolpert. Vom künstlich erzeugten Mißmut ganz abzusehen. Außerdem nehme ich die Fragen von (void)-Programmierern nicht so ernst, und das wird sicherlich noch vielen anderen so gehen. Eben weil dieser Punkt nicht andeutungsweise strittig wäre, sondern alle () schreiben.

mit dem Argument, es käme von C, müßte ich ja auch auf struct verzichten, weil es in C++ die Alternative class mit public gibt.

mit dem Argument, es käme von C

Das ist nicht das Argument. Es ist in C genauso unnatürlich wie in C++, aber als Kompromiss wegen der K&R-Kompatibilität nicht zu vermeiden.

//C
void f();
f(42); //kompiliert
void f(void);
f(42); //error: f nimmt 0 parameter

//C++
void f();
f(42); //Error: f nimmt 0 parameter

void muss man in C für eine Funktion ohne Parameter angeben. In C++ ist es sinnloses Rauschen.

Ne, in C ist es sinnvoll.

Ich meinte das vom Sprachdesign her. Dass es das gibt, und dass es in C benutzt werden sollte ist unstrittig.

Code auf das Mininimum zu reduzieren, indem man jegliche Redundanz vermeidet, wäre eine Strategie, um etwa eine Platzierung beim Ioccc zu gewinnen.