Code bewerten - als Anfänger

jetzt mal unabhängig von funktioniert/ funktioniert nicht oder versetht 
es ein andere ja/ nein

Ich denke nicht das ein Anfänger (vlt. sogar jeder)  seinen eingenen 
Code sinnvoll berwerten kann. Was ein Anhaltspunkt sein könnte: wenn du 
nach einer Weile deinen Code ändern oder erweitern willst und dabei 
größere Schwierigkeiten hast, dann ist der Code schlecht dokumentiert 
oder strukturiert.

Michael B. schrieb:
> Die klassische Bewertung eines Programmcodes ... geht nach dem Aufwand
> den der Prozessor hat die Aufgabe zu bearbeiten

Das ist nur ein Aspekt.
Was ist mit Testbarkeit, Fehlerverhalten, Wartbarkeit (nicht als 
Nebeneffekt), Dokumentation und (dank der BLWer) Time-to-Market?

Danke für die Rückmeldungen.

Michael B. schrieb:
> Informatik-Grundvorlesung,

habe so eine Vorlesung nie besucht, das grobe Zeug, was ich beherrsche, 
selber beigebracht. =)

Michael B. schrieb:
> Anzahl der
> Maschienbefehle

wie kann ich das in meinem konkreten Fall herausfinden? Also was ich so 
höre, hängt es von der Hochsprache usw ab

Wolfgang schrieb:
> Fehlerverhalten

interessanter Punkt.  Wie macht man das "messbar", also wie kann ich da 
eine quantitative Aussage treffen?

Mark B. schrieb:
> 1.) Das korrekte Ergebnis liefert.
> 2.) Von einer anderen Person gelesen und ohne großen Aufwand verstanden
> werden kann. Das erzielt man durch vernünftige Namen für Funktionen und
> Veriablen, und hier und da mal einen sinnvollen Kommentar warum man
> Problem X jetzt auf die Art und Weise Y löst.

naja, obs jemand versteht ist subjektiv. Ich wollte mehr in die 
wissenschaftliche Richtung

Einem Anfänger anzuraten den Maschinencode als Maß von Softwarequalität 
heran zu ziehen halte ich für falsch.

Auf Sourcecode Ebene gibt es brauchbare Richtlnie nach denen der code 
erstellt werden sollte.
Man muß ja nicht gleich MISRA-C anlegen, aber einiges davon ist durchaus 
sinnvoll.

Lesestoff (und weiter führende links) gibt es z.B. hier: 
https://de.wikipedia.org/wiki/Programmierstil

Wolfgang schrieb:
> Das ist nur ein Aspekt.
> Was ist mit Testbarkeit, Fehlerverhalten, Wartbarkeit (nicht als
> Nebeneffekt), Dokumentation und (dank der BLWer) Time-to-Market?

Auf Time-to-Market würde ich nur Optimieren, wenn ich weiß das die Firma 
verlasse bevor das nächste Update Kommt. Bei denn anderen Aspekten gehe 
ich mit.

Wichtig ist auch immer, das der Autor des Codes sagt auf was er 
Optimiert hat. Was nutzt mir ein super schnelle Algorithmus, der viel 
Speicher braucht wenn ich nur wenig davon habe. Die Wartbarkeit ist auch 
so ein Faktor, denn man Schwer Objektiv messen kann, aber guten Code von 
Schlechten unterscheidet.

Ich zum Beispiel finde die Simple Erkenntnis: "Code wird öfters gelesen 
als Geschrieben, also Optimiere auf das leichte Verständnis!" Im 
allgemeinen besser, als, auf das letzte µ-laufzeit von Hand optimierte 
Programme. Als High frequency Broker hätte ich vielleicht andere 
Prioritäten.

NichtWichtig schrieb:
> Lesestoff (und weiter führende links) gibt es z.B. hier:
> https://de.wikipedia.org/wiki/Programmierstil

danke, guter Hinweis

Al3ko -. schrieb:
> Wie groß bzw. umfangreich ist dein Code?

ca 1000 Zeilen

Al3ko -. schrieb:
> Und da du im Elektronik/uC Unterforum geschrieben hast, gehe ich davon
> aus, dass dein Code für uC gedacht ist?

das ist richtig

Es lässt sich kurz zusammenfassen, dass es mannigfaltige Kriterien zur 
Bewertung von Sourcecode gibt. Das hängt stark davon ab, was Deine 
Aufgabe in einem Projekt ist und ob es sich um PC-Software oder Firmware 
handelt.
Meiner Erfahrung nach, wirst du Sourcecode einmal schreiben und vielfach 
lesen müssen. Schreib ihn so, dass er einfach lesbar ist. Davon 
ausgenommen sind lediglich performance-kritische Codeteile. Die dann mit 
entsprechend noch höherer Sorgfalt dokumentiert werden müssen.

