Funktion für nur Zahlen und nur Buchstaben

[volkard]

also ob ne funktion 50 denkschmerzen braucht oder 100, ist für mich ein riesenunterschied. und das ist ja nur die einfache, die ich umgestaltet habe. die schlimme mit den 2500 denkschmerzen ist der eigentliche kracher. die habe ich aber nicht umgestaltet, weil das kleine beispiel sogar noch treffender zeigt, was mir am großen nicht gefällt.

Daniel E. schrieb:

Ich weiß gar nicht, was ihr habt, die Funktion ist auch mit dem break und continue doch sofort zu verstehen.

also ob ein radio 100Eu kostet oder das gleiche 200Eu ist für mich ein riesenunterschied und der laden mit 200Eu ist nicht ok. obwohl ich mir beides leisten könnte.
ob ich 45 minuten zur arbeit fahre oder 90 minuten ist für mich ein riesenunterschied, obwohl ich beides könnte.
warum sollte es für mich keinen unterschied machen, wie komplex die funktionen sind, obwohl ich beide verstehen kann? und du mußt zugeben, daß das for-if-break-continue-monster durchaus von inkompetenz zeugt. kein problem, wir machen alle fehler. aber Power Off hat die klappe zu weit aufgerissen und so getan, als sei er so perfekt wie TGGC und leifert dann solche stümperei ab. da stimmt was nicht und sage ihm so lange, daß er mist codet, bis er mal anfängt, über seinen programmierstil nachzudenken.

[--linuxuser--]

@volkrad du hast in dem fall recht deine version der schleife gefaellt mir auch besser obwohl die andere version auch witzig ist!

das zeigt wiedermal: VIELE WEGE FUEREN NACH HINTERKUMPFLING

[Power Off]

volkard schrieb:

aber Power Off hat die klappe zu weit aufgerissen und so getan, als sei er so perfekt wie TGGC

Gar nicht wahr! Du bist doch hier der, der permanent die Klappe aufreisst!

Viele Wege fuehren nach Rom. Du hast echt noch nix gesehen, Junge.

Ich kann's einfach nicht glauben, dass so ein vermeintlich intelligenter Bursche wie Du sich an so einem Firlefanz aufgeilt.

[good ridance]

Power Off dann verlass doch bitte das Forum! Noobs wie dich brauchen wir hier nicht.

[Daniel E.]

Walli schrieb:

Ein while ist hier kürzer, eleganter und erzeugt semantisch identischen Code, also nenn mir einen guten Grund es nicht zu benutzen.

Mag sein, aber Quelltext wird ja ziemlich häufig umgebaut und dann kommen schon mal Konstruktionen dabei raus, die nicht optimal sind. Wenn man auf den ersten Blick ein bessere und äquivalente Zeile einfällt, dann kann man das korrigieren, aber sich nur auf solche Mikrooptimierungen zu konzentrieren, ist auch nicht zielführend. Um bei Volkards Radio-Vergleich zu bleiben: ich fahre nicht von München nach Travemünde um es für 20 Cent billiger zu bekommen.

[Walli]

Daniel E. schrieb:

Walli schrieb:

Ein while ist hier kürzer, eleganter und erzeugt semantisch identischen Code, also nenn mir einen guten Grund es nicht zu benutzen.

Mag sein, aber Quelltext wird ja ziemlich häufig umgebaut und dann kommen schon mal Konstruktionen dabei raus, die nicht optimal sind. Wenn man auf den ersten Blick ein bessere und äquivalente Zeile einfällt, dann kann man das korrigieren, aber sich nur auf solche Mikrooptimierungen zu konzentrieren, ist auch nicht zielführend.

Solche Mikrooptimierungen machen aber oftmals den Unterschied zwischen lesbar und nicht lesbar aus. Nach über einem Jahrzehnt C++ sollte man entweder soviel Erfahrung haben, dass man ein while benutzt wenn es angebracht ist oder weniger rumprollen. Ansonsten ACK: Wenn Code in Entwicklung ist wird manchmal erstmal funktionierender Müll gebaut und später evtl. mal schöner gemacht wenn man es besser weiß.

