My answers often sacrifice "best practices" and optimizations for brevity and readablity (a.k.a "batteries not included"). I find it that often the asker needs only a few core lines / ideas and the wrapping around is to provide an answer in the form of an MCVE.

Following are points (in no particular order) you should look at when reading my answers (and questions) since I will not always follow the guidelines when they are not necessary for the answer. Use your own judgment when considering these.

  • Modifiers: visibility modifiers (private, public, protected or none), static and final are often affected by the bigger scope of the whole program.

  • Local variables vs. fields: the decision to promote a local variable to a field (or vice versa) often also depends on the bigger picture. It is sometimes much easier to show a point with fields than with local variables.

  • Anonymous classes vs. inner classes: I will often opt for inner classes since they pose a single modifiable unit and provide easier to read code.

  • Formatting: this goes without saying, but whitespaces and braces are user preferences in most cases.

  • Initializing Swing: Swing applications should be invoked as described here, I will usually not do this.

  • Performance: I will often not optimize the code for memory usage or running time and will usually choose the one-line

    methodCall(getObj(), getObj());

    over the 2 lines

    Object obj = getObj();
    methodCall(obj, obj);

    when the call to getObj() returns quickly enough.

Top Questions
1 2

Top Answers
1 2