Ich habe in IDEA mal testweise das Semantic Highlighting eingeschaltet - erst mal eine ziemliche Umgewöhnung. Wie findet ihr das? Welche Farbschemata haben sich bewährt? Das Standard-Schema kommt mir bisher ziemlich flau vor:
Das sieht auf den ersten Blick bunt und wuselig aus. Aber ich arbeite auch mit dunkler Schrift auf hellem Grund, mag also auch mit daran liegen.
Den Beispiel-Screenshot von IntelliJ finde ich ziemlich unübersichtlich, aber das liegt wohl eher am Stil und nicht so sehr am Highlighting. Uncle Bob würde ihnen die Methode jedenfalls um die Ohren klatschen.
Vielleicht sollte es auch Ansporn sein zu refactorn, wenn es einem buchstäblich zu bunt wird 
Wer weiß, wieviele Aufrufparameter da rechts noch kommen…
Ich mag es, auf einen Blick sehen zu können, was ein Parameter, was eine Klassenvariable und was eine lokale Variable ist. Das würde durch die unterschiedliche Farbgebung wohl aufgelöst, oder gibt es unterschiedliche Farbsets für diese Zwecke?
Ich verwende das Darcula Design gerne. Wobei ich es in den Einstellungen auch ein entbuntet habe, aber an anderen Stellen wiederum stärker eingefärbt um Warnungen und Fehler bspw. besser hervorzuheben.
Ich glaube, das Semantic Highlighting greift nur für lokale Variablen. Im Job haben wir sowieso die Konvention, Klassenvariablen mit _ zu präfixen (was ich inzwischen ganz praktisch finde), deshalb wäre mir das sowieso egal.
Das ist sogar eine sehr pythonische Konvention. 
Bei JavaScript habe ich das auch schon für „private“ (ahem…) Felder gesehen.
OT: Weil es dort nicht oder nur schwer anders geht. In einer Sprache, die echte Kapselung unterstützt, ist das doch ein Graus. (Warum nicht gleich das klassische m_ für „Member“? Und interfaces am besten noch mit I prefixen…).
On-Topic: Ich könnte danach suchen, kapier’ aber durch draufschauen erstmal nicht, nach welchen Kriterien die Farben vergeben werden. Also erstmal die klassische Reaktion bei visuellen Änderungen: „Kenn isch net. Mag isch net.“ 
Finde ich nicht, die Logik dahinter ist ja ähnlich wie bei JS: Es sieht hässlich aus → ist intern und soll nicht von draußen benutzt werden. Man spart sich auch das this., aber wichtiger ist, dass man bei Überladungen von Variablen jeden Fehler ausschließt (sowas in der Art: Jemand definiert eine lokale Variable mit gleichem Namen wie eine Membervariable, und bemerkt nicht, dass selbige weiter unten im Codeblock schon vorkommt).
Der Vergleich mit dem Interfaces-I hinkt: Wenn der Nutzer meines Codes wissen muss, ob er gerade eine Klasse oder ein Interface in der Hand hält, ist beim Design etwas mächtig schief gelaufen (außer in den wenigen Fällen, wo der Anwender wirklich von etwas ableiten muss).
Die Farben werden einfach der Reihe nach den verschiedenen Variablen zugewiesen, wer was bekommt, hat keine Bedeutung, nur dass die Vorkommen einer Variable leicht zu erkennen sind.
Nun, hier über code conventions zu streiten macht wohl keinen Sinn, ich fand nur, dass (gerade) JavaScript, die Hippie-Sprache in der jeder macht, was er will, da nur bedingt als Referenz herhalten kann. (Ja, über Sprachen zu streiten macht noch weniger Sinn 
)
Also on Topic: Man müßte es sich wohl mal „live“ mit mehreren Variablen ansehen (im Moment frage ich mich, ob sich dann tatsächlich die Farbe einer Variable ändert, wenn man z.B. einen neuen Parameter hinzufügt). Aber auch konzeptuell: Wenn man auf irgendeiner Konferenz zu irgendeinem Thema, das mit „Graphik“ zu tun hat, ein Paper einreicht, bei dem nicht jedes Farbschema von jedem x-beliebigen Bar-Chart zumindest mit GitHub - rcsb/colorbrewer: Create color blind friendly color palettes in Java & Co. begründet ist, kriegt man das von den Reviewern um die Ohren gehauen - und in der IDE soll man auf einmal zwischen 0x007060 und 0x006070 unterscheiden können? Hm… (Das ist erstmal nur ein Hinterfragen. Vielleicht ist es ja total toll, wenn man es „live“ verwendet. Aber bei Farben ist weniger manchmal mehr…)
Das ist wie Malen nach Farben. 
Ehrlich mir gefällt es auch nicht, auch das 
vermittelt einen mathematischen Eindruck. Eine Programmierung hat aber mit Mathe nix zu tun(*). Der Zeichensatz sollte bei ASCII bleiben!
Also ich finde es auch zu bunt, eine Vielzahl von Farben (=> übersteuerte visuelle Wahrnehmung), zu unübersichtlich, und die Semantik erschließt sich mir auch nicht schneller.
(*): Darüber könnte man sich jetzt streiten, aber es passt nicht zum Thema. Gehören Algorithmen zu Mathe?
Im Problemfenster war gerade eine Warnung auf ein uraltes Codestück “toString wird auf einem Array ausgeführt, meist ist in diesen Fällen der Inhalt der Arrays aber nicht das Array selbst gemeint.”
Semantic Highlighting eingeschaltet, saß ich 5 Minuten davor um das toString() zu finden weil der Cursor und das Highlighting einfach unterging unter all den anderen Farben.
(Kein Bild, bin hinter einem Proxy - aber wer es selber ausprobieren möchte)
if( BuildConfig.DEBUG )
Look.checkGLErrors( "Delete All Textures" );
for( int[] textureIDs : hsImages.values() ) {
Log.v( "Dispose OpenGL", "Delete Texture " + textureIDs );
GLES31.glDeleteTextures( textureIDs.length - 2, textureIDs, 2 );
if( BuildConfig.DEBUG )
Look.checkGlErrors( "glDeleteTextures" );
}
Log.d( "Dispose OpenGL", "Textures Deleted" );Naja der Zeichensatz bleibt ja bei Ascii, das was du da ankreidest nennt man Ligaturen und wird nur auf der Präsentationsschicht verwendet.Verwende z.B. FiraCode sehr gerne, da dort eine Ligatur die zwei Zeichen zusammenfasst dann auch noch immer die breite von zwei Zeichen hat. Also in summe ist dort noch immer alles Monospaced
Bzgl des Semantic highlighting wird mir der Code zu bunt. zumindest in dem Bsp. Leider gibt es das Semantic Highlighting nicht für Scala dadurch kann ich es bei mir auf der Arbeit nicht an einem realen Beispiel testen.
Hallo? Berechenbarkeit (Lambda-Kalkül, Tuningmaschine…), Kategorien-Theorie, Curry-Howard-Lambek-Isomorphismus…
Keine Ahnung haben, aber erst mal meckern! Gute Erklärung von @AmunRa.
Wobei es auch Sprachen gibt, die es da bunter treiben, und tatsächlich Nicht-ASCII verwenden (Fortress käme mir da in den Sinn)
1 „Gefällt mir“