Wie Komplexere Projekte korrekt Programmieren

[new Account()]

Was soll jetzt der kommentarlos hingerotzte Link sagen?

Dachte das ist selbstbeschreibend: Eine Implementierung eines Datentypen, der in den Werten begrenzt ist, mit Hilfe von Templates

 

[andy_m4]

Ich finds ja irgendwie faszinierend. Erst reden sie noch alle wie einfach das doch wäre und nu ist 20 Postings später immer noch nix da.
Es wird langsam lächerlich.
Wer unbedingt Recht behalten will muss im Zweifelsfall auch liefern können. Stattdessen darf ich mir Ausreden anhören.

 

[new Account()]

Soll ich den verlinkten Code jetzt hier reinkopieren, damit du ihn siehst und nicht auf den Link klicken musst?

 

[andy_m4]

Soll ich den verlinkten Code jetzt hier reinkopieren, damit du ihn siehst und nicht auf den Link klicken musst?

Scheint ja echt kompliziert zu sein mal eben so ne Ganzzahl zu definieren die nur die Werte von 1 bis 12 annehmen kann.

Klar könnte ich mir alles selbst zusammenreimen. Aber dann heißt es, wenn ich auf Probleme stoße nur wieder, das ich es nur nicht richtig gemacht hätte. Nene. Ich lasse mich da auf kein Risiko ein, so lange wie hier schon versucht wird auszuweichen.

 

[new Account()]

Kannst ja noch auf meine Klasse warten (natürlich ohne Überlaufdefinitionen, etc. was auch immer), wenn dir das zu komplex ist

Wollte ja nur zeigen, dass es problemlos geht, was du ja angezweifelt hast.

 

[Bagbag]

Hier mal mit TypeScript:

type Month = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12;
const month: Month = 7;

Skaliert natürlich nicht gut und wird bei noch mehr Möglichkeiten etwas unhandlich. Es gibt aber ne Diskussion um sowas zu ermöglichen:

type MyIntegerType = 1..12;
type MyFloatType = 1...12;

 

[andy_m4]

Kannst ja noch auf meine Klasse warten (natürlich ohne Überlaufdefinitionen, etc. was auch immer), wenn dir das zu komplex ist

Laber?
Du hast doch rumgeheult das meine Lösung Aufwand ist ohne es aber bisher erläutern zu können.
Andererseits behauptest Du, dass es in anderen Programmiersprachen wie Java oder C++ kein Problem sei, ohne bisher aber mal das als Quelltext formulieren zu können.

Wollte ja nur zeigen, dass es problemlos geht, was du ja angezweifelt hast.

Bisher hast Du noch GAR NIX gezeigt.

Skaliert natürlich nicht gut und wird bei noch mehr Möglichkeiten etwas unhandlich.

Aber immerhin.

type MyIntegerType = 1..12; type MyFloatType = 1...12;

Erinnert mich von der Syntax ein wenig an Ada Subtyping (die range-Syntax).

 

[new Account()]

Laber?
Du hast doch rumgeheult das meine Lösung Aufwand ist ohne es aber bisher erläutern zu können.
Andererseits behauptest Du, dass es in anderen Programmiersprachen wie Java oder C++ kein Problem sei, ohne bisher aber mal das als Quelltext formulieren zu können.

Du hast selbst gesagt, dass deine Lösung ein gewisser Aufwand ist.

Und ich kann es in Quelltext formulieren, wie du sehen wirst, wenn du deine Geduld übst

Bisher hast Du noch GAR NIX gezeigt.

Doch habe ich mit der Referenz auf eine Bibliothek, die genau das (uvm.) umsetzt.

 

[andy_m4]

Du hast selbst gesagt, dass deine Lösung ein gewisser Aufwand ist.

Ich kann mich nicht erinnern das geschrieben zu haben.

Und ich kann es in Quelltext formulieren, wie du sehen wirst, wenn du deine Geduld übst

Ich gedulde mich ja. Ich wundere mich nur das es dauert, weils ja angeblich kein Problem sein soll.

Doch habe ich mit der Referenz auf eine Bibliothek, die genau das (uvm.) umsetzt.

Na dann wirds ja nicht so schwer sein, die Deklaration hinzuschreiben. *wart*

 

[kuddlmuddl]

Schade, dass einer der wenigen Threads wo mal die wirklich wichtige Frage des Entwickelns (wie baut man erfolgreich große Software) so abdriftet in Streits und Diskussionen ala 'Sprache A ist toller als Sprache B'.

Hier müsste man doch eigtl. über Vor- und Nachteile von CI, Vertikaler Durchstich, Scrum, Agile, XP und Wasserfall reden. Auch welche Vor- oder Nachteile andere Leute zB mit Bottom-Up statt Top-Down Entwicklung erlebt haben hätte mich wirklich interessiert.

 

[Tumbleweed]

Ich kenne leider auch einige Entwickler, die wirklich nur gut bezahlte Programmierer sind und wie mit Scheuklappen ihre Businesslogik in Code hacken wollen und bereits beim Build-Tool dankend ablehnen.

Um aber selbst nicht nur rumzunölen, gehe ich noch mal auf die Ursprungsfrage ein. Theoretische Grundlagen wie Design Patterns und Domain Driven Design kann und sollte man sich beibiegen. Ein daraufhin folgendes Projekt wird vermutlich nicht wie durch Wunderhand guter Code werden, aber im besten Fall hat man hier und da einen flashback ins Gelesene. Es kann natürlich auch passieren, dass man es dann übertreibt und überakademisiert komplizierten Code schreibt...

Ich würde einem Einsteiger wohl raten, sich auf etablierte Tools einzulassen. Statische Code-Analyse weist auf "code smell" und echte Fehler wie Null-Pointer-Dereferenzierung hin. Das führt nicht zu besserer Architektur, aber man kann sich dann mehr auf andere Sachen konzentrieren. Eine wichtige Weisheit, umso mehr, wenn man im Team arbeitet, ist meines Erachtens - Code wird öfter gelesen, als er geschrieben wird. Es ist nicht ausreichend, wenn das Ergebnis der Implementierung stimmt, sondern die Verständlichkeit des Codes ist (zumindest im professionellen Umfeld) bares Geld wert.
Wenn ich dann noch nett bin, hinterlasse ich für meinen Code einen Unit-Test, damit mein Kollege (der nur modifizieren/refactorn will und vielleicht nicht den gleichen Wissens-Hintergrund hat, wie ich) bessere Chancen hat, keine Regression zu verursachen. Es hilft dir natürlich auch selbst, wenn du nach vielen Monaten oder gar Jahren mal wieder an alten Code von dir ran musst.

Um ein bisschen Struktur reinzubekommen, empfiehlt es sich meiner Meinung nach, branchenübliche Frameworks zu nutzen und sich auch auf diese einzulassen. Ich habe schon so manchen Entwickler kennengelernt, der meinte, selbst ist der Mann. Ja natürlich kann ich alles selbst implementieren, aber warum soll ich denn die ganzen Fallstricke, an denen sich andere schon die Pfoten gebrochen haben, noch mal mitnehmen? Da stecken teils Mannjahrzehnte von erfahreneren Entwicklern drin, bei großen Frameworks. Sich dem zu verwehren, ist einfach nur Hybris.

Dann gibt es da noch ein paar Grundprinzipien, die man verinnerlichen sollte, wie DRY, YAGNI, KISS, SOLID und wie sie alle heißen. Auch muss ich mich je nach konkreter Aufgabenstellung entscheiden, ob ich alles in einen fetten Monolithen gieße oder kleine Anwendungen baue, die dann vielleicht übersichtlicher sind. Es ist überall ein Für und Wider, die Entscheidung trifft man je Einzelfall auf Basis seiner Erfahrung. Erfahrung kommt u.a. von früheren schlechten Entscheidungen. Das müssen nicht immer eigene gewesen sein. Man sollte auch offen sein, von Fehlern anderer zu lernen. Für so was ist es z.B. ganz nett, ab und an Konferenzen und Meetups zu besuchen.