[Power Off]

Walli schrieb:

Wenn Code in Entwicklung ist wird manchmal erstmal funktionierender Müll gebaut und später evtl. mal schöner gemacht wenn man es besser weiß.

Den letzten Teil nach dem "und" kannste getrost streichen. Niemand hat das Geld, um Code nochmal nachzubearbeiten.

[Walli]

Power Off schrieb:

Walli schrieb:

Wenn Code in Entwicklung ist wird manchmal erstmal funktionierender Müll gebaut und später evtl. mal schöner gemacht wenn man es besser weiß.

Den letzten Teil nach dem "und" kannste getrost streichen. Niemand hat das Geld, um Code nochmal nachzubearbeiten.

Jaja, du bist natürlich der einzige der schon professionell programmiert hat. Code wird nicht nur runtergeschrieben sondern beizeiten auch erweitert und wenn dabei etwas unschönes auffallen sollte bügelt man das bei Gelegenheit gleich aus.

[theoretiker]

In der Praxis gibt es fast nur schlechten Code. Aber trotzdem können wir es doch hier versuchen besser zu machen.

[otze]

Power Off schrieb:

volkard schrieb:

aber Power Off hat die klappe zu weit aufgerissen und so getan, als sei er so perfekt wie TGGC

Gar nicht wahr! Du bist doch hier der, der permanent die Klappe aufreisst!

Viele Wege fuehren nach Rom. Du hast echt noch nix gesehen, Junge.

Ich kann's einfach nicht glauben, dass so ein vermeintlich intelligenter Bursche wie Du sich an so einem Firlefanz aufgeilt.

ich an deiner Stelle würde den Ball ein klein wenig Flacher halten...
volkard ist nicht aus gutem Grund einer der besten Programmierer dieses Boards.

Wir alle wissen, dass solche Schandtaten wie du sie am laufenden band fabrizierst auch im realen Leben vorkommen, aber das rechtfertigt sie noch lange nicht. Wenn ich die Möglichkeit habe, neuen code zu schreiben, dann würd ich nicht freiwillig sone schweinerei fabrizieren, sondern erstmal versuchen, mit dem bestmöglichen sprachlichen mittel die Aufgabe zu lösen. Um deinem nun kommenden Zeitaspektargument entgegenzuwirken: das ist eine Sache der Erfahrung. Ein guter Programmierer unterscheidet sich von einem schlechten dadurch, dass er auf den ersten Blick erkennt, welches Sprachliche mittel an der Stelle am geeignetsten ist, während der schlechte, bzw unerfahrene programmierer verschiedene Szenarien erstmal durchspielen muss. Natürlich gibts noch die Sorte an programmierern, die bewusst die denkbar schlechteste Lösung benutzen, um sie dann vehement entgegen jeder Logik verteidigen...nur, zu welcher Kategorie willst du gehören?

Achja: Firlefanz ist dies garantiert nicht. Code wie du ihn schreibst will ich nicht debuggen, nein ich will ihn mir nichtmal anschauen. Es ist ein unterschied, ob ich sofort erkenne was gemeint ist und den Code nur zu überfliegen brauch um ihn zu verstehen, oder ob ich mir ein Blatt papier rauskramen muss auf dem ich erstmal versuche die code verschlüsselung zu knacken

[--linuxuser--]

aber powerOff ein trost es gibt sogar contest wo man unuebersichtlichen kacke code hacken muss da kannste ja mal mitmachen! *kich*

[Power Off]

--linuxuser-- schrieb:

aber powerOff ein trost es gibt sogar contest wo man unuebersichtlichen kacke code hacken muss da kannste ja mal mitmachen! *kich*

Nee danke, den hab ich schon, wenn ich andere Leute Code warten muss.

Da rotzt man mal schnell was hin, um einem anderen Benutzer zu helfen, und zum Dank kriegt man einen dicken fetten Arschtritt. Ist wie im richtigen Leben.

