Suche einen Namen für Funktion

light_to_weight();

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'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

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.

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?

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);

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?

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 :-)

Mist. Wie kriege ich jetzt den Kaffe vom Monitor? :)

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.

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 :-)