Zu guter Letzt noch was, was @kuddlmuddl ja schon andeutete - auch die Art und Weise, wie man ein größeres Projekt angeht, konzeptioniert und später durchführt, ist eine kleine Wissenschaft für sich. Ich habe relativ früh gelernt, dass es illusorisch ist zu denken, man könnte ein Projekt von vorn bis hinten durchplanen. Manchmal muss man erst in eine Richtung loslaufen und Problemchen/Anforderungen feststellen, die man anfangs noch gar nicht auf dem Schirm hatte. Umso wichtiger ist es, dass der Code entsprechend gut wartbar ist, damit man im späteren Projektverlauf noch die Chance hat umzusteuern, ohne einen kompletten rewrite machen zu müssen. Es gibt allerdings noch genug Leute, die über Jahre Papier beflecken wollen und meinen, hinterher programmiert man das runter und hat das perfekte Ergebnis.

 

[DaysShadow]

@kuddlmuddl Der Thread ist halt von 2016, wo übrigens auch der TE das letzte Mal gesehen wurde, und jegliche Diskussion interessiert daher den TE genau 0 😄 k.a warum hier in der Form alte Threads weitergeführt werden, wenn man sich ohnehin nicht an das Thema halten kann

 

[psYcho-edgE]

k.a warum hier in der Form alte Threads weitergeführt werden, wenn man sich ohnehin nicht an das Thema halten kann

Da musst du @new Account() fragen, der ist hier der "Leichenschänder"

 

[andy_m4]

'Sprache A ist toller als Sprache B'.

Geht (mir) gar nicht um Sprache A ist besser als B. Es geht darum, dass verschiedene Sprachen unterschiedliche Stärken und Schwächen haben.

Hier müsste man doch eigtl. über Vor- und Nachteile von CI, Vertikaler Durchstich, Scrum, Agile, XP und Wasserfall reden. Auch welche Vor- oder Nachteile andere Leute zB mit Bottom-Up statt Top-Down Entwicklung erlebt haben hätte mich wirklich interessiert.

Hätten wir gerne machen können. Wenn Dich das interessiert, frag nach. Blöd ist hinter her angelaufen zu kommen und sich lediglich zu beschweren, dass die Diskussion nicht in die gewünschte Richtung verlaufen ist.

Ergänzung (26. November 2018)

Ich habe relativ früh gelernt, dass es illusorisch ist zu denken, man könnte ein Projekt von vorn bis hinten durchplanen. Manchmal muss man erst in eine Richtung loslaufen und Problemchen/Anforderungen feststellen, die man anfangs noch gar nicht auf dem Schirm hatte.

Dem kann ich nur zustimmen. Das ist in nicht wenigen Fällen durchaus ein probates Mittel. Weil man dann auch schnell quasi was in der Hand hat, was man zurecht modellieren kann.
Wobei sich bei mir ein grober Plan schon relativ früh ergibt. Der ist zwar auch nicht in Stein gemeißelt, aber man hat halt eine Karte und tastet sich nicht blind vor.
Wobei hier auch viel Erfahrung reinspielt. Die hat man nicht von Anfang an.

Umso wichtiger ist es, dass der Code entsprechend gut wartbar ist, damit man im späteren Projektverlauf noch die Chance hat umzusteuern, ohne einen kompletten rewrite machen zu müssen.

Ja. Das ist extrem wichtig. Aber den sollte man ja sowieso haben. Von daher muss man ja nicht großartig was Anderes machen also sowieso empfohlen.
Und die modernen (Refactoring-)Tools unterstützen dabei ja auch, wenn man etwas reorganisieren muss.