Das weiss ich auch, dass while() kuerzer als meine for()-Konstruktion ist.

Und dann schreibt man ein paar Zeilen Code, um jemandem zu helfen, und schon stuerzt sich eine ganze Horde Klugscheisser auf einen und behauptet, man waere ein Newbie.

Wenn ihr den Leuten, die ein Problem haben, helfen wuerdet, anstatt nur ueber Loesungen debattieren, die gepostet wuerden, waere das Board mit Sicherheit viel nuetzlicher fuer angehende Programmierer.

Andererseits -- warum soll ich mir jeden Scheissdreck gefallen lassen? (die Endlosschleife von Flamewars. )

[--linuxuser--]

mann tek it esy

[the trolls]

junge wir sind scharf aufs trollen weil das einfach nur spaß macht. nix gegen dich.

[volkard]

Power Off schrieb:

Da rotzt man mal schnell was hin, um einem anderen Benutzer zu helfen, und zum Dank kriegt man einen dicken fetten Arschtritt. Ist wie im richtigen Leben.

ich kenne dein richtiges leben nicht.
ich stieg ein mit

du darfst inzwischen sogar in C kleine funktionen bauen. SCNR

und du hast dich dumm gestellt und im nöchsten hab ich dich wie nen nube behandelt und dann hast du mir unterstellt, ich würde kein c können und es wurde komisch.

Das weiss ich auch, dass while() kuerzer als meine for()-Konstruktion ist.

kürzer wäre egal. leichter zu lesen. was du nicht weißt oder nicht zugibst, ist, daß leicht lesbarer code anzustreben ist.

Und dann schreibt man ein paar Zeilen Code, um jemandem zu helfen, und schon stuerzt sich eine ganze Horde Klugscheisser auf einen und behauptet, man waere ein Newbie.

hast dich so gegeben, indem du eisern behauptetest, daß der code so ok sei.

Wenn ihr den Leuten, die ein Problem haben, helfen wuerdet, anstatt nur ueber Loesungen debattieren, die gepostet wuerden, waere das Board mit Sicherheit viel nuetzlicher fuer angehende Programmierer.

auch während dieses threads hab ich durchaus in anderen threads hilfreiche tips gegeben. und das hier war auch notwendig. ist halt besser, wenn unser programmierernachwuchs gleich erfährt, daß "hauptsache, der compiler frißt es" nucht mehr ein brauchbares motto ist.

Andererseits -- warum soll ich mir jeden Scheissdreck gefallen lassen?

lies einfach ein wenig mit und weise mir schlechten code nach und schau, wie ich reagiere. wahrscheinlich sage ich "ups, hast recht" oder sowas. ich sage aber vermutlich nicht "du magst meinen code nicht? ich geb dir mal nen link auf den standard, wo er erklärt ist".

[Power Off]

volkard schrieb:

du darfst inzwischen sogar in C kleine funktionen bauen. SCNR

und du hast dich dumm gestellt und im nöchsten hab ich dich wie nen nube behandelt und dann hast du mir unterstellt, ich würde kein c können und es wurde komisch.

Ich wusste einfach nicht, was Du meinst. Ich dachte, Du meinst, dass ich Code geschrieben habe, der ueber den Bereich der aktuellen Uebungsaufgaben des OP hinausgeht.

volkard schrieb:

kürzer wäre egal. leichter zu lesen. was du nicht weißt oder nicht zugibst, ist, daß leicht lesbarer code anzustreben ist.

Das ist er sowieso immer. Ich hab halt so viel Erfahrung, dass ich den Code, den ich gepostet habe fuer supereinfach und superleicht zu lesen gehalten habe, deswegen habe ich auch zuerst fast keine Kommentare reingeschrieben, weil der Code so kurz war.

Die readnum() Funktion ist ein Mini-Parser, der Zahlen aus einer Zeile des Eingabestroms filtert.
Ich habe es nur deswegen in eine Funktion gepackt, damit es moeglichst kompakt ist und nicht in X Funktionen aufgesplittet ist.

