JALOPY | Java Source Code Formatter Beautifier Pretty Printer
Overview • Download • Documentation • Plug-ins • Links • Contact
Features | History | Manual | FAQ | Javadoc
This page generated: June 8 2004
4.4. Code Inspector
Prev | Chapter 4. Settings | Next
- ## 4.4. Code Inspector Provides the configuration facility for the Jalopy Code Inspector. The Code Inspector is able to inspect Java source files for naming convention violations and possible code weaknesses. ### 4.4.1. General Lets you control the general Code Inspector settings. #### 4.4.1.1. General Enable Lets you enable or disable the Code Inspector as a whole. #### 4.4.1.2. Tips Lets you selectively choose what actions should be performed during inspection. Moving the mouse pointer onto a checkbox displays a minimalistic tooltip after a short delay. Tip 1 - Don't substitute another type for `Object` in the equals declaration For a detailed discussion see Effective Java [Bloch01], pp. 35. Tip 2 - Object the general contract when overriding `equals` For a detailed discussion see Effective Java [Bloch01], pp. 25. Tip 3 - Always override `hashCode` when you override `equals` For a detailed discussion see Effective Java [Bloch01], pp. 36. Tip 4 - Always override `equals` when you override `hashCode` Tip 5 - Always override `toString` For a detailed discussion see Effective Java [Bloch01], pp. 42. Tip 6 - Use interfaces only to define types For a detailed discussion see Effective Java [Bloch01], pp. 89. Tip 7 - Replace structures with classes For a detailed discussion see Effective Java [Bloch01], pp. 97. Tip 8 - Return zero-length arrays, not `nulls` For a detailed discussion see Effective Java [Bloch01], pp. 134. Tip 9 - Adhere to generally accepted naming conventions For a detailed discussion see Effective Java [Bloch01], pp. 165. Tip 10 - Refer to objects by their interfaces For a detailed discussion see Effective Java [Bloch01], pp. 156. Tip 11 - Never declare that a method "throws Exception" For a detailed discussion see Effective Java [Bloch01], pp. 181. Tip 12 - Never declare that a method "throws Throwable" For a detailed discussion see Effective Java [Bloch01], pp. 181. Tip 13 - Don't ignore exceptions For a detailed discussion see Effective Java [Bloch01], pp. 187. Tip 14 - Never invoke `wait` outside a loop For a detailed discussion see Effective Java [Bloch01], pp. 201. Tip 15 - Avoid thread groups For a detailed discussion see Effective Java [Bloch01], pp. 211. Tip 16 - Document collection types As long as there are no strong-typed collections (a.k.a. Java Generics support) available, it is best to document the object type of the items hold by a collection. Example 4.154. Collection comment
      private static final List _favorableTypes = new ArrayList(20); // List of <String>
- Tip 17 - Adhere to naming convention for collection types If you use comments to document the object type of collection items, you should conform to a generally accepted naming convention. Tip 18 - Avoid empty `finally` blocks Empty `finally` blocks are of no use and may indicate programmer errors. Example 4.155. Empty `finally` block
      Writer writer = null;

      try
      {
          writer = new BufferedWriter(new FileWriter(file));
          write.write(data);
      }
      catch (IOException ex)
      {
          System.err.println("file could not be written -- " + file);
      }
      finally
      {
      }
- The programmer certainly wanted to close the `Writer` in the `finally` block to ensure that allocated system resources will be freed. Tip 19 - Avoid variable shadowing Variable shadowing should be avoided on general principle, as it tends to be confusing. For more information about shadowing, see the Java Developer Connection (JDC) Tech Tips, October 10, 2000 ( http://developer.java.sun.com/developer/TechTips/2000/tt1010.html#tip2, subscription needed) or section 6.3.2, "Obscured Declarations," section 7.5.2, "Type-Import-on-Demand Declaration," section 8.4.6, "Inheritance, Overriding, and Hiding," section 8.4.8.5, "Example: Invocation of Hidden Class Methods," and section 14.4.3, "Shadowing of Names by Local variables" in "The Java Language Specification Second Edition" by Gosling, Joy, Steele, and Bracha (http://java.sun.com/docs/books/jls/). Tip 20 - Add NOI18N comment for String literals Enabling this tip will cause warnings for all String literals without associated `/* NOI18N */` comment. Internationalizing Java applications is often done with nifty tools that use marker comments to indicate that a given String literal should not be considered for localization. Most tools (at least the ones I know of) use trailing single-line comments which may not be very robust for processing with a formatting tool such as Jalopy. In contrast the author uses a multi-line comment of the form `/* NOI18N */` that gets directly placed after a String literal and will therefore always stuck with it. Example 4.156. $NON-NLS-1$ comment
      FileDialog dialog = new FileDialog(this,
          ResourceBundle.getBundle(BUNDLE_NAME)
          .getString("BTN_SAVE_AS", FileDialog.SAVE); //$NON-NLS-1$
  This trailing comment could be easily moved away from its String literal during formatting which would result in an unwanted notice on successive internationalization runs. Example 4.157. $NON-NLS-1$ comment
      FileDialog dialog =
          new FileDialog(this,
                         ResourceBundle.getBundle(BUNDLE_NAME).
                                        getString("BTN_SAVE_AS",
                         FileDialog.SAVE); //$NON-NLS-1$
  Example 4.158. NOI18N comment
      FileDialog dialog =
          new FileDialog(this,
                         ResourceBundle.getBundle(BUNDLE_NAME).
                                        getString("BTN_SAVE_AS" /* NOI18N */),
                         FileDialog.SAVE);
Prev | Up | Next
4.3.13. Misc | Home | 4.4.2. Naming
to top