Statische Code-Analyse weist auf "code smell" und echte Fehler wie Null-Pointer-Dereferenzierung hin. Das führt nicht zu besserer Architektur, aber man kann sich dann mehr auf andere Sachen konzentrieren.

Exakt. Man kann bestimmte Sachen damit relativ gut vermeiden.

 

[BeBur]

Viel gutes wurde an sich schon geschrieben auf den ersten Seiten.
Was noch fehlt: Sinnvolle (impliziert: viele) Tests schreiben und stets auch Zeit nehmen refactoring zu betreiben.

Die verlinkte bounded::integer library klingt sehr geil aber hat ja einen etwas anderen bzw. allgemeineren Scope.

Here we see the most important idea behind using the library, and that is type deduction. The goal is to specify only the bounds of your inputs, and have the compiler deduce the bounds of all intermediate and result types.

Das ist ja recht üblich bei C++, man will möglichst keinen runtime overhead haben. Deswegen ist so etwas wie "ich will einen Integer haben, der soll aber maximal 12 sein" nicht im Sprachstandard vorgesehen.

Im OOP Sinne will man sowas ja sowieso nicht haben, in der Welt der Domäne gibt es schließlich nie Integers, höchstens relativ simple Value Objects. Von daher ist sich einen Integer-Datentyp für ein Intervall von Null bis Zwölf zu definieren schlechter Stil im Sinne des Threads.

Von daher ist die Frage nicht, warum das im C++ Standard nicht vorgesehen ist, sondern warum das überhaupt irgendjemand machen wollen würde und warum das bei Racket in der Form möglich ist.
Die Antwort darauf lautet vermutlich, dass bei Racket das funktionale Programmieren im Vordergrund steht und das Beispiel nur eine Konsequenz daraus ist, vermutlich kann man eine beliebige lambda-funktion verwenden.

Funktionales Programmieren ist mMn aber schon eher sehr speziell und nicht so richtig OnTopic.

 

[Miuwa]

Ja dann los. Ich warte. Irgendwie wird davon geredet das es geht, aber keiner wird mal konkret.
Nicht labern, machen!

Ich hab es schon gemacht, sonst würde ich nicht drüber labern. Die Library ist aber nicht open source.

Wie ich schon geschrieben habe: Der Code ist zu lang um ihn hier zu posten, selbst wenn ich könnte, aber nicht kompliziert.
Die Nutzung ist jedenfalls genauso trivial wie wenn es Teil der Sprache wäre:

bounded_int<-5,5> i = 3;

Wirst du mir natürlich nicht glauben solange der Code nicht hier im Forum gepostet wird, aber das ist mir eigentlich ziemlich schnuppe - werd ja schließlich nicht dafür bezahlt dich zu überzeugen.

 

[Fonce]

