Best Practice - Aufbau und Struktur

[Nopp]

Guten Morgen zusammen,

ich probiere mich seit neuestem auch beim Programmieren, hauptsächlich mit Python und GDScript. Wenn ich das besser beherrsche möchte ich gerne C++ dazu nehmen. Aber ist ja auch egal, womit ich mich rumschlage.

Meine Frage richtet sich eher darauf, ob es gewisse "best practices" oder Konventionen gibt, wie man ein Programm/Tool/Spiel aufbauen "sollte". Damit meine ich z.B. folgendes:

1. Nicht zu viel in eine Klasse schreiben
2. Nicht zu viele (oder keine?) globalen Variablen
3. Einrückungen sollten so und nicht so gemacht werden
4. etc...

Gibt es gute Lektüre, die solches gut beschreibt und ggf. auch Anwendungsbeispiele nennt, warum man das so tun sollte? Beim Programmieren führen ja wirklich sehr viele Wege zum Ziel, aber viele sind unsauber und hinken deswegen oft stark z.B. in der Performance. Und das würde ich gerne vermeiden und gleich von Anfang an lernen "sauber" zu programmieren und weniger zu hacken.

Vielen Dank für hilfreiche Tipps!

 

Nopp 

 

 

[Panawr]

Das erste Buch was mit natürlich einfällt ist "Clean Code":

https://www.amazon.de/Clean-Code-Refactoring-Patterns-Techniken/dp/3826655486

Wirklich gutes Buch, weiß jedoch nicht ob es in deinem Fall mit Kanonen auf Spatzen schießen ist.
Möchtest du denn auch in der Berufswelt mit dem programmieren einsteigen? Dann kann ich dir das Buch
sehr ans Herz legen. Möchtest du nur für dich selber bisschen programmieren, aber trotzdem halbwegs 
guten Code haben, dann reicht es vielleicht schon sich den Code von ein paar guten Open Source Projekten
anzuschauen.

PS: Hier gibt es noch einen Blog, der auf Basis dieses Buches schon einiges zusammen gefasst hat:
http://www.sebastianviereck.de/regeln-fur-guten-sauberen-code-clean-code/

Bearbeitet 31. August 2016 von Panawr

[Nopp]

vor 12 Minuten schrieb Panawr:

Das erste Buch was mit natürlich einfällt ist "Clean Code":

https://www.amazon.de/Clean-Code-Refactoring-Patterns-Techniken/dp/3826655486

Wirklich gutes Buch, weiß jedoch nicht ob es in deinem Fall mit Kanonen auf Spatzen schießen ist.
Möchtest du denn auch in der Berufswelt mit dem programmieren einsteigen? Dann kann ich dir das Buch
sehr ans Herz legen. Möchtest du nur für dich selber bisschen programmieren, aber trotzdem halbwegs 
guten Code haben, dann reicht es vielleicht schon sich den Code von ein paar guten Open Source Projekten
anzuschauen.

PS: Hier gibt es noch einen Blog, der auf Basis dieses Buches schon einiges zusammen gefasst hat:
http://www.sebastianviereck.de/regeln-fur-guten-sauberen-code-clean-code/

Danke für deinen Kommentar!

Ich möchte es sowohl privat als auch beruflich einsetzen, bzw. ich arbeite an 2 Softwareprojekten mit, aber nicht als Entwickler. Möchte ich jedoch langfristig auch können oder eigenständig in der Lage sein etwas zu entwickeln. Zum Selbstzweck oder vielleicht auch nicht. Mir ist es aber wichtig es sauber zu machen, so wie meine Arbeit als Admin

Daher danke ich dir sehr für die Links 

 

Bearbeitet 31. August 2016 von Nopp

[Whiz-zarD]

vor 29 Minuten schrieb Panawr:

Das erste Buch was mit natürlich einfällt ist "Clean Code":

https://www.amazon.de/Clean-Code-Refactoring-Patterns-Techniken/dp/3826655486

Ja, das Buch ist zu empfehlen und eines der Pflichtlektüre, wenn es um Clean Code geht.

Es ist aber ein Irrglaube, wenn du denkst, dass Clean Code gleichzeitig auch eine bessere Performance bietet. Clean Code ist einfacher zu lesen und zu warten aber das hat nichts mit Performance zu tun. Um Performance würde ich mir auch erst mal keine Gedanken machen, sondern es geht erst mal darum, sein Code sauberzuhalten. 

Wie Einrückungen gemacht werden ist Geschmackssache und auch von Sprache zu Sprache unterschiedlich. Java und C# haben eine nahezu identische Syntax und dennoch sind die empfohlenden Namenskonventionen von Klassen/Methoden unterschiedlich. Während in z.B. Java empfohlen wird, eine Methode so zu schreiben:

public void method() {
	// mach was
}

Wird sie in C# so empfohlen:

public void Method()
{
	// mach was
}

Und Python definiert die Blöcke nicht mit geschweiften Klammern, sondern mit Tabs. Da wird man also gezwungen, sauer einzurücken.

vor 49 Minuten schrieb Panawr:

PS: Hier gibt es noch einen Blog, der auf Basis dieses Buches schon einiges zusammen gefasst hat:
http://www.sebastianviereck.de/regeln-fur-guten-sauberen-code-clean-code/

Zitat

Interfaces und Implementierungen

Eine Interface Klasse sollte im Bezeichner keine Erwähnung des Namens beinhalten, wie z.B. IShape, sondern einfach Shape heißen. Die Implementierung des Interfaces sollte am kenntlich sein, am Ende des namens, z.B. ShapeImp

