Unverständnis für ":" und "?"

Hallo an Alle,
Ich melde mich mal wieder zur späten Stunde, weil ich nun beim nächsten Thema bin und dieses mir wieder ein Brett gegen den Kopf haut.
Es geht im Allgemeinen um den Kontrollfuss. Jedoch ist bei dem folgenden Beispiel eine Notation aufgetreten, welche ich so noch nie gesehen habe. Gleichzeitig werde ich aus dem Internet und meinem Lehrbuch einfach nicht schlauer. Der Code lautet:
Java:
public static int c4(final int[] array) {
int count = 0;
for (final int element : array) {
if (element == 4) {
count++;
}
}
return count;
}
Dieser Code soll anscheinend ausgeben, wie oft die 4 in dem übergebenem Array vorkommt. Hätte ich dies lösen müssen, dann hätte ich das über for(int i = 0; i < array.length; i++)
gelöst und nicht über das kryptische ":". Wenn einer mir dieses ":" und das "?" erklären könnte, wäre ich überglücklich.

Beste Grüße
 
Wird solch eine Schreibweise eigentlich in der Praxis verwendet oder ist dies mittlerweile veraltet, weil ich konnte mir dadurch den objektorientierten Gedanken dabei nicht erschließen
 
Und das for-each wird nach meiner Erfahrung deutlich öfters verwendet als die Zählschleife. Wobei mein Blick sich vor allem auf der Anwendungsentwickung liegt.
 
weil ich konnte mir dadurch den objektorientierten Gedanken dabei nicht erschließen
Wo ist denn z.B. der objektorientierte Gedanke bei dem "+" Operator? Oder addierst du `1+2` per `new BigInteger("1").add(new BigInteger("2")).intValue()` ?
Der ternäre Operator ist ein Operator wie jeder andere auch: Er kann in Ausdrücken verwendet werden, um einen Wert zu generieren.
 
Meine persönliche Meinung zum ternären Operator:

- Er ist toll um solche Konstrukte zu vermeiden:

Java:
// Ohne
int i;
if (bedingung) {
  i = 1;
} else {
  i = 2;
}

// Mit:
int i = bedingung ? 1  : 2;
Das ist deutlich kürzer und wenn man sich dran gewöhnt hat, auch gut zu lesen.

Wo ich mich dem ternären Operator verweigere ist, sobald es verschachtelt wird oder der Code hinter dem Fragezeichen so lang wird, dass man die Übersicht verliert. Dann finde ich ihn extrem schwer zu lesen.

Bei den For-Schleifen stimme ich JustNobody vollkommen zu. Die for-each Schleife hat die mit dem Index fast vollständig verdrängt. (Und wird selber teilweise von streams verdrängt). Die Schleife mit Index wird eigentlich nur noch verwendet, wenn die anderen Varianten nicht gehen, weil man z.B. den Index für irgendwelche Berechnungen, Ausgaben etc. braucht
 
Also
a ? b : c;
ist äquivalent zu
if (a) { b } else { c }
wobei man aber dazu sagen muss dass b und c keine "void-Anweisungen" sein dürfen sondern zum Beispiel auch "Rückgabewerte" sein können.
Vergleich https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.25 und https://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.9 der "Conditional Operator ? :" erwartet einen Ausdruck und das "if Statement" erwartet ein Statement.

Ausdrücke dürfen nicht einfach so ohne Statement stehen,
Java:
		int ii = 0;
		int jj = 1;
		
		ii + jj;
wäre zum Beispiel Nonsense hoch 10.
 
Naja wie immer ist die Wahrheit nicht schwarz oder weiß sondern eher grau. Wer qualitativ guten Code schreibt ist produktiv, hingegen ist aber auch produktiv wer qualitativ schlechten Code schreibt aus der Sicht mancher. Damit geht einher dass eine Menge an Code Zeilen geschrieben wurde welche sich mit einer natürlichen Zahl angeben lässt und welche "von Wirtschaftlern" verstanden werden kann und als Maßgabe für eben jene Produktivität herangezogen werden kann. Andere Kriterien (Konventionen Clean Code best practices Patterns usw.) sind für Wirtschaftler vielleicht nicht so wichtig.
 
Ich denke, ich lehne mich nicht zu weit aus dem Fenster, wenn ich behaupte, dass kein Entwickler auf der Welt nach Anzahl geschriebener Codezeilen bezahlt wird. Das ist einfach nur schwachsinnig und auch absolut kein Maßstab bzw. keine zuverlässige Kenngröße für den Erfolg eines Unternehmens.
Ein Entwickler, der viel Code schreibt, trägt nicht mehr zum Erfolg eines Unternehmens bei, als ein Entwickler, der wenig Code schreibt.
Das einzig entscheidende ist, wie schnell man mit dem, was man produziert hat, live geht und somit Teil der Wertschöpfungskette wird und es dem Unternehmen so erlaubt, entweder mehr/besser/schneller zu verkaufen bzw. auch interne Geschäftsprozesse günstiger/schneller/zuverlässiger durchzuführen. Time-to-market!
Natürlich hat die Anzahl der Codezeilen hierauf aber einen Einfluss. Wenn viel Code geschrieben wird, dann muss unter Umständen auch viel Code getestet und später viel Code durch sich ständig ändernde Anforderungen refactored/umgeschrieben werden. Wenn überhaupt, dann sollten Entwickler, die wenig Code produzieren, dabei aber schnell mit dem Code live gehen, gut bezahlt werden.
 
Ich denke, ich lehne mich nicht zu weit aus dem Fenster, wenn ich behaupte, dass kein Entwickler auf der Welt nach Anzahl geschriebener Codezeilen bezahlt wird.
Ich habe zumindest mal von einer Firma gehört, in der die Entwickler angehalten wurden, die obligatorischen 50 LoC/d zu schaffen. Sozusagen als Fleißnachweis. Wer mal (oder mal öfter) weniger schrieb, wurde zum Chef zitiert.

Natürlich ist das völliger Quatsch, wenn ich aber sehe was manche Firmen sonst für Blüten treiben würde es mich wundern, wenn es sowas nicht gäbe.


Wenn überhaupt, dann sollten Entwickler, die wenig Code produzieren, dabei aber schnell mit dem Code live gehen, gut bezahlt werden.
Das ist auch keine gute Idee, ich habe den Verdacht daß das so bei Altium (CAD für Elektronik) gemacht wird. Einerseits führt das zwar zu kleineren Verbesserungen an vielen Stellen (was schön ist, da man während der Arbeit immer wieder kleine angenehme Neuheiten entdeckt). Leider werden größere Dinge dann aber umso seltener angefaßt und Funktionen bleiben lange unfertig.

Altium an sich steckt voller richtig guter Ideen, die aber leider nur halb zu Ende gedacht/umgesetzt sind, und das bleibt dann ziemlich lange so.
 
OMG! (Jahressoll an LoC erfüllt :D)

Zum Anderem, in der Produktion gibt es bei Stückzahlen (welche hergestellt oder verpackt werden, etc.) ja zum Beispiel den Akkordarbeitszuschlag. Das ist aber auch nicht so gut, weil diejenigen, die über einen längeren Zeitraum hinweg wesentlich mehr über der Soll-Stückzahl pro Stunde "liegen" und damit den Akkordarbeitszuschlag locker erreichen, dann von ihren Kolleginnen und Kollegen mindestens einen strafenden Blick kassieren... (das könnte als eine Art Mobbing gelten...)
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben