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

[Mika34]

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:

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

 

[thecain]

wo siehst du ein '?' ?

Das : ist ein foreach loop. Das ist das Selbe wie deine Lösung

 

[Mika34]

Ein "?" kam in einem anderen Beispiel und da habe ich auch nicht verstanden, was dies zu bedeutet hat

 

[Javinner]

@Mika34 Trenärer Operator

 

[M.L.]

Könnte es sich um einen ternären Operator handeln: https://www.baeldung.com/java-ternary-operator ?

 

[Mika34]

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

 

[Javinner]

Wird solch eine Schreibweise eigentlich in der Praxis verwendet oder ist dies mittlerweile veraltet

Ist superbequem, kürzer und einfacher zu lesen, als eine if-else-Anweisung, probier es doch selbst kurz aus.

 

[kneitzel]

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.

 

[httpdigest]

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.

 

[LimDul]

Meine persönliche Meinung zum ternären Operator:

- Er ist toll um solche Konstrukte zu vermeiden:

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

 

[White_Fox]

- Er ist toll um solche Konstrukte zu vermeiden

Er ist nur schlecht wenn man nach Codezeilen bezahlt wird. 😛

 

[LimDul]

Er ist nur schlecht wenn man nach Codezeilen bezahlt wird. 😛

Gibt es sowas noch ernsthaft?

 

[Xyz1]

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,

		int ii = 0;
		int jj = 1;
		
		ii + jj;

wäre zum Beispiel Nonsense hoch 10.

 

[Xyz1]

Genauer ist
d = a ? b : c;
äquivalent zu
d; if (a) { d=b; } else { d=c; }
.

 

[White_Fox]

Gibt es sowas noch ernsthaft?

Es gibt genug Dinge, die es nicht geben sollte. Und immerhin ist die Einheit LoC/d eine Größe, die wirklich jeder Wirtschaftler versteht. (Nichts gegen Wirtschaftler im Allgemeinen.)

 

[Xyz1]

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.

 

[httpdigest]

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.

 

[CSHW89]

Ich glaube, er weiß, wie man gut verdient:
https://github.com/AceLewis/my_first_calculator.py/blob/master/my_first_calculator.py

 

[White_Fox]

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.

 

[Xyz1]

Ich glaube, er weiß, wie man gut verdient:
https://github.com/AceLewis/my_first_calculator.py/blob/master/my_first_calculator.py

OMG! (Jahressoll an LoC erfüllt 😀)

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

 

[mihe7]

Ich glaube, er weiß, wie man gut verdient:
https://github.com/AceLewis/my_first_calculator.py/blob/master/my_first_calculator.py

public class Goldesel {
    public static void main(String[] args) {
        System.out.println(
            "# my_first_calculator.py by AceLewis\n"+
            "# TODO: Make it work for all floating point numbers too\n\n"+
            "if 3/2 == 1:\n"+
            "    input = raw_input\n\n"+
            "print('Welcome to this calculator!')\n" +
            "print('It can add, subtract, multiply and divide whole numbers from 0 to 50')\n"+
            "num1 = int(input('Please choose your first number: '))\n"+
            "sign = input('What do you want to do? +, -, /, or *: ')\n"+
            "num2 = int(input('Please choose your second number: '))\n");

        char[] operators = {'+','-','/','*'};
        for (char op : operators) {
            for (int num1 = 0; num1 <= 50; num1++) {
                for (int num2 = 0; num2 <= 50; num2++) {
                    System.out.printf("if num1 == %d and sign == '%c' and num2 == %d:\n", num1, op, num2);
                    String result = "Inf";
                    switch (op) {
                        case '+': result = "" + (num1+num2); break;
                        case '-': result = "" + (num1-num2); break;
                        case '*': result = "" + (num2*num2); break;
                        case '/': result = num2 == 0 ? "Inf" : Double.toString(num1/(double)num2); break;
                    }
                    System.out.printf("    print(\"%d%c%d = %s\")\n", num1,op,num2,result);
                }
            }
        }
        System.out.println("\nprint(\"Thanks for using this calculator, goodbye :)\")");
    }
}

$ java -cp . Goldesel | wc -l
20822

--> passt 🙂

EDIT: Code geändert... printf -> print - Python...

 

[kneitzel]

Ja, du musst nur aufpassen: Jeden Tag nur um einen festen Wert erhöhen. Nicht dass Du ausversehentlich immer verdoppelst oder so - das fällt sonst sehr schnell auf ....

"Was hast Du heute gemacht?"
"Ich habe den Calculator erweitert - er rechnet nun mit Zahlen bis zu 10.350 statt nur bis 10.300 wie gestern ... morgen erweitere ich es dann auf bis zu 10.400."

Gutes Einkommen. Bis Du den Calculator fertig hast (er den Integer Bereich voll abdeckt) hast Du noch genug Arbeit bis zur Rente 🙂

 

[LimDul]

Mal übrigens ganz davon abgesehen, dass LoC sich nicht sinnvoll messen lässt.

Klar, wenn ich komplett neuen Code schreibe, geht das. Aber was ist mit Änderungen? Was ist wenn ich Rahmen einer Änderung alte Zeilen lösche? Was ist wenn ich Zeile mehrfach anfasse? etc.

 

[kneitzel]

Mal übrigens ganz davon abgesehen, dass LoC sich nicht sinnvoll messen lässt.

Klar, wenn ich komplett neuen Code schreibe, geht das. Aber was ist mit Änderungen? Was ist wenn ich Rahmen einer Änderung alte Zeilen lösche? Was ist wenn ich Zeile mehrfach anfasse? etc.

Wenn Du Zeilen löschst, dann wird Dir das natürlich vom Gehalt abgezogen ....

Also arbeite für mich - da darfst Du dann auch viel Geld mitbringen und mir zahlen 🙂

 

[mihe7]

Also arbeite für mich - da darfst Du dann auch viel Geld mitbringen und mir zahlen

Aha, arbeite für @JustNobody und das Geld verschwindet JustNowhere 😛

 

[TM69]

Wenn Du Zeilen löschst, dann wird Dir das natürlich vom Gehalt abgezogen ....

Also arbeite für mich - da darfst Du dann auch viel Geld mitbringen und mir zahlen 🙂

Au sch... dann darf ich ja gar keine Optimierungen mehr durchführen 🙁

😀😀😀😀😀😀😀😀

 

[Meniskusschaden]

Au sch... dann darf ich ja gar keine Optimierungen mehr durchführen 🙁

😀😀😀😀😀😀😀😀

        if (Math.random()<0) {
            // alter Code
        } else {
            // optimierter Code
        }

😉

 

[TM69]

        if (Math.random()<0) {
            // alter Code
        } else {
            // optimierter Code
        }

😉

Das stimmt, man schreibt möglichst immer gleich optimierterten Code. Leider sind Vorgänger oder andere Teammitglieder nicht so einsichtig 😀😀😀

 

[kneitzel]

Das stimmt, man schreibt möglichst immer gleich optimierterten Code. Leider sind Vorgänger oder andere Teammitglieder nicht so einsichtig 😀😀😀

Also was meinst Du mit "optimierten Code"? Wenn es bei Optimierung hier auch um Laufzeit gehen sollte, dann wäre meine klare Aussage: "Don't do it" bzw. "Don't do it (yet)".
Siehe z.B. https://clean-code-developer.de/die-grade/roter-grad/#Vorsicht_vor_Optimierungen

Wenn hier optimierter Code lediglich für clean code stehen sollte: Ja, dem stimme ich zu hätte aber andere Worte benutzt.