Man muss aber auch darauf achten, dass hier Java gemeint ist, denn in der C#-Welt wird dies ebenfalls nicht empfohlen. In der C#-Welt ist es üblich, dass Interfaces mit einem großen I anfangen und für den eigentlichen Namen nimmt man ein Adjektiv (z.B. IDisposable) oder ein Nomen (z.B. IList).

In C# endet auch die konkrete Implementierung nicht mit Imp oder Impl. Das braucht man auch nicht, da schon durch das große I erkennbar ist, was ein Interface und was eine Klasse ist. (z.B. die Klasse List implementiert das Interface IList).

[afo]

Clean Code würde ich erst als Schritt 2 sehen.

Am Anfang brauchst du einen viel umfassenderen Überblick. Da empfehle ich dir Code Complete. https://www.amazon.de/dp/0735619670/

[Nopp]

vor 35 Minuten schrieb afo:

Clean Code würde ich erst als Schritt 2 sehen.

Am Anfang brauchst du einen viel umfassenderen Überblick. Da empfehle ich dir Code Complete. https://www.amazon.de/dp/0735619670/

Ist das denn noch alles "aktuell"? Scheint ja ein etwas älteres Werk zu sein. Oder ändern sich solche Konventionen eigentlich nicht?

[Whiz-zarD]

Was  verstehst du denn unter "Konventionen"?
Eine Konvention ist ja eine Vereinbarung. Darunter versteht man in der Softwareentwicklung eher sowas wie Namensgebung, Einrückungen, etc. Es gibt zwar empfohlende Konventionen aber das kann sich auch von Firma zu Firma unterscheiden. Keiner muss sich daran halten. 

Das, was du wohl meinst, sind wohl so etwas wie Design Patterns. Zum Thema Design Patterns kann man noch das gleichnamige Buch von Erich Gamma erwähnen, was eigentlich so zur Pflichtlektüre gehört.
Ich kenne das Buch "Code Complete" nicht aber ich denke, das meiste, was man dort findet, findet man auch im Buch "Clean Code". Zumindest liest sich die Agenda sehr ähnlich. Man darf auch nicht vergessen, dass Robert C. Martin als einer Erfinder des Begriffs "SOLID" gilt, was die Welt der objektorientierten Programmierung der letzten 10 Jahren sehr geprägt hat.

Ansonsten könnte man noch Begriffe wie Test-driven Development (TDD) und Design-driven Design (DDD) in den Ring werfen. Dazu gibt es dann auch noch haufenweise Bücher aber das sind Praktiken, die man Anwenden kann, wenn man schon mehr Erfahrungen gesammelt hat.
 

[Nopp]

vor einer Stunde schrieb Whiz-zarD:

Was  verstehst du denn unter "Konventionen"?
Eine Konvention ist ja eine Vereinbarung.

.....

Das, was du wohl meinst, sind wohl so etwas wie Design Patterns.

Da hast Du wohl Recht. Ich meine halt "Das beste Vorgehen" bei gewissen Tätigkeiten der Softwarentwicklung. Gibt es ja auch für die Systemadministration. Redbooks, Best Practices von MS, etc.pp.

[KeeperOfCoffee]

vor 19 Minuten schrieb Nopp:

Da hast Du wohl Recht. Ich meine halt "Das beste Vorgehen" bei gewissen Tätigkeiten der Softwarentwicklung. Gibt es ja auch für die Systemadministration. Redbooks, Best Practices von MS, etc.pp.

Meinst du diese Cookbooks? (einfach mal googeln) wie z.B.

dieses hier

Bearbeitet 31. August 2016 von KeeperOfCoffee

[Nopp]

vor 2 Minuten schrieb KeeperOfCoffee:

Meinst du diese Cookbooks? (einfach mal googeln)

Ne, darum geht es ja m.W. nicht um den grundlegenden Aufbau, sondern um die spezifische Lösung von Anwendungsfällen, wenn ich mich nicht irre.

[afo]

vor 2 Stunden schrieb Nopp:

Ist das denn noch alles "aktuell"? Scheint ja ein etwas älteres Werk zu sein. Oder ändern sich solche Konventionen eigentlich nicht?

Mythical Man-Month ist von 1975, How to win friends and influence people von 1936. So grundlegende Dinge ändern sich eher selten und wenn dann meistens langsam.

vor 2 Stunden schrieb Whiz-zarD:

Ich kenne das Buch "Code Complete" nicht aber ich denke, das meiste, was man dort findet, findet man auch im Buch "Clean Code". Zumindest liest sich die Agenda sehr ähnlich.

Code Complete ist viel umfassender. Es werden dabei auch wesentlich grundlegendere Fragen beantwortet. Ein Anfänger kann da mehr mitnehmen, weil es eben auch um so Dinge geht wie man variablen benutzt, wann man welchen Datentyp benutzt, wie man Dinge aufteilt, welche Kontrollstrukturen man wie und wann anwendet.

Clean Code hingegen kann meiner Meinung nach seine Stärken erst entfalten wenn man mal 1-2 Jahre programmiert hat. Zu vielen der Punkte fehlt einem sonst einfach noch der Bezug und man liest einfach nur drüber ohne das was hängen bleibt während an anderer stelle vielleicht noch grundlegende Einsichten fehlen.

An anderer Stelle habe ich schon mehrfach für Einsteiger die folgenden 3 Bücher empfohlen:

Kent Beck - Implementation Patterns
Steve McConnell - Code Complete
Hunt/Thomas - The Pragmatic Programmer

Und zwar in genau dieser Reihenfolge. Clean Code ist dann vermutlich Nummer 4.
Implementation Patterns ist großartig, weil es genau die Fragen "wie mache ich eigentlich.../wie verwende ich..." auf relativ niedriger Ebene beantwortet.

Bearbeitet 31. August 2016 von afo