Java ist auch eine Insel

Donnerstag, Januar 17, 2008

Code style: Remove unnecessary statements and keywords

Bad

Good

import java.lang.*;


import java.util.*;

import java.util.Scanner;

import java.util.*;

class MyClass extends Object { }

class MyClass { }

class MyClass {

int i = 0;

boolean b = false;

char c = '\u0000';

String s = null;

double d = 0.0;

}

class MyClass {

int i;

boolean b;

char c;

String s;

double d;

}

class MyClass {

MyClass() { super(); }

}

class MyClass {

MyClass() { }

}

interface MyInterface {

public abstract void foo();

}

interface MyInterface {

void foo();

}

void lollipop() {

return;

}

void lollipop() {

}

java.lang.String s;

String s;

Object[] param = new Object[ 1 ];

param[ 0 ] = i;

Object[] param = { i };

Something missing?

Labels:

AddThis Social Bookmark Button

7 Comments:

  • Hallo erstmal,

    ich denke, dass bei Interfaces auch weiterhin gilt, dass jedes deklarierte Feld neben public auch implizit static und final ist.

    Es können daher beide Varianten innerhalb eines Interface-Körpers notiert werden, mit dem Resultat einer identischen Abbildung auf Java-Bytecode:

    interface MyInterface {
    public static final double PI = 3.14159;
    }

    interface MyInterface {
    double PI = 3.14159;
    }

    Die zweite Variante spart natürlich Schreibarbeit ;-)


    Viele Grüße,
    harald

    By Anonymous Harald, at Januar 17, 2008 7:07 PM  

  • Hallo,

    und hier sind meine "Erlebnisse":

    A)
    Bad:
    Type x = null;
    if (...) {
      x = ...;
    } else {
      x = ...;
    }

    Good:
    Type x = ... ? ... : ...;

    B) "Try" single out
    Bad:
    Type foo() {
      Type result = null;
      try {
        ...
        result = ...;
      } catch (Exception e) {
        ...
      }
      return result;
    }

    Good:
    Type foo() {
      try {
        ...
        return ...;
      } catch (Exception e) {
        ...
        return null;
      }
    }

    C) Single out mit "Tiefgang"
    Bad:
    void foo() {
      if (!(...)) {
        ...
        ...
        ...
      }
    }

    Good:
    void foo() {
      if (...) return;
     
      ...
      ...
      ...
    }

    D) Und natürlich der Klassiker:

    Bad:
    if (...) {
      return true;
    } else {
      return false;
    }

    Good:
    Ja, schon klar...

    Grüße, Holger.

    By Anonymous Anonym, at Januar 17, 2008 10:01 PM  

  • @Holger, was soll denn unter D) als good stehen? So ein verkürztes if wie unter A)?

    Gruß,
    Tim

    By Anonymous Tim, at Januar 21, 2008 10:42 AM  

  • @Tim:

    Nein, unter D) sollte ein einfaches

    return (Expresion);

    stehen.

    Viele Grüße
    Bastian

    By Anonymous Bastian, at Januar 21, 2008 9:19 PM  

  • return (Expression);

    sollte das natürlich heißen...

    By Anonymous bastian, at Januar 21, 2008 9:20 PM  

  • Bei A hab ich persönlich (und viele, die ich kenne) zumindest immer das Problem, das der ternäre Operator nicht sofort lesbar ist, sonden immer erstmal Nachdenken erfordert.

    By Anonymous Hartmut, at Februar 06, 2008 2:03 PM  

  • @harmut:

    Hast du und haben die viele, die du kennst, nur Probleme mit dem ternären Operator, aber nicht mit if-Anweisungen? Und welche Gedanken sind beim Erfassen des ternären Operators erforderlich? Das würde mich wirklich interessieren. Denn nur bei A-Bad fängt es bei mir an zu rattern:
    - "x = null" ist doch gelogen, x kann doch nie null sein.
    - Oder vielleicht doch, und droht eine NPE? -> lieber noch einmal genauer hinsehen!
    - Wird x auf jeden Fall gesetzt?
    - Ah, doch nur eine einfach Zuweisung!
    - Argh! Und bei "final" hätte der Autor wahrscheinlich noch ne weitere Variable und Zuweisung ge- bzw. missbraucht!

    By Anonymous Anonym, at Februar 13, 2008 10:51 PM  

Kommentar veröffentlichen

<< Home