J o: Programmfluss Node.js (asynchron) regeln

Beitrag lesen

Moin,

check() sollte natürlich auch erst aufgerufen werden wenn der asynchrone Task beendet ist, zum Beispoiel im Callback einer MySQL abfrage. Dachte das ist ersichtlich.

War es (mir) anscheinend nicht. Aber ja, so kann es gehen. Jedenfalls, wenn man nicht bereits mit Promises arbeitet oder mit Funktionen, die Promises liefern. In dem Fall wäre es sinnvoller, bei den Mechanismen der Promises zu bleiben, die ja eine Antwort auf das Problem bereits mitbringen.

Gut, ich habe noch nicht mit Promises gearbeitet da ich meine Asynchronen Funktionen eben mit Callbacks oder dieser "Wasserfall"-Schleife abgearbeitet habe.

Ob das jetzt b oder cancel heißt, wo ist der unterschied? Falls check( true ) aufgerufen wird bricht die Schleife ab und es wird der Callback aufgerufen.

Und das muss ich erst aus dem Code lesen, denn ein einfaches b sagt mir das nicht. Voraussetzung ist auch, dass der Code das macht, was er soll. Wenn da ein Fehler drin ist, kann unter Umständen die eigentliche Intention aus solchen Abkürzungen nicht hervorgehen. Das macht es dann nicht unbedingt leichter, den Fehler zu eliminieren.

Natürlich muss man das aus dem Code lesen was eine Funktion tut, wenn man denn nicht weiß was sie tut oder tun soll. Bei mir sieht die Funktion auch etwas anders aus, ich hab sie ja schon für die Leserlichkeit etwas aufgeweitet:

aFE: function(o,d,c){var i=0,k=Object.keys(o),v=Object.values(o);function p(b=false){i++;if(i===Object.keys(o).length||b===true){if(typeof(c)==='function'){c();}}else {d(k[i],v[i],p);}}d(k[i],v[i],p);}

Aber ihr habt Recht, nur weil ich weiß was mein Code tut, heißt das nicht das ihr ihn verständlich lesen könnt. Aber dafür ist Code auch nicht da, dass er Menschen lesbar ist und sich jeder direkt darunter etwas vorstellen kann, denn Code ist und bleibt eine Maschinen Sprache. Erst wenn es um das lernen bzw. erklären geht, muss Code greifbar und verständlich lesbar sein.

Gruß
Jo