清单 2. 单点退出示例
1 public String getName( )
2 {
3 //
4 // local variables
5 //
6 String returnString;
7
8
9 //
10 // beginning of code
11 //
12 returnString = textField.getText( );
13 if ( null == returnstring )
14 {
15 badCount++;
16 totalCount++;
17 return( null )
18 }
19
20 returnString = returnString.trim( );
21 if ( returnString.equals( "" ) )
22 {
23 badCount++;
24 totalCount++;
25 return( null );
26 }
27
28 totalCount++;
29 return( returnString );
30
31 } // end getName
在第 15 行，badCount 增加了，因为 getText( ) 返回 null。在第 23 行，badCount 代码又重复了。现在想像一下如果这个例子需要完成更复杂的“清理”时会有多混乱。
清单 3 显示了一种更好的方法：
清单 3. 单点退出示例 —— 修正后
1 public String getName( )
2 {
3 //
4 // local variables
5 //
6 String returnString;
7
8
9 //
10 // beginning of code
11 //
12 returnString = textField.getText( );
13 if ( null != returnstring )
14 {
15 returnString = returnString.trim( );
16 if ( returnString.equals( "" ) )
17 returnString = null;
18 }
19
20 //
21 // "cleanup"
22 //
23 if ( null == returnString )
24 badCount++;
25 totalCount++;
26
27 return( returnString );
28
29 } // end getName
这是一个简化的例子，但是请注意遵照这种习惯有多么容易，以及这样做的好处。
加强警戒（En garde）!
要记住，您的客户对您的产品有与您不一样的想法。他们会在一个您的小组很可能从来也没想到的 —— 或者至少是没有可能测试的 —— 环境中安装它。他们会以您从来没有想到过的方法使用它，并以您意想不到的方法配置它。下面的列表有助于帮助您保证他们不会发怒：
验证所有收到的参数的完整性（考虑如果您期待一个数组而传递来的是一个 null，但是您在索引数组之前没有检查这种可能性时会发生什么情况）。
考虑所有可能的错误情况并增加处理每种情况的代码（您希望代码得体地处理错误条件而不是堵塞它）。
对于那些未预料到的错误条件，加入一个一般性的“捕获所有”错误处理程序。
在适当的时候和地点使用常量。
在代码各处加入跟踪和日志。
如果您的产品将翻译为另一种语言，那么保证您的代码可以“支持”它。即使出现这种情况的机会很小，但是提前计划总是好一些。修改代码以使它提供支持是最容易产生缺陷的。下面是几个您要考虑的与支持相关的问题：
您是否有任何硬编码的字符串？
您是否正确地处理不同的日期/时间？
不同的货币表示呢？
还有，在代码中使用大量断言。有关在 Java 代码中使用断言的细节信息请参阅 参考资料。
给您的代码加上充分的 注释。总之，您还记得在六个月前编写那个方法时的想法吗？一年后要修改您的代码的某个人又会怎么想呢？在我们提出的所有建议中，这一条可能是最重要的。
跟踪和日志
日志是必不可少的，而现有的最好工具是 alphaWorks 的 Logging Toolkit for Java （更多信息请参阅 参考资料）。
