Funktion für nur Zahlen und nur Buchstaben

Power Off

Walli schrieb:

Du sagst ja selbst, dass du schon einige Zeit dabei bist. Scheinbar bist du damals sofort in die Zeitdruck-Programmierung eingestiegen während andere hier auch ab und an mal ein paar Momente zum rumbasteln hatten. Anders kann ich mir nämlich nicht erklären wieso dir bei einem Problem nicht intuitiv die passende Schleife einfällt. Ich mache es immer in der Reihenfolge "denken -> tippen", was sich bisher immer als relativ praktisch erwiesen hat. Bei komplexeren Sachen kritzelt man sich dann halt kurz ein Diagramm und denkt mal ein paar Sekunden nach wie man das Problem geeignet strukturieren kann. Das ist vorher ein kleiner Mehraufwand der meiner Erfahrung nach im Endeffekt unheimlich viel Zeit spart.

Ist ja schoen, dass Du while-Schleifen so cool findest, aber mir gefallen halt for-Schleifen besser.

Was der "richtige Schleifentyp" ist, liegt im Ermessensspielraum des Programmierers, wuerde ich sagen.

Und: Es gibt beim Programmieren durchaus Situationen, in denen man gar keine Zeit zum Denken hat. Toll, wenn Du das Problem noch nicht hattest.

Ich denke beim Programmieren schon lange nicht mehr bewusst nach. Geht alles vollautomatisch.

Diagramme! Du bist echt lustig, Mann!

--linuxuser--

Power Off schrieb:

Ich denke beim Programmieren schon lange nicht mehr bewusst nach.

*kich*

Ich denke beim Programmieren schon lange nicht mehr bewusst nach.

Unmöglich.

Walli

Power Off schrieb:

Ist ja schoen, dass Du while-Schleifen so cool findest, aber mir gefallen halt for-Schleifen besser.

Schön! Warum benutzt du eigentlich eine Hochsprache wenn die so viele unnütze Konstukte bietet?

Power Off schrieb:

Und: Es gibt beim Programmieren durchaus Situationen, in denen man gar keine Zeit zum Denken hat.

Ich möchte nicht deine Software benutzen müssen.

Power Off schrieb:

Diagramme! Du bist echt lustig, Mann!

Ich meine nicht so einen "UML-von-vorne-bis-hinten-Quatsch" wie er einem an der Uni immer als gängige Praxis eingeredet wird sondern simple Skizzen auf Papier. Wenn du die nicht brauchst... schön. Aber du denkst ja sowieso nicht beim programmieren, warum also Gedankenstützen auf Papier? Und sowieso: Du hast ja so wenig Zeit, dass du zu jeder Tages- und Nachtzeit innerhalb von wenigen Minuten auf neue Beiträge reagieren kannst . Langsam wird es echt lächerlich mit dir.

Power Off

Walli schrieb:

Ich meine nicht so einen "UML-von-vorne-bis-hinten-Quatsch" wie er einem an der Uni immer als gängige Praxis eingeredet wird sondern simple Skizzen auf Papier. Wenn du die nicht brauchst... schön. Aber du denkst ja sowieso nicht beim programmieren, warum also Gedankenstützen auf Papier? Und sowieso: Du hast ja so wenig Zeit, dass du zu jeder Tages- und Nachtzeit innerhalb von wenigen Minuten auf neue Beiträge reagieren kannst . Langsam wird es echt lächerlich mit dir.

Wenn ich zur Zeit einen Job haette, wuerde ich mit Sicherheit kaum hier posten ... dann haette ich keine Zeit mehr.

Kommst Du Dir nicht megatoll vor, mit Deinen Vorurteilen?

Power Off

impossible schrieb:

Ich denke beim Programmieren schon lange nicht mehr bewusst nach.

Unmöglich.

Alles ist unmoeglich, solange wie man nicht damit konfrontiert wird.

Ich hatte zwei megastressige Arbeitsverhaeltnisse in den letzten 9 Jahren.

Mit der Zeit geht einem alles in Fleisch und Blut ueber -- wie Autofahren.

Aber sei echt froh, wenn's bei Dir noch nicht so schlimm ist.

MFK

Power Off schrieb:

Ist ja schoen, dass Du while-Schleifen so cool findest, aber mir gefallen halt for-Schleifen besser.