@BeBur
Also ja C++ verfolgt einen Zero Overhead Ansatz, aber das ist vor allem auf Libraries bezogen! Wenn ich diese in einer Anwendung nutze wird eigentlich immer empfohlen wenn vorhanden Zugriffe über Varianten mit Bound Checks zu wählen.(z.B. beim Zugriff auf einen std::vector über die Methode at(int Index).
Verstehe jetzt auch nicht wie du drauf kommst das man das im OOP Sinne nicht haben will? Prüfst du deine Eingabeparameter etwa nicht?

 

[BeBur]

Das 'nicht haben will' bezog sich auf das Beispiel eines auf Integer basierten Datentyps mit einer Einschränkung wie "darf maximal bis 18 gehen". Das sind praktisch immer Domänenspezifische Bedingungen, die im Rahmen von OOP in einer Klasse gekapselt sind. Ich bezog mich dabei auf untenstehendes Argument, das meines Erachtens nach auf einen ungünstigen Fokus basiert.
Sowas wie:
type animal_count = 1..18; // We only have 18 types of animals in our game
Will man sowieso nie schreiben, von daher spielt es mMn im Rahmen von "wie komplexe Projekte korrekt Programmieren" eine untergeordnete Rolle.

Es geht um korrektes programmieren. Und dazu gehört halt auch Datentypen sinnvoll definieren. Das Problem ist, wenns nicht geht oder zu kompliziert ist, machts keiner.

 

[andy_m4]

Das ist ja recht üblich bei C++, man will möglichst keinen runtime overhead haben. Deswegen ist so etwas wie "ich will einen Integer haben, der soll aber maximal 12 sein" nicht im Sprachstandard vorgesehen.

Genau darauf hatte ich bereits hingewiesen.

Im OOP Sinne will man sowas ja sowieso nicht haben, in der Welt der Domäne gibt es schließlich nie Integers, höchstens relativ simple Value Objects. Von daher ist sich einen Integer-Datentyp für ein Intervall von Null bis Zwölf zu definieren schlechter Stil im Sinne

Das hätte ich jetzt gern mal näher erläutert. Also inwiefern das schlechter Stil ist.

Von daher ist die Frage nicht, warum das im C++ Standard nicht vorgesehen ist, sondern warum das überhaupt irgendjemand machen wollen würde und warum das bei Racket in der Form möglich ist.

Ganz einfach. Weil man auf ein gutes/umfangreiches Typ-System sehr viel wert legt. Was auch absolut Sinn macht, weil ein gutes Typsystem viele Fehler vermeidet.

Die Antwort darauf lautet vermutlich, dass bei Racket das funktionale Programmieren im Vordergrund steht und das Beispiel nur eine Konsequenz daraus ist,

Nein. Nicht wirklich. Erstens hat Racket auch ein klassenbasiertes Objektsystem, wo man diesen ganzen Typkram übrigens auch drauf anwenden kann. Zum anderen die die Idee ja nicht neu. Das geht z.B. auch in Ada. Da kann man ebenfalls Typen mit Contraints einschränken:
subtype Monthtype is Integer range 1 .. 12;

und viola hat man ein Typ mit denen man Variablen deklarieren kann, die eben nur Ganzzahlen von 1 bis 12 annehmen können.

Und Ada ist nicht funktional. Eher strukturiert und natürlich seit den 90er Jahren auch Objektorientierung.

vermutlich kann man eine beliebige lambda-funktion verwenden.

Was ja auch eine große Stärke ist. Weil man eben nicht für jeden Kram eine extra Syntax braucht, sondern das nehmen kann, was man sowieso immer nimmt.

Funktionales Programmieren ist mMn aber schon eher sehr speziell und nicht so richtig OnTopic.

Sehe ich komplett anders. Funktionales Programmieren bringt in vielen Situationen Vorteile. Weil es es einfacher macht fehlerfreie Programme zu schreiben (durch die Minimierung von Nebeneffekten) und weil man (auch daraus resultierend) gute Unterstützung für Multithreading quasi nebenbei geschenkt bekommt.
Ich will funktionales Programmieren jetzt hier nicht als Allheilmittel verstanden wissen. Aber es sollte halt zum Repertoire eines Programmierers genauso dazu gehören, wie eben OOP und andere Paradigmen.

 

[new Account()]

Ganz einfach. Weil man auf ein gutes/umfangreiches Typ-System sehr viel wert legt. Was auch absolut Sinn macht, weil ein gutes Typsystem viele Fehler vermeidet.

Also ich kann mich nicht erinnern z.B. in C++ je ein Problem damit gehabt zu haben einen passenden Typ zu definieren. Falls ich mal bounded integers brauchen sollte, habe ich die Library im Reportaire. Danke für das Konzept des Beschränken eines Integers von 1 bis 12!
C++ hat viele Probleme, aber das letzte Problem, das C++ hat ist wahrscheinlich Beschränktheit in jeglicher Hinsicht.