Für mich hat sich folgendes Kriterium als brauchbar erwiesen:

google nach: "the only valid measurement of code quality wtfs/minute"

kann man soetwas als Programmierstil bezeichnen (gibt es eine Norm)? Ist 
das soetwas, an das ihr euch haltet?

USS schrieb:
> kann man soetwas als Programmierstil bezeichnen (gibt es eine Norm)? Ist
> das soetwas, an das ihr euch haltet?

Lies bitte den verlinkten Wikipedia-Artikel.

Mir scheint die Frage wichtig, worum es Dir geht.

Ich vermute, Du nimmst an, dass es einen richtigen, allgemein 
anerkannten Stil gibt. Das trifft nicht zu.

Es gibt vielmehr eine Reihe verschiedener, sich teilweise 
widersprechende, teilweise umstrittene Regeln, auf die man sich 
festlegen kann oder auch nicht. Der Wikipedia-Artikel beschreibt das 
Problem der Entscheidung und einige Regeln recht verständlich und 
ausführlich, denke ich.

Das wesentliche scheint mir zu sein, sich, für sich persönlich oder für 
eine Gruppe, zunächst mal auf ein paar Regeln festzulegen und sie strikt 
zu befolgen. Man wird im Laufe der Zeit erfahren, ob der Sinn, der 
Effekt dieser Regeln für einen selbst wichtig ist oder nicht. Ebenso, ob 
es Regeln gibt, die einem fehlen oder sogar solche, an die noch niemand 
gedacht hat.

Sinnvolle Fragen i.d.Zshg. scheinen mir also zu sein: Welche Regeln gibt 
es (Wikipedia und anderswo)? Welche will ich anwenden? Welchen Effekt 
sollen sie haben? Haben (nach einer Weile der Anwendung) diese Regeln 
den gewünschten Effekt? Welche externe Kritik gibt es? Halte ich diese 
Kritik für relevant?

USS schrieb:
> kann man soetwas als Programmierstil bezeichnen (gibt es eine
> Norm)? Ist
> das soetwas, an das ihr euch haltet?

Kommt Darauf an (TM) Wenn es Teil des Pflichtenheft/Projektstandard ist, 
halte ich mich dran. Meiner Persönlichen Meinung widerspricht der Aufbau 
diese Struktur.
Zum Beispiel Wenn die Funktionen so wie so in der gleichen Datei 
Implementiert werden, wozu dann die Protoypen über der Main? Die Main am 
Ende hätte den Vorteil, dass ich mit einer guten IDE sofort dahin 
springen kann und das Programm so lesen wie es der Computer tut und so 
weiter.

Wegstaben V. schrieb:
> Das ist erstmal kein "Stil", sondern "Struktur".

macht Sinn. Gibt es Normen für Strukturen

> Üblicherweise gilt, daß Programme die weniger Aufwand enthalten, auch
> einfacher zu erweitern und warten sind.

Dass die Effizienz eines Programms in die Qualitätsbewertung eingeht, 
steht außer Frage.  Allerdings habe ich eher die Erfahrung gemacht, dass 
effiziente Lösungen meist komplexer und schwerer zu warten sind als 
triviale, einfache und offensichtlich korrekte, dafür aber meist weniger 
effiziente Lösungen.  Zu entscheiden, welche davon die "bessere" Lösung 
ist, erfordert Erfahrung und einen guten Überblick über das 
Gesamtproblem.


>> Anzahl der Maschienbefehle
>
> wie kann ich das in meinem konkreten Fall herausfinden? Also was ich so
> höre, hängt es von der Hochsprache usw ab

Beim Betrachten der Laufzeit unter Groß-O-Notation ist die konkrete 
Implementierung eher nebensächlich.  Man betrachtet die Abhängigkeit der 
Laufzeit von der Menge an Eingabedaten: doppelte soviele Eingabedaten, 
doppelte Laufzeit -> O(N); doppelte Eingabedaten, 4-fache Laufzeit -> 
O(N²); etc.  Ob die Implementation in Sprache A nun 30% schneller ist 
als in Sprache B, ist irrelevant, da konstante Faktoren rausfliegen. 
Die Sprache wird erst relevant, wenn sie bestimmte (effiziente) Lösungen 
nicht ermöglicht.

