呵呵，我来稍作解释吧 好的命名有一个基本原则，命名法能够反应出语言本身不能反应出的含义。 比如，在javascript当中，匈牙利命名法就很合适 function(v) { v = window.createObject("..."); var a = v; ... } 因为js没有强制类型检查，所以在变量名前加类型前缀可以有效的避免错误传值。但是在c++当中，匈牙利命名法用处就很小了 int i = 1; i = "0"; 编译器会毫不客气的报个错，提醒你：这里该传整数。 但是c++当中class和struct还是很相象的。 单独一个Person，你知道是什么类型吗？是class，还是struct，抑或enum?在java里，这个问题就不存在了，一切都是类，现在你只需要 Person { }即可。
C语言用的溜的习惯用后者；俺还是习惯用前者，if(src!=null && src.equals("des")){...}，看起来比较清晰，出发点也更清晰附： public boolean equals(Object anObject) See Also: compareTo(java.lang.String), equalsIgnoreCase(java.lang.String) public int compareTo(String anotherString) Throws: NullPointerException - if anotherString is null.
比如在C++中
如果你写if(x==1)，有可能写成if(x=1),但是编译不会报错(当然java不会出现这种问题)
但是如果你写成if(1==x)，即使你写成if(1=x)，也不用担心，编译器会报错
养成这样的习惯，写什么语言都可以避免
这是比较推荐的写法，把常量放在前面
比如在C++中
如果你写if(x==1)，有可能写成if(x=1),但是编译不会报错(当然java不会出现这种问题)
但是如果你写成if(1==x)，即使你写成if(1=x)，也不用担心，编译器会报错
养成这样的习惯，写什么语言都可以避免
================================================ java 不推荐使用这个方法，因为if(x=1)在 JAVA里编译器会报错。不应该在JAVA想当然的使用C++中的一些常用处理办法。
作 者： kypfos (夜色太漫长)
等 级：
信 誉 值： 97
所属论坛： Java J2SE / 基础类
问题点数： 20
回复次数： 8
发表时间： 2004-04-20 10:08:51
为什么很多地方会推荐采用后一种方式来进行字符串比较呢
========================================================我没有见过在JAVA里会推荐使用后一种方式来进行字符串比较 !!!!!
.equals 前面的变量都尽量保证不是null的.这样的可以避免 NullPointerException 的出现,而且好多时候还可以省掉很多
if(src==null)这样的代码.
比如说你在client端需要用户输入一个关键的字符，如果用户没有输入，在client端进行检查时用第二种方式就有可能出错，将null传送到server端，造成错误。
而使用一种方式就隐含了对null输入的检查。
一般来说有两种情况：
1 这个地方src的取值的确有可能是null,这是程序正常运行所允许的，那么就应该写成
if(src!=null && src.equals("des"));
这样可以表示更加清晰的语义！使得阅读程序的人能一下把握这条判断语句的前提条件。
2 这个地方src的取值不可能是null。既然如此，想要用后一种方法来防范NullPointerException就完全没有必要了。
也许有人会立即反驳：万一这里是个null怎么办？程序不就会不正常退出了吗？
下面我来解释：正常运行时会不会是null?不会。好，那么万一这里出现了null，就说明程序运行的不正常，对不对？对。既然程序已经运行不正常了，那么你有办法让它工作的像正常程序一样吗？显然不能。现在又有人说话了：那总比非法退出要好。
我可以举一个现实的例子：一个程序在测试时没有发生任何问题，然后给用户演示，用户点击了一个按钮，然而没有任何事情发生－－没有出错信息，也没有按正常情况弹出新窗口。后来费了很大劲单步调试，才发现有个传值的地方有次序问题，导致传了空值，而接收空值的函数采用了某些类似楼主例子的避免异常的措施，结果就导致了这种情况发生。
事实上，最重要的是：如果当初这个函数没有刻意的去掩盖空值，那么这个错误早就可以在测试阶段被发现和排除了。
最后再劝告楼主一句：异常的用途有二：错误检测和流程控制。如果一味的去回避，那么java还要异常处理何用？
再一次强调，不要以为适合C++或别的语言的处理方法就可以用在JAVA上，大错特错
致：game0ver12345(sfsfdsfdsdfsf)个人觉得思想方法不应有体现在语言上的差异。
============================================我也觉得思想方法不应有体现在语言上的差异。
方法名叫做 do_something 这样的命名在JAVA上是败笔。
例如在C++ 或C上 ，这样的命名方法很普通，但在JAVA上就是败笔。类名叫做CPerson
方法名叫做 do_something 这样的命名在JAVA上是败笔。
-----------------
能解释一下吗？谢了。
java里的method一般是首个小写，后面的单词首个字母大写，而且一般是动词＋名词：）
比如public void doSomething()
好的命名有一个基本原则，命名法能够反应出语言本身不能反应出的含义。
比如，在javascript当中，匈牙利命名法就很合适
function(v)
{
v = window.createObject("...");
var a = v;
...
}
因为js没有强制类型检查，所以在变量名前加类型前缀可以有效的避免错误传值。但是在c++当中，匈牙利命名法用处就很小了
int i = 1;
i = "0";
编译器会毫不客气的报个错，提醒你：这里该传整数。
但是c++当中class和struct还是很相象的。
单独一个Person，你知道是什么类型吗？是class，还是struct，抑或enum?在java里，这个问题就不存在了，一切都是类，现在你只需要
Person {
}即可。
有的时候只要比较src和'dec'等不等就可以了
那样当然用"dec".equlas(src)就可以了如果要对src==null的时候做处理
那当然不能直接用"dec".equlas(src)了没什么好不好的
因为前面一中要多写一个
if(src!=null && src.equals("des")){
//
}
if(src != null) {
//dosomething;
} else {
//错误处理;
}
检查一下比较好，或是用try...catch的方式
有人说尽量使用try catch，这个我很赞同，但问题是什么情况下需要捕获意外，不能说写一句代码就trycatch一下，或把所有代码统统try catch，这样做肯定是不对的，当然我说的也有些极端，呵呵，我只是想说明在需要的时候才用try catch比如，大家讨论的src为null时，这个时候我们需要捕获意外吗？一般是不要的，我们想要做的只是在src为null的时候不做一些事，不执行某个方法等而不是让我们了解这个时候src为null了，这个意外对我们来说是毫无意义的，开发者就算知道什么时候src为null了又能做些什么呢？，这个本来就是正常情况下会发生的。在debug的时候，因为src为null，没有执行某个方法，后台看不到错误信息，我想我们在开发的时候就应该了解这个if else，else的时候会发生什么，应该心中有数，再说也可以通过日志打印出目前的src值
呵呵，欢迎讨论
public boolean equals(Object anObject)
See Also:
compareTo(java.lang.String), equalsIgnoreCase(java.lang.String)
public int compareTo(String anotherString)
Throws:
NullPointerException - if anotherString is null.
C语言用的溜的习惯用后者；俺还是习惯用前者，if(src!=null && src.equals("des")){...}，看起来比较清晰，出发点也更清晰=========================================
if(src!=null && src.equals("des")){...}这句话是在JAVA中已经成为惯例 ，第二种写法会破坏JAVA程序的惯例。
最后再劝告楼主一句：异常的用途有二：错误检测和流程控制。如果一味的去回避，那么java还要异常处理何用？
---------------------------------------------------------
使用try/catch会引起性能损失，所以最好不要拿异常作流程控制。我是从书上看到的。参见于《高质量java程序设计》，电子工业出版社。我觉得书里面的异常讲得很好
那咱们来抬抬杠吧
尽信书则不如无书。“使用try/catch会引起性能损失，所以最好不要拿异常作流程控制。”这句话讲的不错，抛出异常会带来很大的性能损失，不过必须得放在具体环境中理解。首先，如果有预先的检查手段，则尽量不要使用异常。
比如if(src==null){...}就是一种预先的检查手段。它可以保证用正常流程来保证代码块的前提被满足其次，该检查手段只能用于正常运行条件下。
比如if(src==null)就意味着src==null属于正常情况，这时程序仍然处在正常运行中。
如果你遇到这种判断，可以问一下自己，我是否允许src传入null?如果调用方要求我必须对src这种情况进行处理，那么它就是正常的，我必须检查src是否为null,然后分开处理。
反之，抛出异常，将流程切换到异常处理中。
当你的变量 src 的取值有可能为 null 时，前一种写法就会抛出 NullPointerException，后一种情况就避免了这个问题
回复人： kevinliu961(kevin) ( ) 信誉：98 2004-04-20 13:26:00 得分:0
这是比较推荐的写法，把常量放在前面
比如在C++中
如果你写if(x==1)，有可能写成if(x=1),但是编译不会报错(当然java不会出现这种问题)
但是如果你写成if(1==x)，即使你写成if(1=x)，也不用担心，编译器会报错
养成这样的习惯，写什么语言都可以避免
=========================================================为什么JAVA比C＋＋更少错误，更容易调试，这是由于JAVA有它自己的特点的缘故。如果值为null的时候 ，第一种写法在JAVA中会产生Exception , 很好的确定了错误，更容易debug.如果值为null的时候 ，第二种写法在JAVA中根本不是程序员的想要得到的，极可能产生错误，但这种错误已经偏离了原先的错误位置， debup更为困难。为什么在C＋＋中有时会推荐第二种写法，这是因为在C＋＋中第一种写法根本不能产生Exception ,根本达不到JAVA的第一种效果。在JAVA中，第一种写法是一个惯例，没有特殊的原因最好遵循JAVA本身的惯例。
可能我们理解的流程控制是不同的。处理异常对你来说也是一种控制方式。对我来说，程序的流程控制是说在正常的逻辑下，根据条件的不同而采取不同的处理手段。出现异常的话我们就会抛开原来的逻辑转到异常处理，我认为这种方式最好只用来处理我们无法预料的情况或者正常情况下不会出现但出于程序健壮性原因而必须考虑的问题。我们不能因为异常可以进行流程控制就要拿它来做。我认为无论是何原因，语义的错误一定要检查，比如在使用字符串前一定要确认它不为空，哪怕查出它为空后自己来抛出一个RuntimeException。也许麻烦些，但是程序的可读性和逻辑性要好一些。
呵呵，请抨击
我认为异常处理也应当看做一个流程。因为异常处理部分也是由语句构成，也会有分支，循环（当然很少见）。
事实上，一个正常的程序可以看做2个流程：正常逻辑和异常处理逻辑。异常处理的好处在于可以迅速的根据发生的异常种类切换到相应的异常处理逻辑中去，在比较复杂的结构中，可以节省下很多资源，而且使正常逻辑显得更加清楚。除此之外，我觉得我们的意见都是一样的，关于语义错误一定要检查这一点我完全赞同。我在前面也提到过“如果有预先的检查手段，则尽量不要使用异常。”
exception就是拿来提醒自己的：这里有问题！或者可能有问题！要么截获它，然后设法处理，要么就事先做检查，以满足合法性前提。只会掩盖算什么，迟早要吃苦头的
不过if得太多，也比较烦！：（流控制 经常出错。