Er findet while-Schleifen nicht "cool". Der einzige, der Sprachmittel unabhängig von Sinn und Zweck betrachtet, bist du.

Power Off schrieb:

Ich denke beim Programmieren schon lange nicht mehr bewusst nach. Geht alles vollautomatisch.

Man kann deinem Code ansehen, dass er ohne bewusste Hirntätigkeit entstanden ist.

Power Off schrieb:

Mit der Zeit geht einem alles in Fleisch und Blut ueber -- wie Autofahren.

Jetzt will ich nicht nur mit deinem Code nichts zu tun haben, ich will dir auch nicht auf der Straße begegnen.

Wenigestens bist du konsequent. Dein Code passt zu deinem Auftreten.

Power Off

MFK schrieb:

Man kann deinem Code ansehen, dass er ohne bewusste Hirntätigkeit entstanden ist.

Ich fasse das Kompliment auf! Danke!

Nee, im Ernst, es hat Vor- und Nachteile. Nachteil ist: Wenn mir nix einfaellt, hab ich ein Problem. Vorteil ist: Nahezu fehlerfreie Software ohne nachzudenken hinzubekommen kann nicht jeder.

Meine ehem. Arbeitgeber haben sich regelmaessig darauf verlassen, dass ich immer sofort eine Loesung fuer auch noch so komplexe Probleme gefunden habe. Einmal hab ich z.B. ein Projekt realisiert, bei dem vorher ein Gutachten gemacht worden war, dass es technisch unmoeglich sei. Mein Chef sagte mir das, und fragte mich, ob ich es machen wolle. Und ich sagte ja, und dann machte ich es. Der Kunde war sehr zufrieden mit dem Endprodukt.

In der betreffenden Firma machte ich immer die Sachen, die niemand anders machen wollte oder konnte.

Ich bin sozusagen einer der Muellmaenner der Softwareindustrie! Ich mach alles!

MFK

Power Off schrieb:

Nee, im Ernst, es hat Vor- und Nachteile. Nachteil ist: Wenn mir nix einfaellt, hab ich ein Problem. Vorteil ist: Nahezu fehlerfreie Software ohne nachzudenken hinzubekommen kann nicht jeder.

Wenn das für dich so passt, ist das in Ordnung. Aber dann würde ich dich bitten, darauf zu verzichten, den Anfängern hier solchen Code als Lösung oder Beispiel anzubieten. Ich finde, dass du damit eine Menge Schaden anrichtest. Geh einfach mal davon aus, dass der überwiegende Teil der Leute, die hier Fragen stellen, nicht so begnadet ist wie du (nicht ironisch), und deshalb mit solchem Code nicht klarkommt.

Power Off schrieb:

Nee, im Ernst, es hat Vor- und Nachteile. Nachteil ist: Wenn mir nix einfaellt, hab ich ein Problem. Vorteil ist: Nahezu fehlerfreie Software ohne nachzudenken hinzubekommen kann nicht jeder.

programmieren ohne nachzudenken hat nachteile: dein code ist kacke. außerdem geht das natürlich nur in domänen, wo du zu hause bist.
vorteile: keine.
natürlich kann ich auch in etlichen domänen code einfach so runterschreiben und bis auf ein paar tippfehler, die der compiler schnell sieht (vor allem retrun statt return), ist der code clean. nur ich schaue immer danach nochmal drüber, ob es was zu verbessern gibt. und meistens ist da nix mehr, weil ich auch auf anheb den weg einschalge, wo es nix mehr zu verbessern gibt.
zeitersparnis sehe ich bei deinem code nicht, denn ich lese code mindestens 20-mal häufiger, als ich ihn schreibe. also muß nur das lesen optimiert werden. selbst wenn ich vor so einer funktion eine sekunde pausieren würde, um nachzudenken, welche schleife paßt und danach nochmal 2 sekunden, um zu schauen, ob es sich hübsch anfühlt, hab ich die 3 sekunden doch schon ganz bald wieder drin, sobald ich den ersten fehler suche und anläßlich dessen den code mehrmals lese.
gerade bei arbeitgebern wie du sie beschreibst, die ganz mächtig zeitdruck machen und auch nicht gestatten, daß man nachher noch ein wenig pflegt, ist die große kathastrophe doch immer dann, wenn der kunde nach 2 jahren noch ein feature dazu will. dreht man hier was, reißt woanders ein bug auf und die sucherei geht los.