Ich vergaß zu erwähnen, dass es auch ästhetiche Gesichtspunkte gibt. In 
manchen Fällen widersprechen sie auch einer Stilregel.

Mir z.B. ist es lieber, Bedingungen wie

1

if (i == 7) ...

nicht so

1

if (7 == i) ...

zu schreiben, obwohl es mir korrekt erscheint, dass die zweite 
Schreibweise einen Fehler wie

1

if (i = 7) ...

vermeidet.


Im übrigen ist es durchaus eine Ansichtssache, was unter "Stil" fällt. 
Der Wikipedia-Artikel nennt einige Regeln und (sogar) Paradigmen bzw. 
Entwicklungsmuster, die er "im weiteren Sinn" als "Stil" bezeichnet; 
also nicht im eigentlichen. Muss man sich überlegen, ob man so eine 
Abgrenzung für wichtig hält und wofür.

> nicht so: if (7 == i) ...

Dass dir das nicht gefällt, mag aber auch an deiner Muttersprache 
liegen.  Ein Japaner verteidigte mal diese Schreibweise damit, dass sie 
eher der japanischen Sprache entspricht (Wortreihenfolge im Satz) - 
klingt einleuchtend, weiß aber nicht, ob das tatsächlich so ist ;-)

Solange der TO nicht schreibt, wofür oder auf was er bewerten will, ist 
das alles hier.kaffesatzleserei.

Sollst Du für irgendwas oder irgendwen bewerten? Wird jemand anders 
bewerten? Dann nenne Ross und Reiter.

Willst du besser werden? Dann schreibe und lese Code, und ein paar gute 
Bücher. Zu beidem kannst Du auch konkret hier fragen.

Es kommt drauf an.
Bei Python wäre man schon froh, jeder würde sich an den PEP8-Guide 
halten.

Mark B. schrieb:
> Fehleingaben provozieren und das Ergebnis messen.

Das ist doch nur UI. Viel kritischer ist, das Laufzeitprobleme 
vernünftig behandelt werden. Sonst gibt es soetwas wie eine Ariane 5.2 
mit der bewährten Ariane 4 Software.

USS schrieb:
> wenn man als Anfänger seinen eigenen Code bewerten soll, welche
> Anhaltspunkte würdet ihr wählen?

das geht nicht. Anfänger können ihren eigenen Code nicht bewerten.

ihr gebt mir viel Input, was gut ist, aber einiges geht durcheinander.
Das Bild von dem Aufbau eines C-Programmes -> habe ich in öffentlich 
zugänglichen uochschulmaterila gefunden. Es stand keine Norm dabei oder 
ähnliches. Aber ich bezweifel, dass der prof sich das aus der Nase 
gezogen hat. Deswegen die Frage, ob es zu dem konkreten Beispiel eine 
Norm gibt
 Ansonsten erstmal vielen dank, lese mich ein und sonst melde ich mich 
nochmal

USS schrieb:
>> Anzahl der Maschienbefehle
> wie kann ich das in meinem konkreten Fall herausfinden?

Das bekommst du indirekt über Performance-Tests heraus, bei denen man 
nicht nur die Ausführungszeit sondern auch die CPU und Speicherlast 
berücksichtigt.

Mark B. schrieb:
> "Für nicht genutzte Rechenzeit gibt es kein Geld zurück." :-)

Das ist nur halb richtig. Denn schlafende Computer nehmen weniger Strom 
auf (nicht alle, aber die meisten). Und den vergangenen 20 Jahren haben 
Intel und AMD ihre x86 Prozessoren in dieser Hinsicht extrem verbessert.

Cyblord -. schrieb:
> Code wird in WTF / Minute bewertet.

Das ist witzig, aber auch richtig. Bringt es prägnant auf den Punkt.

USS schrieb:
> ihr gebt mir viel Input, was gut ist, aber einiges geht durcheinander.
> Das Bild von dem Aufbau eines C-Programmes -> habe ich in öffentlich
> zugänglichen uochschulmaterila gefunden. Es stand keine Norm dabei oder
> ähnliches. Aber ich bezweifel, dass der prof sich das aus der Nase
> gezogen hat. Deswegen die Frage, ob es zu dem konkreten Beispiel eine
> Norm gibt
>  Ansonsten erstmal vielen dank, lese mich ein und sonst melde ich mich
> nochmal

Aber lieber USS! Dann musst Du Deine Frage sorgfältiger formulieren.

Du hast ursprünglich gefragt:

"wenn man als Anfänger seinen eigenen Code bewerten soll, welche
Anhaltspunkte würdet ihr wählen?"

