spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Seit Visual Studio 2012.

Die ganzen intelligenten Zeiger im "memory"-Header gibt es schon mindestens seit 2010 (Version 10).
Defintiv. Ich habe zwar vor, demnächst umzusteigen, aber noch nutze ich selber die 2010er Version. Auch mit "unique_ptr".

Gut zu wissen. Ich habe meist den boost:shared_ptr genutzt. Aber viele C++ Projekte habe ich bislang sowieso nicht.

Coffeescript hat mich gerade echt zum Schmunzeln gebracht. Für alle die Coffeescript nicht kennen, es ist eine Sprache die in JavaScript compiliert wird und damit einige Schwächen von JavaScript ausmerzen möchte.

Nach der Zeile

ist logged_in nicht etwa true oder false wie man es in anderen Sprachen kennt, sondern:




Da hat sich der in Coffeescript hinzugefügte Existenzoperator den Ausdruck gekrallt.

Schon alleine die Zeile

ist ein WTF wert

Zitat von »patrick246«

Schon alleine die Zeile
Quellcode
logged_in = data ? true : false
ist ein WTF wert

Ich denke das kann durchaus sinnvoll sein. "logged_in" soll wahrscheinlich die Rolle eines Boolean übernehmen und "data" muss nicht unbedingt true oder false sein. Bei der späteren Verwendung von "logged_in" spart man sich dann die eine oder andere Überraschung.

Aber data soll sich ja wohl anscheinend als bool auswerten lassen, also würde
ja reichen

Zitat von »Sylence«

Aber data soll sich ja wohl anscheinend als bool auswerten lassen, also würde
Quellcode
logged_in = data
ja reichen

Nein, da CoffeeScript nicht typisiert ist. Wenn "data" z.B. ein Object ist würde man dieses in "logged_in" speichern.

Zitat von »hetzge«

Zitat von »Sylence«

Aber data soll sich ja wohl anscheinend als bool auswerten lassen, also würde
Quellcode
logged_in = data
ja reichen

Nein, da CoffeeScript nicht typisiert ist. Wenn "data" z.B. ein Object ist würde man dieses in "logged_in" speichern.

Genau, in data steht die Antwort eines REST Endpoints, der die Informationen des aktuell angemeldeten Benutzers zurückgibt. Ist kein Benutzer angemeldet, werden keine Daten geschickt.

Allerdings ist mir durch die Einwände aufgefallen das es über den HTTP Status eleganter geht.

Selbst wenn es nicht am HTTP-Code festgemacht werden könnte, wäre es (meiner Meinung nach) etwas besser (/lesbarer), wenn man mit dem Wert prüft, den man an dieser Stelle erwartet (null oder undefined im Falle von JavaScript).
Ist einem die Lesbarkeit nicht besonders wichtig, kann man auch durch doppelte Negation (!!data) an die boolsche Repräsentation kommen.
Auf den HTTP-Code einzugehen ist da natürlich durchaus eleganter.

Zitat von »Sacaldur«

Selbst wenn es nicht am HTTP-Code festgemacht werden könnte, wäre es (meiner Meinung nach) etwas besser (/lesbarer), wenn man mit dem Wert prüft, den man an dieser Stelle erwartet (null oder undefined im Falle von JavaScript).
Ist einem die Lesbarkeit nicht besonders wichtig, kann man auch durch doppelte Negation (!!data) an die boolsche Repräsentation kommen.
Auf den HTTP-Code einzugehen ist da natürlich durchaus eleganter.

Danke für den Tipp mit der doppelten Negation. Das wusste ich noch nicht. Im Falle von JavaScript müsste man tatsächlich jede Situation testen (null, undefined, empty usw.). Ob das besser lesbar wäre als die CoffeeScript Variante ist sicher ein streitbares Thema wo es um persönliche vorlieben geht. Mit "if(data)..." wird für mich einfach geprüft ob es sich um eine brauchbare Variable handelt mit der ich weiter arbeiten kann. Klarer kann man das eigentlich nicht ausdrücken. Man muss sich natürlich darüber im klaren sein was alles unter die CoffeeScript-"Wahrheit" fällt.