Power Off

volkardus schrieb:

natürlich kann ich auch in etlichen domänen code einfach so runterschreiben und bis auf ein paar tippfehler, die der compiler schnell sieht (vor allem retrun statt return), ist der code clean. nur ich schaue immer danach nochmal drüber, ob es was zu verbessern gibt. und meistens ist da nix mehr, weil ich auch auf anheb den weg einschalge, wo es nix mehr zu verbessern gibt.

Das ist bei mir genauso.

(bleibende Tippfehler mach allerdings auch sehr wenige, da ich beim Schreiben den Blick immer auf dem Cursor habe und meist sofort korrigiere, wenn ich es sehe; allerdings mach ich als weniger offensichtliche Tippfehler, z.B. "==" statt "!=" usw., oder falsche Bezeichner, aber die find ich immer beim nochmal durchlesen, compilieren oder testen)

Die Methode, den Code solange zu durchzulesen, bis man davon ueberzeugt ist, ist gut. Meist werfe ich den Compiler nicht eher an, bis ein Modul testbereit ist.

volkardus schrieb:

gerade bei arbeitgebern wie du sie beschreibst, die ganz mächtig zeitdruck machen und auch nicht gestatten, daß man nachher noch ein wenig pflegt, ist die große kathastrophe doch immer dann, wenn der kunde nach 2 jahren noch ein feature dazu will. dreht man hier was, reißt woanders ein bug auf und die sucherei geht los.

Ich schreibe die Programme meist von vornherein so, dass man sie erweitern kann, und dass durch eine Aenderung nirgendwo "bugs aufreissen" koennen.

Es gibt ein paar einfache Techniken, z.B. Black-Boxing (aber auch White-Boxing), mit denen man solche Probleme vermeiden kann.

Jede Funktion hat eine klare Aufgabe und eine klare Schnittstelle. Klassen z.B. duerfen keine nicht-hierarchischen Abhaengigkeiten haben.

Code muss geordnet sein wie eine Julia-Menge, z.B.: man kann rein- und rauszoomen, aber die Zusammenhaenge sind stets klar.

--linuxuser--

Power Off schrieb:

Wenn ich zur Zeit einen Job haette

kann das mit deinem kacke code zusammenhaengen?

Power Off

MFK schrieb:

Aber dann würde ich dich bitten, darauf zu verzichten, den Anfängern hier solchen Code als Lösung oder Beispiel anzubieten. Ich finde, dass du damit eine Menge Schaden anrichtest.

Meinst Du nicht, dass Du ein wenig uebertreibst?

Mit "solcher Code" bezieht Du Dich auf folgende gueltige C Konstruktion:

for(;;) {
   if ( /* Wiederholbedingung */ ) continue;
   if ( /* Abbruchbedingung */ ) break;
}

Dies ist ein gaengiges Konstrukt. Ich nehme es immer, wenn die Abbruchbedingung zu Beginn unklar ist. Dann kann ich spaeter nach Belieben Abbruch- oder Wiederholbedingungen eingeben.

Man kann auch "goto" dafuer verwenden, aber ich finde "for" dafuer bequemer.

Jeder Anfaenger wird frueher oder spaeter sowas lesen muessen, da wird er nicht drum rum kommen.

Und meine readnum() Funktion is auch sehr leicht zu lesen.

Als ich C Anfaenger war, vor 19 Jahren, hab ich ja schon sowas lesen koennen (aber da konnte ich schon BASIC und Assembler).

Irgendwie hab ich das Gefuehl, ihr wollt mich bloss verscheissern.

Power Off

--linuxuser-- schrieb:

kann das mit deinem (...) code zusammenhaengen?

Nein. Ich hatte bloss bei meinem letzten Arbeitgeber zuviel Stress, und hab selber gekuendigt, weil ich nicht mehr arbeiten konnte. Jetzt nach 2-3 Monaten kann ich wieder ein bisschen programmieren.

Ich wuensch Dir das auch mal.

MFK

Power Off schrieb:

Meinst Du nicht, dass Du ein wenig uebertreibst?

Nein. Du solltst doch bemerkt haben, dass eine große Anzahl qualifizierter Boardbenutzer deinen Stil furchtbar bis entsetzlich findet.

Mit "solcher Code" bezieht Du Dich auf folgende gueltige C Konstruktion:

