Checkliste "der gute Ton" beim Programmieren

[Finux]

Hallo zusammen, 

 

ich bin Neuling was die Programmierung angeht (angehender FiAe). Ich suche seit einigeer Zeit ein Nachschlagewerk/anderes Material, welches einfach (möglichst Sprachenunabhängig!) ganz Grundlegendes beinhaltet unter dem Gesichtspunkt: "Was gehört zum guten Ton eines Programmierers?" 
Ich meine damit so Dinge wie

--> "Man sollte aus Grund X und Y seinen geschriebenen Code möglichst gut dokumentieren. Das kann in etwa so aussehen [Bsp.Abbildung]"

--> "Man sollte nie Funktionen und Variablen gleich benennen (Es gibt Programmiersprachen wo das möglich ist)"

 

Es gibt sicherlich eine ganze, ganze Menge dieser Dinge, ich als Frischling habe aber keine Übersicht darüber.

Manches kommt mit der Erfahrung, einiges steht auch vielleicht in Sprachenbezogenen Lehrbüchern, aber diese Zeilen in diesen 1.000 Büchern zu finden ist schier unmöglich, und ich möchte mir so früh wie möglich ganz bewusst "den guten Ton" antrainieren, weil ich selbst auch viel Wert darauf lege. 

Ich hoffe es ist verständlich geworden, was ich suche, möglicherweise gibts den perfekten Suchbegriff- in dem Falle, ich steh aufm Schlauch, helft mir mal runter ?

P.S.: Dass es natürlich keine zwingende Voraussetzung ist sich "den guten Ton" anzueignen ist mir natürlich klar.


Vielen Dank im Voraus!

 

FIN

[Whiz-zarD]

Regel Nr.1: "There's no silver bullet!"

Bedeutet: Es gibt kein Konzept, dass für alle Fälle gilt. Es fängt schon damit an, dass Firmen oft einen Styleguide vorgeben, wie der Code aussehen sollte, damit er unternehmensweit einheitlich aussieht. Dafür geben häufig die Entwickler der Sprache schon einen Styleguide mit, an denen man sich orientieren kann. 

Auch beim Punkt "Code Kommentierung" scheiden sich die Geister. Einige sagen: "so viel Kommentare wie möglich". Ich sage: "So wenig Kommentare, wie nötig." Der Code sollte schon sprechend genug sein, denn da steckt die Wahrheit. Der Kommentar kann lügen, wenn z.B. der Code angepasst wurde aber der Kommentar nicht.

Aber das ist alles Kleinkram. Styleguides lassen sich überwachen und automatisieren. Dafür gibt es Erweiterungen für die Entwicklungsumgebungen, die z.B. ein Einchecken verhindern, wenn der Stil nicht stimmt. Viel wichtiger ist die Einhaltung der Programmierprinzipien. Da gibt es ne ganze Menge und unterscheiden sich je nach Paradigma und können auch nur durch Übung erlernt werden. Es ist nicht möglich, einfach ein Haken dahinter zu setzen. In der Objektorientierung haben wir z.B. die SOLID-Prinzipien, dann gibt es noch das KISS-Prinzip und das DRY-Prinzip.

Zum "guten Ton" gehören auch sog. Unittests. Also automatisierte Tests, die dein Code testen. Daher gehen viele Entwickler dazu über, das sog. TDD-Verfahren (Test-driven Development) bzw. das Test-First-Konzept einzusetzen, das bedeutet, dass man zuerst den Test schreibt und dann seinen Code. So zu handeln, bedarf es schon einiges an Disziplin. Nach traditionellen Methoden wurden Tests erst nachdem die Entwicklung fertig war, geschrieben. Das war aber immer ätzend, zeitaufwendig und fraß Geld. Daher wurde es dann gerne ganz weggelassen, was zur Folge hatte, dass der Code irgendwann untestbar wurde und immer mehr Bugs verursachte.

 

[KeeperOfCoffee]

Ein Buch kann normalen Menschenverstand nicht ersetzen.

Du kannst so viele Bücher haben  wie du willst, wenn die Firma X für die du arbeitest es so und so will, kannst du das ganze eh über den Haufen werfen.

[pr0gg3r]

vor 22 Minuten schrieb Finux:

ich bin Neuling was die Programmierung angeht (angehender FiAe).

Dann gedulde dich, das kommt von Zeit zu Zeit. Eigentlich gehört das (meiner Meinung nach) auch mit zu den Aufgaben deines Ausbildungsbetriebes, jedoch legt nicht jeder Betrieb Wert auf Qualität. Habt ihr Code-Reviews?

vor 26 Minuten schrieb Finux:

Ich hoffe es ist verständlich geworden, was ich suche, möglicherweise gibts den perfekten Suchbegriff- in dem Falle, ich steh aufm Schlauch, helft mir mal runter ?

"best programming practices", "programming paradigms", "improve code quality", ... Anonsten gibt es auch Bücher, wie z.B. "clean code". Am allerwichtigsten ist es dennoch, jemanden zu haben, der sagt: "das hier kannst du so und so besser machen" (deshalb meine Frage nach den Code-Reviews). 

[JimTheLion]

Ich würde hier noch The Pragmatic Programmer empfehlen https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition

Zitat

• Fight software rot
• Learn continuously
• Avoid the trap of duplicating knowledge
• Write flexible, dynamic, and adaptable code
• Harness the power of basic tools
• Avoid programming by coincidence
• Learn real requirements
• Solve the underlying problems of concurrent code
• Guard against security vulnerabilities
• Build teams of pragmatic programmers
• Take responsibility for your work and career
• Test ruthlessly and effectively, including Property-based testing
• Implement the Pragmatic Starter Kit
• Delight your users

 

[car_cdr]

Das Buch "Clean Code" von Robert C. Martin ist recht bekannt.
Es programmiersprachen-unabhängig und behandelt viele nützliche Themen aus der Objektorientierten-Programmierung.

In diesem Buch stehen auch interessante Sachen drin, z.B. dass es aus Sicht des Autors gar nicht mal so gut ist, alles zu kommentieren, sondern dass man anstatt dessen den Code - eben durch Clean Code - für sich selbst sprechen lässt. Kommentare zeigen laut ihm eher das Unvermögen auf, sich selbst durch Code ausdrücken zu können.

Zitat

P.S.: Dass es natürlich keine zwingende Voraussetzung ist sich "den guten Ton" anzueignen ist mir natürlich klar.

Also meiner Meinung gehört das auf jeden Fall dazu. Vor allem, wenn man das beruflich macht. Den Unternehmen geht auf Dauer viel Geld dabei verloren, dass Projekte nicht gut programmiert werden. Denn wenn das Projekt wächst und wächst, wird der Zeitaufwand, den Code zu verbessern und sich ins Projekt einzuarbeiten, auch immer größer.

[Visar]

Der "gute Ton" beim Programmieren ist leider immer noch sehr subjektiv geprägt, @Whiz-zarD hat das bereits recht gut zusammengefasst. Wir haben bei uns noch viele Legacy-Anwendungen, zu denen keine ausführliche Dokumentation existiert und wo der Code nur sehr sporadisch kommentiert wurde. Schlimmer wird es nur dadurch, dass das Ganze weder sonderlich selbsterklärend noch gut lesbar ist. Sich am Gegenteil zu orientieren kann also nicht so verkehrt sein.

Tests verstehe ich dagegen weniger als "guten Ton", sondern schlicht als Muss. Qualitätssicherung ist wichtig. Ende.

 

 

 

[MartinSt]

Code Complete

Steve McConnell