So einen Programmierstil kann man auch als besonders lesbar betrachten.

volkard schrieb:

hast dich so gegeben, indem du eisern behauptetest, daß der code so ok sei.

Das ist er auch -- fuer mich, und etliche andere, die mit viel schlimmeren Dingen zu tun haben.

Das mit der Vorbildfunktion sehe ich natuerlich ein, aber wenn ich jedesmal 10 mal wuerfeln muss, wenn ich jemanden helfen will, kann ich's auch gleich ganz lassen.

volkard schrieb:

auch während dieses threads hab ich durchaus in anderen threads hilfreiche tips gegeben. und das hier war auch notwendig. ist halt besser, wenn unser programmierernachwuchs gleich erfährt, daß "hauptsache, der compiler frißt es" nucht mehr ein brauchbares motto ist.

Es gibt in der Praxis aber so gut wie gar keinen Code, der irgendeiner Regel gerecht wird. Jeder programmiert am Ende doch nur so, wie er es will.

Frueher dachte ich auch mal so, wie Du, dass es ein hehres Ziel sei, besonders guten und sauberen Code zu schreiben, und dass man das am besten jedem unter die Nase reibt.

Mittlerweile stehe ich auf dem Standpunkt, dass es egal ist, wie jemand programmiert, Hauptsache der Code laeuft. Wenn man will, kann man jeden Code verstehen, auch wenn er nicht im eigenen Stil geschrieben ist.

Das wird vor allem dann wichtig, wenn man fuer eine Firma arbeitet und den Code von anderen Leuten warten muss. Wenn man dann den Code nicht versteht, kann man sich gleich einsargen lassn (natuerlich kommt mit der Zeit auch Erfahrung dazu).

Aber ich geb Dir Recht, dass es gut ist, Anfaengern gleich von Anfang an guten Code beizubringen.

Was guter Code ist, ist aber von Betrachter zu Betrachter unterschiedlich, wie man hier deutlich sehen kann.

volkard schrieb:

lies einfach ein wenig mit und weise mir schlechten code nach und schau, wie ich reagiere. wahrscheinlich sage ich "ups, hast recht" oder sowas. ich sage aber vermutlich nicht "du magst meinen code nicht? ich geb dir mal nen link auf den standard, wo er erklärt ist".

OK!

Da faellt mir auch gleich was ein: In einem anderen Thread hast Du eine Funktion mit

void func() {
}

deklariert. Seit C90 sollte das aber

void func( void ) {
}

heissen.

[volkard]

Power Off schrieb:

Da faellt mir auch gleich was ein: In einem anderen Thread hast Du eine Funktion mit

void func() {
}

deklariert. Seit C90 sollte das aber

void func( void ) {
}

heissen.

jup.
zum beispiel in http://www.c-plusplus.net/forum/viewtopic-var-t-is-121640-and-highlight-is-.html
das liegt daran, daß ich c++ gewohnt bin und dort ist () so definiert, daß keine argumente erlaubt sind, also identisch mit (void). in c++ sollte man kein (void) mehr schreiben.
in c schrieb ich natürlich auch immer (void), wie sich das da gehört. habs einfach vergessen.

[volkard]

Power Off schrieb:

Frueher dachte ich auch mal so, wie Du, dass es ein hehres Ziel sei, besonders guten und sauberen Code zu schreiben, und dass man das am besten jedem unter die Nase reibt.

es geht für dich erstmal darum, daß du auch nach dem schreiben kurz mal drüber nachdenkst und gegebenenfalls was verbesserst. nicht um diesen konkreten code besser zu haben. das wäre zu einfach. es hat dann den zweck, daß du das nächste mal es gleich richtig machst. es geht darum, eine rückkopplung zu haben, die einen dazu führt, daß man immer besser wird. daß man auf anhieb das feinste sprachmittel sieht. daß man auf anhieb die schnellste implemetierung der schleife sieht. daß man auf anhieb den fehler erkennt. kurz: es geht darum, dich ständig zu verbessern und nicht auf lorbeeren auszuruhen.
siehe http://www.c-plusplus.net/forum/viewtopic-var-t-is-121246-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html
klar kann ich sowas mit nur einer hand schreiben und auch fremden code lesen und den fehler auf anhieb sehen. aber ich bin einfach nicht gut genug, muß immer besser werden. nicht nur im verständnis der verrücktesten metaprogrammierungstricks, auch in den grundlagen. und sag nicht, du hättest keine solchen mikro-lücken.