Es geht hier nicht um gültig, es geht um Stil. Mag sein, dass das für dich persönlich nicht relevant ist. Gegenüber denen, die sich an so etwas stören, verhältst du dich aber äußerst rücksichtslos.

Jeder Anfaenger wird frueher oder spaeter sowas lesen muessen, da wird er nicht drum rum kommen.

Anfängern geht es hier aber selten darum, Code zu lesen. Die wollen schreiben, und du lieferst stilistisch schlechte Beispiele. Das muss nicht sein.

Als ich C Anfaenger war, vor 19 Jahren, hab ich ja schon sowas lesen koennen (aber da konnte ich schon BASIC und Assembler).

Wie gesagt, schön, das du so begabt bist, aber viele, die hier Fragen stellen, sind es nun mal nicht. Und darauf nimmst du keine Rücksicht.

Irgendwie hab ich das Gefuehl, ihr wollt mich bloss verscheissern.

Mir zumindest ist es durchaus Ernst mit meinem Appell: Halt dich von den Anfängern fern, du versaust ihnen durch deinen Code den Stil. Ich fände es gut, wenn du Anfängern deine Fähigkeiten im Lesen von schlechtem Code beibringen könntest. Aber du bringst ihnen nur bei, wie man schlechten Code schreibt.

--linuxuser--

Power Off schrieb:

--linuxuser-- schrieb:

kann das mit deinem (...) code zusammenhaengen?

Nein. Ich hatte bloss bei meinem letzten Arbeitgeber zuviel Stress

warum nur??

Power Off

MFK schrieb:

Mir zumindest ist es durchaus Ernst mit meinem Appell: Halt dich von den Anfängern fern, du versaust ihnen durch deinen Code den Stil. Ich fände es gut, wenn du Anfängern deine Fähigkeiten im Lesen von schlechtem Code beibringen könntest. Aber du bringst ihnen nur bei, wie man schlechten Code schreibt.

Anstatt immer nur dasselbe zu wiederholen, nenn doch mal konkret die Stellen, die Dich stoeren, und schreib zu, warum. Damit dieser Thread fuer einen Anfaenger auch noch einen Wert bekommt. Und fuer mich auch.

Ich halte meinen Stil fuer sehr gut, und jeder, fuer den ich gearbeitet habe, auch. Also, begruende mal Deine Aussagen.

Das ein "while" in dem Fall gereicht haette ist klar, aber warum soll die "for"-Konstruktion "schlechter Code" sein?

Warum rechtfertig das eine Serie persoenlicher Beleidigungen?

Power Off

--linuxuser-- schrieb:

warum nur??

Das hatte mehrere Gruende, aber es lag hauptsaechlich daran, dass ich ein Riesenprojekt allein machen musste.

MFK

Power Off schrieb:

Anstatt immer nur dasselbe zu wiederholen, nenn doch mal konkret die Stellen, die Dich stoeren, und schreib zu, warum. Damit dieser Thread fuer einen Anfaenger auch noch einen Wert bekommt. Und fuer mich auch.

Mehrere Leute haben dir an mehreren Stellen gesagt, was sie an deinem Code stört. In diesem und auch in anderen Threads. Du verstehst die Argumente nicht.

Ich halte meinen Stil fuer sehr gut, und jeder, fuer den ich gearbeitet habe, auch. Also, begruende mal Deine Aussagen.

Warum soll ich nochmals wiederholen, was dir viele Benutzer hier schon mehrfach gesagt haben, und was du bisher nicht verstanden hast? Du hältst deinen Code für stilistisch in Ordnung, sehr viele kompetente Leute hier finden, dass er grottenschlecht ist.

Ich glaube, wir können dich nicht davon überzeugen, dass dein Code schlecht ist. Genausowenig wirst du uns überzeugen können, dass er gut ist. Könnstest du nicht einfach akzeptieren, dass dein Code von vielen in dieser Community für schlecht gehalten wird und dich um des Friedens willen gegenüber Anfängern zurückhalten?

Warum rechtfertig das eine Serie persoenlicher Beleidigungen?

Das tut es nicht. Aber wenn jemand sich derart uneinsichtig zeigt wie du, dann verlagert man schon mal die Argumente auf eine unsachliche Ebene. Ich nehme mich da nicht aus. Du hast wieder und wieder gezeigt, dass du sachliche Argumente gar nicht wahrnimmst. Das einzige, was du anscheinend als stilistisches Merkmal gelten lässt, ist, ob der Code läuft oder nicht. Die Bewertungskriterien Anderer akzeptierst du nicht. Damit bist du unbelehrbar.

