Path: csiph.com!aioe.org!BKV6fg769rZhHiF5T3QFKA.user.gioia.aioe.org.POSTED!not-for-mail From: Wanja Gayk Newsgroups: de.comp.lang.java Subject: =?UTF-8?B?UmU6IFRocmVhZC5zbGVlcCgpIGjDpGx0IGRlbiBUaHJlYWQgbmljaHQgYW4=?= Date: Fri, 18 Dec 2020 01:25:33 +0100 Organization: Aioe.org NNTP Server Lines: 67 Message-ID: References: NNTP-Posting-Host: BKV6fg769rZhHiF5T3QFKA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: MicroPlanet-Gravity/3.0.4 X-Notice: Filtered by postfilter v. 0.9.2 Xref: csiph.com de.comp.lang.java:13368 In article , feunews@mpaap.de says... > Ich sag mal aus langjähriger Erfahrung mit einigen zehntausend > Java-Neulingen: Die Mehrheit derer, die > > socket.isConnected() == false > > statt > > !socket.isConnected() > > schreibt, vergleicht auch, wenn keine Verneinung im Spiel ist, mit true > und false, schreibt also ggf. auch > > if (socket.isConnected() == true) { ... } Stimmt, aber ich halte es in der Pauschalität falsch das zu ächten. 1. Sowas optimiert jeder billige Compiler weg. 2. Lesbarkeit ist Trumpf. Ein ! Ist oft einfach zu übersehen, manchmal ist der schlichte Vergleich mit false einfach sehr viel deutlicher. wenn ich eine Reihe von Vergleichen habe, wie: optionA.setEnabled(lineA1() == true && lineB2() == true); optionB.setEnabled(lineC2() == false && lineB1() == true); Dann sind all die "true" und "false" zwar überflüssig, aber: es kann sich sehr schön mit einer Tabelle aus einer Spezifikation decken und in so einer Situation ist es ggf. durchaus wert so geschrieben zu werden, sprich: Es ist nicht pauschal falsch bewusst auf die kleinen, unauffälligen "!" zu verzichten und stattdessen mit einem boolean zu vergleichen. Extrem unglücklichen Beispiel: optionC.setEnabled(lineC2() && lineB1()); optionD.setEnabled(!inEC1() && !inEC2()); Joel Spolsky, streitbar, wie seine Meinungen sind, schrieb einmal in einem Artikel, man sollte darauf achten, Code so zu schreiben, dass Sachen, die falsch sind, auch falsch aussehen. Sowas, wie entity.setWhat(taintedWhatever()); // sollte einen Alarm im Kopf läuten entity.setWhat(validatedWhatever()); // sieht richtig aus statt: entity.setWhat(whatever()); // wurde das valdiiert oder nicht? Da denke ich selbst viel zu selten dran, aber hat was. In dem Fall oben kann sowas eben auch auftreten. Oder kurz: Nen Computer kann man auch in Whitespace oder Malboge programmieren, solange die Runtime den Code versteht, ist dem Recher egal, wie scheiße der Code zu lesen ist. Daher ergibt sich: Code ist nicht dafür da dem Rechner zu gefallen, sondern den Autoren. Gruß, -Wanja- -- ..Alesi's problem was that the back of the car was jumping up and down dangerously - and I can assure you from having been teammate to Jean Alesi and knowing what kind of cars that he can pull up with, when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]