Hallo, Für ein kleines µC-Projekt suche ich einen guten Namen für eine Funktion. Aus einer gemessenen (Licht-)Intensität I soll eine Masse M prognostiziert werden (dursichtiger Behälter wird mit dunkler Flüssigkeit gefüllt, Kamera misst Intensität). Dazu gibt es eine aus Erfahrungswerten "gefittete" Funktion f: M = f(I). Ich suche nun einen guten Namen für diese Funktion (meinetwegen auch englisch). Ich habe erst an "Transfer-", "conversion-" oder "Übertragungsfunktion" gedacht, aber das hört sich alles falsch an. Über Ideen bin ich sehr dankbar.
intensity_to_mass GetMassFromIntensity ... je nachdem, ob man Unter_striche oder CamelCase mehr mag.
Martin schrieb: > Ich suche nun einen guten Namen Ich war immer der Meinung, gute Programmierer müssten kreativ sein.
Martin schrieb: > Dazu gibt es eine aus > Erfahrungswerten "gefittete" Funktion f: M = f(I). estimated_mass();
Falk B. schrieb: > i2m(); YMMD Mal im Ernst, ein SW Entwickler fragt in einem Forum nach einem Funktionsnamen an? Und ihr nehmt diese Anfrage ernst? Macht mal ne Rechnung auf: Wie viele Funktionen schreibt er durchschnittlich pro Tag? Wird er jetzt alle halbe Stunde den nächsten Namen erfragen? Kopfschüttel
Reinhard #. schrieb: > Ich war immer der Meinung, gute > Programmierer müssten kreativ sein. Der TO hatte jedoch weder behauptet noch impliziert, gut zu sein - daraus vermag nun jeder selbst seine Schlüsse zu ziehen ;-) On topic: Falk B. schrieb: > Wenn man's klassisch ala K&R C-Style machen will > > i2m(); Ich hätte eher itom() vorgeschlagen...
Wenn man fuer die NSA programmiert nimmt man nichtssagende Namen wie Suzi oder Hugo. :=)
Martin schrieb: > Aus einer gemessenen (Licht-)Intensität I soll eine Masse M > prognostiziert werden (dursichtiger Behälter wird mit dunkler > Flüssigkeit gefüllt, Kamera misst Intensität). Bei der quantitativen Analyse im Chemielabor wird ein vergleichbares Verfahren als "Messung der Extinktion" bezeichnet. Vllt. gibt es hier noch eine Idee für einen guten Funktionsnamen: Extinktion (Optik): https://de.wikipedia.org/wiki/Extinktion_(Optik) Messprinzip in der Absorbtionsspektrometrie: http://www.uni-bielefeld.de/chemie/lehre/basispc/media/Spektrometer/
:
Bearbeitet durch User
>Wenn man's klassisch ala K&R C-Style machen will >i2m(); Ja, so hat man das vor 40 Jahren gemacht. Heute macht man es anders. In diesem Buch gibt es die Analyse eines Softwareprogrammieres mit der er herauszufinden versucht, was er am meisten am Computer macht. https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html Das Ergebnis: Rauf und runter scrollen und Code lesen. Die Schlussfolgerung: Code muss lesbar sein wie ein Buch. Deshalb ist das Refactoring ganz wichtig, mit dem man die Lesbarkeit ständig verbessert. Kommentare: sind verboten. Der Code muss selberklärend sein. schlechte Beispiele: i2m(x); // wandelt eine Lichtintesität in eine Masse um ledOn(); // schaltet die Leutdiode ein reset(); // macht einen Reset wait(); // wartet
@Rufus Τ. Firefly (rufus) (Moderator) >SoftwareArchitekt schrieb: >> Kommentare: sind verboten. Der Code muss selberklärend sein. >Hust. Dogmen waren schon immer Mist ;-)
SoftwareArchitekt schrieb: > Kommentare: sind verboten. Der Code muss selberklärend sein. Das ist zu allgemein formuliert. Kommentare die beschreiben was der code macht sollten durchaus verboten sein, immerhin steht ja schon in Form von ausführbarem Code schwarz auf weiß dort was er macht. Jedoch sollte man schon hier und da mal erklären warum man was macht (wenns nicht gerade offensichtlich ist), oder warum gerade so und nicht anders, oder in ein paar knappen Sätzen (in nem Block der sich schön von Doxygen extrahieren lässt) grob zusammenfassen was denn überhaupt erreicht werden soll.
:
Bearbeitet durch User
1 | void checkForCommentProportion( uin32_t linesOfCode, uint32_t linesOfComments ) |
2 | {
|
3 | if( ( (float) linesOfComments / linesOfCode ) >0.01 ) |
4 | {
|
5 | informCoder(" please reduce the number of comment lines "); |
6 | informCoder(" due to high risk of code function and comment mismatch "); |
7 | informCoder(" refactor your code for better readability "); |
8 | }
|
9 | }
|
SoftwareArchitekt schrieb: > Kommentare: sind verboten. Der Code muss selberklärend sein. Ok, dann nenn die function emacs(); //Eats Memory And Corrupts System oder fullofbugs(); Aber das wäre nicht nur selbsterklärend sondern auch ehrlich - wer kann das schon aushalten ;-)
Also wenn das so schwierig ist mit den Namen, dann empfehle ich den Rückschritt zu einem BASIC mit Zeilennummern und gosub.
MagIO2 schrieb: > Also wenn das so schwierig ist mit den Namen, dann empfehle ich den > Rückschritt zu einem BASIC mit Zeilennummern und gosub. Genau so! Das erfüllt dann auch gleich diese Bedingung: SoftwareArchitekt schrieb: > Code muss lesbar sein wie ein Buch. Rufus Τ. F. schrieb: > Hust. Dagegen gibt es doch bestimmt Etwas von Ratiopharm... :)
SoftwareArchitekt schrieb: > Kommentare: sind verboten. Der Code muss selberklärend sein. In den meisten Fällen sehe ich das auch so. Allerdings gibt es durchaus Ausnahmen von dieser Regel. Beispiele: Ich kommentiere grundsätzlich sehr ausführlich alle Workarounds um den Müll, den andere verzapft haben und der sich von mir nicht oder nur mit sehr hohem Aufwand wirklich beheben liesse. Auch alles, was in sich bekannt unlogisch ist, aber worauf der Kunde einfach mal unbeirrbar wider jede Vernunft bestanden hat. Das erleichtert es dann, wenn der Kunde nach einem viertel oder halben Jahr (wie zu erwarten) mit der Forderung nach einer kostenlosen Nachbesserung angeschissen kommt, den Schaden zu beheben. Man muss sich dann nicht wieder neu in das Thema reindenken. Natürlich kriegt der Kunde die Nachbesserung trotzdem nicht kostenlos, denn ausser dem Kommentar im Quelltext sorgt man natürlich auch dafür, dass die Beratung für eine logisch konsistente Lösung und deren Ablehnung durch den Kunden aktenkundig ist. So generiert man leicht verdientes Geld, was sich obendrein praktisch fast fest einplanen läßt... Auch Shortcuts kommentiere ich ausführlich. Also Sachen, wo man unter Ausnutzung bestimmter Randbedingungen wesentlich effizienteren/kürzeren Code schreiben kann, als normalerweise an dieser Stelle anfallen würde. Das ist sehr hilfreich, wenn bei späteren Erweiterungen des Codes diese Randbedingungen plötzlich teilweise oder gar ganz wegfallen... Wenn ich noch eine Weile nachdenke, fallen mir wahrscheinlich noch einige weitere Sachen ein, wo man Kommentare durchaus benutzen sollte. Fakt ist jedenfalls: die stupiden halbautomatischen Kommentare, die heutzutage en vogue sind und aus denen dann vollautomatisch eine angeblich hinreichende Dokumentation generiert werden können soll, sind meistens völlig nutzlos, genauso wie die daraus generierte "Dokumentation". Das ist völliger Bullshit. Was dokumentiert werden muss, ist das Konzept, was hinter dem Code steht. Der Rest steht im Code selber und muss nicht nochmal in Prosa ausgedrückt werden.
SoftwareArchitekt schrieb: > Kommentare: sind verboten. Der Code muss selberklärend sein. Ganz streng gehört verboten, die Argumente zu spezifizieren: Ist die Zeit in Clockticks, in µs oder in jiffies anzugeben? Ist das Ergebnis in mg oder lbs? Besonders wichtig finde ich auch, häufige Funktionen oder Methoden möglichst langatmig zu benennenn: fopen() -> Böse OpenFileOrPipeInStdioStyleReturningFILEPointerOrNull() -> Übersichtlich! Dann wird es auch zeit, diese unlesbar kryptischen Operatoren endlich DeutLichLesbar hinzumalen: LET TargetVariable BeEqual 32 AddIntegers 4 Subtract 2 DivideBy 3 SemiColon COBOL hat das ja schon mal recht gut vorgemacht. COBOL-Programmierer haben einen sicheren Job.
1 | double calculateMass_Kg( double intensity_w_per_qm ); |
oder das Beispiel von Frank ( i2m ) ausgeschrieben:
1 | double intensityToMass_Kg( double intensity_W_per_Steradiant ) |
Die beiden großen Probleme der Informatik: Cache-Ungültigkeitserklärung und Namen finden. https://martinfowler.com/bliki/TwoHardThings.html
Martin schrieb: > Erfahrungswerten "gefittete" Funktion f: M = f(I). > > Ich suche nun einen guten Namen für diese Funktion (meinetwegen auch > englisch). "gefittete" und dann unschlüssig über die Sprache?
SoftwareArchitekt schrieb: > https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html Hast du das Buch gelesen? Ich auch nicht. Aber ich habe mir wenigstens das Inhaltsverzeichnis angeschaut. Das Kapitel "Kommentare" umfasst immerhin 14 Seiten, was darauf hindeutet, dass das Thema etwas komplexer ist als du es hier darstellst: > Kommentare: sind verboten. :)
Alexander T. schrieb: > Ganz streng gehört verboten, die Argumente zu spezifizieren: Ist die > Zeit in Clockticks, in µs oder in jiffies anzugeben? Ist das Ergebnis in > mg oder lbs? Das wäre eigentlich ein prima Anwendungsgebiet für ein starkes Typsystem, dann könnte man das zur Compilezeit erzwingen, bräuchte es nicht zu dokumentieren und es würden weniger Raumsonden in Planeten krachen.
Martin schrieb: > Für ein kleines µC-Projekt suche ich einen guten Namen für eine > Funktion. Hmm. wie wärs mit: double Herbert(double Bernd);
Urmel schrieb: > Die beiden großen Probleme der Informatik: Cache-Ungültigkeitserklärung > und Namen finden. > > https://martinfowler.com/bliki/TwoHardThings.html da fehlen noch die "off-by-one" Fehler ;-)
Sieh es mathematisch. Es ist eine Funktion. Nenne sie f. Gibt es im aktuellen Kontext bereits eine Funktion namens f, hänge einen nullbasierten Zähler auf Zahlenbasis deiner Wahl (möglichst nicht 2, 8, 10 oder 16) an und zähle so lange hoch, bis der Name eindeutig wird. Herzlichen Glückwunsch, Du hast Deinen Funktionsnamen gefunden. Is doch echt nicht so schwer, oder?
Ich würde die Funktion einfach "Lichtmassendings" nennen... :-) Kommentare sind wichtig, vor allem wenn mal wieder ein total genialer Gedanke verwirklicht wird der so irre Genial war das man ihn ein viertel Jahr selber erst nach 2h analyse wieder durchschaut...
Und noch viel irre genialer sind die Gedanken, bei denen man nach 2h Analyse denkt, es gäbe eine viel einfachere Lösung. Die einfache Lösung 1d lang implementiert und am Ende feststellt, dass sie genauso umfangreich, wie die ursprüngliche Lösung geworden ist ;) Von daher: Sinnvolle Kommentare sind absolut nichts Böses und sogar erstrebenswert.
In der idealen Welt der Lehrbücher wie z.B. CleanCode ist das alles ganz einfach. Da ist jede Zeile Code selbsterklärend und selbst ein Dreizeiler wird schon als zu komplex definiert, den man doch bitte in mehrere Funktionen unterteilen soll. In der Realität sieht die Sache leider nicht immer so einfach wie bei den Trivialbeispielen in den Lehrbüchern aus, insofern (und weil man in der Realität einen Termin hat und nicht noch 10 Runden Refactoring einlegen kann) helfen Kommentare sich zu erinnern WARUM man etwas genau so programmiert hat. Während jetzt die Verfechter der reinen Lehre noch so lang weiter laborieren, bis die Geschäftsleitung mangels Erfolg den Geschäftsbereich einstampfen, haben wir mit der nichtidealen aber zufriedenstellend performant und fehlerfrei laufenen Software dann schon ein Dutzend Kunden. Jobst M. schrieb: > Emc²() Das war der beste :-)
SoftwareArchitekt schrieb: >
1 | >
|
2 | > void checkForCommentProportion( uin32_t linesOfCode, uint32_t linesOfComments ) |
3 | > { |
4 | > if( ( (float) linesOfComments / linesOfCode ) >0.01 ) |
5 | > { |
6 | > informCoder(" please reduce the number of comment lines "); |
7 | > informCoder(" due to high risk of code function and comment mismatch |
8 | > "); |
9 | > informCoder(" refactor your code for better readability "); |
10 | > } |
11 | > } |
12 | >
|
13 | >
|
Division by zero error in line 3.
Die Suche nach eine vernünftigen Funktionsname ist in der Tat selten einfach. Nach Kommentaren zu verlangen ist eigentlich ein ganz anderes Thema. Schlechte Programmierer hadern nicht so lange an den Funktionsnamen, gute schon eher, da diese wissen das Quelltext auch von Menschen gut lesbar sein muss.
AS7 schrieb: > Schlechte Programmierer hadern nicht so lange an den Funktionsnamen, > gute schon eher, da diese wissen das Quelltext auch von Menschen gut > lesbar sein muss. Wenn er seit Gestern 14:53 immer noch an dem Namen einer Funktion hängt, dann sollte er den Beruf wechseln.
Roflmops schrieb: > Wie kriege ich jetzt den Kaffe vom Monitor? :) 1. Komplett weißen Inhalt anzeigen. 2. Foto mit ausreichender Auflösung machen. 3. Foto invertieren. 4. Pixelgenaue Gammakorrektur durchführen. Gruß Jobst
AS7 schrieb: > Die Suche nach eine vernünftigen Funktionsname ist in der Tat selten > einfach. Für Unbeteiligte, die die Namenskonvention im Programm nicht kennen, ist es noch viel schwieriger.
>SoftwareArchitekt schrieb: >> >>
1 | >> void checkForCommentProportion( uin32_t linesOfCode, uint32_t linesOfComments ) |
2 | >> { |
3 | >> if( ( (float) linesOfComments / linesOfCode ) >0.01 ) |
4 | >> { |
5 | >> informCoder(" please reduce the number of comment lines "); |
6 | >> informCoder(" due to high risk of code function and comment mismatch |
7 | >> "); |
8 | >> informCoder(" refactor your code for better readability "); |
9 | >> } |
10 | >> } |
>> >> Autor: Eric B. (beric) >Division by zero error in line 3. Danke. Das zeigt, wie gut Code ohne Kommentare lesbar sein kann und gleich verstanden wird :-)
SoftwareArchitekt schrieb: > Danke. > Das zeigt, wie gut Code ohne Kommentare lesbar sein kann und gleich > verstanden wird :-) Ist ja auch sehr komplex ... 10 PRINT "HALLO" 20 GOTO 10 benötigt auch keine Kommentare ... Gruß Jobst
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.