Das ist eine ganz andere Frage. Nämlich die woher Dein Prof. irgendein 
Bild hat und ob das aus einer Norm stammt.

Wenn hier irgendwas durcheinander geht, dann Deine Fragen.

Bitte habe Verständnis dafür, dass die Verständigen hier genau die Frage 
beantworten, die Du stellst. Nicht die, die Du nicht stellst.
Wir lesen keine Gedanken und unsere Glaskugeln sind alle beim polieren. 
:-)

Stefan ⛄ F. schrieb:
> Das bekommst du indirekt über Performance-Tests heraus, bei denen man
> nicht nur die Ausführungszeit sondern auch die CPU und Speicherlast
> berücksichtigt.

weiß ich nicht, wie so ein Test aussieht

Theor schrieb:
> Bitte habe Verständnis dafür, dass die Verständigen hier genau die Frage
> beantworten, die Du stellst. Nicht die, die Du nicht stellst.
> Wir lesen keine Gedanken und unsere Glaskugeln sind alle beim polieren.
> :-)

passt doch alles, die Frage hat sich  herauskristallisiert

https://www.informatik.uni-leipzig.de/~meiler/Propaed.dir/PropaedWS12.dir/Vorlesung.dir/V01.htm#_Toc272238785

also das was ich gepostet habe, entspricht in etwa dem ansi-standard?

Das alleinige Kriterium ist, ob der Code die Anforderungen erfüllt.
Code ist ja kein Kunstwerk, für das der Künstler beliebig viel Zeit 
investieren soll.

Alles was der Code erfüllen soll ist im Vorfeld festgelegt. z.B.
- maximaler Speicherbedarf
- Ausführungsgeschwindigkeit
- Reaktionsgeschwindigkeit
- Skalierung
- Fertigstellungstermin
- Kosten/Zeitaufwand

und nicht zuletzt auch firmeninterne Regelungen wie
- Coding-Style
- Variablenbenennungen
- Dokumentation
- Versionierung
- Testkriterien

Dann kannst z.B. ein Netzdiagramm machen, wie gut die einzelnen 
Anforderungen erfüllt sind.
Alles was nicht im Vorfeld festgelegt wurde, kann nicht in 
Qualitätsbetrachtungen eingehen.

Vincent H. schrieb:
> -) Zu große Einrückungstiefe

was spielt das für eine Rolle?

Vincent H. schrieb:
> Salopp gesagt heißt zu große Einrückungstiefe dass der Code zu komplex
> ist was Verzweigungen und Co angeht.

ah verstehe. tatsächlich habe ich, was das angeht, gut gepunktet

Michael B. schrieb:
> also die Anzahl der Maschienbefehle die (nicht der code lang ist sondern
> die) ausgeführt werden um das Problem (inklusive Fehlerbearbeitung) zu
> lösen.

Mit heutigen Prozessoren kann die Performance auch mal mit der Anzahl 
der ausgeführten Instruktionen steigen, ist also eher eine sinnlose 
Metrik. Gemessene Taktzyklen sind aussagekräftiger.

USS schrieb:
> Aber ich bezweifel, dass der prof sich das aus der Nase gezogen hat

Wenn es darum geht, Code für einen Prof zu schreiben: das hat nichts mit 
echten Code zu tun. Das wäre, als bewerte man ein Gedicht nach der 
Handschrift.

Die ganzen akademischen Regeln gelten für Code von genau dem Umfang 
(1000 Zeilen ). Und wenn der Prof an ungarischer Notation hängt, dann 
macht es den Code nicht besser, aber deine Zensur.

USS schrieb:
> weiß ich nicht, wie so ein Test aussieht

Kann man auch nicht pauschal sagen- Performance Tests sind immer sehr 
Anwendungsspezifisch und werden in der Regel selbst wiederum 
schrittweise entwickelt. An besten von einem separaten Team - nicht von 
den Programmierern.

A. S. schrieb:
> Und wenn der Prof an ungarischer Notation hängt, dann
> macht es den Code nicht besser, aber deine Zensur.

Genau, womit wie wieder darauf zurück kommen, dass der Code die 
Anforderungen des Kunden erfüllen muss. In diesem Fall ist der Professor 
der Kunde und auch derjenige, der Struktur und Stil vorgibt.

Als Entwickler orientiert man sich besser daran, was die Leute um einen 
herum haben wollen, als an irgendwelchen Standards. Über Standards 
sollte man genau so wie über eigene Ideen mit Team und ggf. Kunde 
diskutieren, bevor man sie umsetzt.