Zum Inhalt springen
  • 0

Checkliste "der gute Ton" beim Programmieren


Finux

Frage

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

7 Antworten auf diese Frage

Empfohlene Beiträge

  • 1

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.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0
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). 

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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.

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Diese Frage beantworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...