Mittlerweile stehe ich auf dem Standpunkt, dass es egal ist, wie jemand programmiert, Hauptsache der Code laeuft.

komisch. mittlerweile stehe ich niht mehr auf dem standpunkt. wir machen temporal gegenläufige entwicklungen durch.

Aber ich geb Dir Recht, dass es gut ist, Anfaengern gleich von Anfang an guten Code beizubringen.
Was guter Code ist, ist aber von Betrachter zu Betrachter unterschiedlich, wie man hier deutlich sehen kann.

jup. vor 8 jahren hab ich auch manchmal viele funktionen zu einer großen zusammengefaßt, weil die nubes gerne vergessen hatten, was welche funktion macht. naja, das hat aber nix gebracht. die nubes müssen eh lernen, mit vielen funktionen klar zu kommen. und wenn man so leichte sachen wie

bool isDigit(char ch){
   return '0'<=ch && ch<='9';
}

reinschmiert, wird auch keiner meckern. wer schon in der lage ist, sich sowas wie isDigit zu merken, hat mehr spaß dran, damit den mini-parser zu lesen. und wer's noch nicht kann, übt das richtige.

edit: aber da ich auch c++ lehre, muß ich an mich auch andere maßstäbe anlegen, als wenn ich nur c++ benutzen würde. ich muß ja guten gewissens sein, die schüler auf einen weg zu führen, der sie in den folgenden jahren möglichst weit bringt.

[Power Off]

Hier ist mir schon wieder was in Deinem "Anfaenger-Code" aufgefallen:

volkard schrieb:

bool isDigit(char ch){
   return '0'<=ch && ch<='9';
}

1. Den Datentyp "bool" gibt es erst seit C99. Es gibt immer noch viele Compiler, die keinen bool-Typ haben. Also solltest Du zumindest so etwas wie

#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901L
typedef enum { false, true } bool;  /* fuer alte Compiler */
#endif

dazuschreiben. Wenn Dein Anfaenger den Code compilieren will und ein Error wegen "bool" kriegt, kann das ganz schoen frusten.
Deswegen nehme ich in Beispielen immer noch "int" statt "bool". Das muss mir natuerlich niemand nachmachen.

2. Im Gegensatz zu C++ sind in C Zeichenkonstanten vom Typ "int", und nicht "char".

Der Anfaenger nimmt bei Deinem Beispiel an, dass '0' und '9' vom Typ 'char' waeren, weil Du das in den Parameter geschrieben hast.
Dann wundert er sich, wenn Zeichen jenseits der ASCII-Range in switch-Anweisungen nicht mehr funktionieren, die er mittels der C-Standard-Bibliothek eingelesen hat.

3. Boolescher Ausdruck ohne Kennzeichnung

Ein Anfaenger koennte Verstaendnisprobleme kriegen, wenn er den Ausdruck "return '0' <= ch && ch <= '9';" liest.
Daher waere es besser, ueber den Conditional-If-Operator zu zeigen, welche Werte wann zurueckgegeben werden.
Das liest sich auch viel besser, uebrigens.

Daher sollte das Codeschnipsel entweder so:

#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901L
typedef enum { false, true } bool;  /* fuer alte Compiler */
#endif
bool isDigit( int ch ){
   return '0' <= ch && ch <= '9' ? true : false;
}

oder so:

int isDigit( int ch ){
   return '0' <= ch && ch <= '9' ? 1 : 0;
}

aussehen.

[jup]

mit punkt 3 hast du dich endgültig disqualifiziert