In Anlehnung an den alten Geisterfahrerwitz:
"Im Forum gibt es einen, der echt seltsame Ansichten über guten Code-Stil hat."
"Einen? Hunderte!"

Power Off schrieb:

Die Methode, den Code solange zu durchzulesen, bis man davon ueberzeugt ist, ist gut. Meist werfe ich den Compiler nicht eher an, bis ein Modul testbereit ist.

ich compiliere da aber viel, viel mehr.

Ich schreibe die Programme meist von vornherein so, dass man sie erweitern kann, und dass durch eine Aenderung nirgendwo "bugs aufreissen" koennen.

hört, hört.
manchmal hat man "by design" bestimmte sonderwünsche ausgeschlossen. natürlich in absprache mit dem kunden. und genau die will er dann doch haben.

das geht dann beim vogelsimulator so:
P: "ok, normale vögel wie adler stellen konzeptionell kein problem dar. und vögel, die auf dem biden bleiben, weil sie nicht fliegen können, da behaupten wir einfach, daß sie nicht fligen wollen. wie isses mit pinguinen?"
K: "das programm wird ganz sicher nur die mitteleuropäische vogelwelt abbilden sollen. laßt pinguine weg".
und 2 jahre später hätte er gerne eine pinguin-"erweiterung". daß dabei ganz zentrale klassen angetatscht werden und das eher einem kompletten redesign gleichkommt, ist ein problem.

oder bei deinen parsern, wir haben eine zeilenorientierte sprache und es ist in der DIN dazu definiert, daß jede zeile mit \n angeschlossen ist. insbesondere ist das letzte zeichen jeder gültigen quellcodedatei ein \n. ich benutze die info von anfang an und schreibe sogar so code wie du. also keine getline() und dann die zeilen verarbeiten, sondern mitten im parser drin immer getch() und tests.
den code, gegen die explizite spezifikation vorher schon so zu schreiben, daß EOF gültiges zeilenende wäre, ist falsch, denn der user hat sich damals gewünscht, daß alle falschen programme auch mit fehlermeldung bestraft werden.
nach 2 jahren kommt der kunde und will auch EOF als das letzte zeilenende erlauben, weil er inzwischen vermehrt einen editor einsetzt, der das letzte \n auch mal wegschmeißt. ich müßte im ganzen programm jede einleseschleife anpassen. oh, graus!

Jede Funktion hat eine klare Aufgabe und eine klare Schnittstelle. Klassen z.B. duerfen keine nicht-hierarchischen Abhaengigkeiten haben.

du meinst kene zyklischen abhängigkeiten? äh, das kommt aber schon mal vor. warum die forderung?

aber ich hab ne andere: jede funktion erfüllt nur einen zweck. dein monster liest whitespaces davor weg und danach, kümmert sich ums vorzeichen und liest die ziffernfolge selbst ein. das wäre für mich mindestens 4 funktionen, für jeden einfachen zweck eine und eine, die alles zusammenpappt.

Code muss geordnet sein wie eine Julia-Menge, z.B.: man kann rein- und rauszoomen, aber die Zusammenhaenge sind stets klar.

julia-mengen sind nicht in jedem zoom-faktor klar, sondern sie sind in jedem zummfaktor jedem anderen zoomfaktor ähnlich.
wäre code wie julia-mengen, wäre er sich stets ähnlich, egal wohin man zoomt. also im detail schlecht und im großen schlecht, zum beispiel.

sagen wir mal, code soll in jedem zoo-faktor klar sein. ist das nicht genaial einfach zu erreichen, daß in jedem zoom-faktor nur winzige funktionen gebaut werden?
hab jetzt keinen lese-code für ints da. nur schreib-code, aber es sollte klar werden, was ich meine.

template<typename T>
void printSignedImpl(T x,Writer& out){
	if(x<0){
		x=-x;
		out<<'-';
	}
	printUnsignedImpl(toUnsigned(x),out);
}

den leser stelle ich mir ähnlich vor. daß ich dann kein MUL mehr brauche, sondern nur ein unäres minus, ist netter nebeneffekt.