请问，用中文作为 方法和变量的名字 有什么利弊？ - ITeye问答
在写 java 代码时，是可以用 中文作为变量名和方法名的。从可读性和可维护性来说，似乎用中文作为 变量名和方法名 对我们中国人来说具有更好的可读性和更好的可维护性。
请问，你会这样用吗？为什么？
问题补充：redstarofsleep 写道用中文倒是真没试过。。。。。
还是英文的通用性高吧。
用中文的话可移植性肯定差了。
在类Java_KAbanban 写道利：也许你看的时候感觉很好理解
弊：一旦出现编码不一致的问题，中文就会出现乱码，你想一下还能调用的到吗？
统一使用 utf8 是没有问题的，从数据库到网页，全部都用 utf8 相信就不会出现编码的问题。
问题补充：redstarofsleep 写道LZ可以看看Java编码规约。
规约不是拍脑袋随便规定的，每一条都有它的道理。
规约里规定类名首字母大写，变量名首字母小写。
我记得在 c 语言的编程规范里有两种，一种是和现在的 java 类似，另一种是，用下划线来分开各个单词。规范的制定，说到底是为了使代码更易于阅读和维护。但现在的 java 编程规范的制定，肯定没考虑过类似中文等其他语言。所以我认为这个规范是有限制的。我们可以考虑用下划线来区分词语。
问题补充：jinceon 写道我还真见过人用中文，他说他们老师推荐用中文，容易理解。
看到那些get学生，set学生，我就郁闷。
这是不是因为你不习惯而已？
问题补充：redstarofsleep 写道
那JavaBean呢？如果一个类的成员变量都是中文的，那么它的get/set方法怎么写？你自己调用是没问题，放到框架里（Struts2，Hibernate这类的）还能自动设入值吗？
这个我没有测试过。但从个人经验上分析，你说的这些框架应该是能支持的。就象上面的朋友所说的：
我还真见过人用中文，他说他们老师推荐用中文，容易理解。
看到那些get学生，set学生，我就郁闷。
jinceon (初级程序员)
他们的老师敢推荐这些学生用中文，如果这些老师自己没有试过就推荐，可能性不大。因此我认为你说的这个应该不成问题
问题补充：redstarofsleep 写道我在Struts2上试过了，是不支持的，拿不到值，返回null。
而且这在理论上也是说不通的，完全违反了javaBean的规约。JavaBean对于变量名和get/set方法有着非常苛刻的要求。
除了Javabean之外，现在很多框架都支持不用配置文件，按照约定来命名就能自动认到。用中文的话，这种方式也可能会有问题。
昨晚回去后简单测试了一下。我的测试环境是： springside 3.3.4(spring3 + struts2 + hibernate + h2database)，全部用 utf-8。测试大约过程是，在实体字段全是英文的情况下：
1、添加字段，可以自动对应在数据库中的表添加
2、可以正常取出数据。
当把某个实体的字段改为中文后：
1、hibernate 不能自动添加字段到数据库表中；
2、手动通过sql往数据库表中添加了一个中文字段后，并添加相应的数据；
通过 h2的界面添加修改数据没有问题（h2本身是 java 写的，从这个意义上说，jdbc 是支持中文字段的）。但最后在前台的界面(struts2)中没有显示相应的数据；
在前台界面中输入数据，在没有更改非中文字段数据的情况下，hibernate 没有输出 update 语句；如果更改了非中文字段，那么非中文字段的数据能正常更新，但中文字段的数据没有取到，没法保存。
具体中间到底是 哪个部分不支持，现在还暂时没有深入测试。等明天有空再测试一下。
另外，很多朋友说，用中文作为变量名/方法名，是不符合 javabean 等相关规范的。因为我没有阅读过相关规范，暂时也没空去看。大家能不能简单说一下，javabean 等规范要求必须使用英文作为变量名吗？还有，为什么 java 要支持使用非英文字符作为变量名和方法名呢？这样做有什么意义？
反过来，我们能不能这样认为，既然java支持使用非英文字符作为变量、方法名，但现在很多框架、规范不支持，那是不是这些规范、框架的缺陷和 bug ？
ps:我发布这个问题的初衷在于探讨这种可能性，不考虑外国人看不懂等问题。
问题补充：1、有些朋友说，用中文编码后，代码的可读性和可维护性可能更差。我相信这种情况是存在的。但我更相信，作为中国人，绝大部分人用中文表达思想胜于用英文表达。
之所以出现用中文编码比英文编码更难读懂，我想最主要的是习惯问题。比如设计模式的名称，一个类名称用了设计模式的名称，基本上懂设计模式的阅读者一眼就知道编码作者想做什么了。另外是一些习惯用法，比如，一些名 action、service、thread 的类，类里的 execute 方法。如果这些也用中文来命名，就使得可读性、可维护性变得更差。
所以我比较倾向于编码中，一般情况用英文编码，但部分地方用中文。举个几个用中文感觉更合适的简单的例子：
我们有时候定义一些常量，如，男 -& 1，女 -& 0，-1 -& 未知；
我们写一些枚举类，里面定义了一些如中国的地名等；
一些业务方法、一些类属性用的英文很难表达，或英文单词本身比较生僻；
这些情况下，我们用这样的代码：City.广州、City.深圳 就比用 City.GuangZhou、City.ShenZhen要强一些。
当然我也没有真正用中文做过编码，更适合的场景也举不出例子来。
2、关于中英文切换和输入的速度的问题。
因为我常用中文来写注释，但我很少会因为中英文需要切换而感到困惑。
而对于输入速度，如果是写注释，我用英文时常因不知道怎么用英文来表达而苦恼，需要思考的时间很长；而对于在代码中的变量和方法名，我常常为了使变量名、方法名能准确地表达我想要表达的意思而去查词典，并且对词典查出来的几个单词，仔细斟酌该那个单词更合适而花费大量的时间。
所以我认为速度并不是使用中文编码而需要考虑的情况。
问题补充：niko7 写道为了说这个问题，先来看个活生生的例子：http://blog.csdn.net/niko7/archive//225327.aspx
比如类名是中文的，每次new 的时候就麻烦了。方法名是中文的，调用的时候就麻烦了。
这种麻烦主要是来自代码辅助生成时，按了“.”以后必须往下翻，或者切换到中文输入法输入，很麻烦。并且完全享受不到IDE的驼峰提示的好处了。
还有个头疼的问题是，中文没有大小写区别，导致bean的属性命名规范体现不出来，所以会导致一些框架出现问题。而JavaBean的规范之所以那么规定，显示是没有考虑到中文。
所以，中文能作为类名，方法名，属性名，变量名是纯属偶然，仅仅是因为Java内核支持UTF-8，所以这些字符都没有问题；也不会出现上面说的，找不到变量的问题，在class文件内都是同一编码的，jvm内核就是支持UTF-8的。可以放心使用。
结论是：Java支持中文类名、方法名、属性名，并且不会因为乱码问题导致运行期链接失败。这是Java内核支持UTF-8这一特性决定的。
但是Java语言规范里并不支持这一用法，可以从JavaBean规范看出来。
很多框架不支持，是因为中文属性名与JavaBean规范不友好造成的。
为了带来有限的“容易理解”，却导致程序功能不正常了，是得不偿失的，所以：不推荐使用。
那么在属性名之外的地方，还是可以尝试使用的，比如成员变量名、类名、方法名中。
Java5开始有枚举了，枚举值的名称相当于类名，使用中文优势蛮大的。
因为现代IDE的突飞猛进，我有时候是用英文取个名，把代码写好，在后期优化的时候会把变量名重构成中文的。这样易于输入，也易于理解。
非常不错。如果明天没有更好的回答，采用这个为最佳答案了。
采纳的答案
为了说这个问题，先来看个活生生的例子：http://blog.csdn.net/niko7/archive//225327.aspx
比如类名是中文的，每次new 的时候就麻烦了。方法名是中文的，调用的时候就麻烦了。
这种麻烦主要是来自代码辅助生成时，按了“.”以后必须往下翻，或者切换到中文输入法输入，很麻烦。并且完全享受不到IDE的驼峰提示的好处了。
还有个头疼的问题是，中文没有大小写区别，导致bean的属性命名规范体现不出来，所以会导致一些框架出现问题。而JavaBean的规范之所以那么规定，显示是没有考虑到中文。
所以，中文能作为类名，方法名，属性名，变量名是纯属偶然，仅仅是因为Java内核支持UTF-8，所以这些字符都没有问题；也不会出现上面说的，找不到变量的问题，在class文件内都是同一编码的，jvm内核就是支持UTF-8的。可以放心使用。
结论是：Java支持中文类名、方法名、属性名，并且不会因为乱码问题导致运行期链接失败。这是Java内核支持UTF-8这一特性决定的。
但是Java语言规范里并不支持这一用法，可以从JavaBean规范看出来。
很多框架不支持，是因为中文属性名与JavaBean规范不友好造成的。
为了带来有限的“容易理解”，却导致程序功能不正常了，是得不偿失的，所以：不推荐使用。
那么在属性名之外的地方，还是可以尝试使用的，比如成员变量名、类名、方法名中。
Java5开始有枚举了，枚举值的名称相当于类名，使用中文优势蛮大的。
因为现代IDE的突飞猛进，我有时候是用英文取个名，把代码写好，在后期优化的时候会把变量名重构成中文的。这样易于输入，也易于理解。
用Ascii字符编码在任何平台下都不会有问题，如果采用中文编码，错误的设置字符编码会导致不能编译，在没有安装中文的平台上无法显示中文。
我之前做webgame的时候就碰到过后台java服务端方法名还有参数以及变量都是中文做的，当时觉得很好奇，现在想想虽然从可读性性上来讲是让我们能够一目了然但是从移植性上将就不行了，把服务部署到linux unix 上的时候就不行了。
不知道楼主你问这个问题是想怎么做打算这么开发你的项目么？
我不认为用中文命名就有好的可读性和可维护性，这种底层的东西还是用英文正规些。
有的平台会报错，通用性低！
不通用，建议少使用
看了你的补充，发现你完全没明白到底是为什么不用中文。什么驼峰啊，IDE啊，那都是次要的，等你用中文开发，还不搞个中文的IDE啊，再有什么JAVABEAN规范，等你掌握技术的时候，你就可以定规范，还管什么别人的规范。
不错 不错... 以后咱们中国人就好开发了
什么时候也行成标准就好了..&&
个人喜欢而已,如果允许,用中文是很不错的.但开发效率不是很高,打字慢.
从来没试过。。不过很多框架。。将不能使用
通用性和平台移植性差，不应该使用中文进行函数、变量、类等的命名！
物料的问题 你用汉语拼音也比中文强
这个其实写代码还是不要过多引入中文的，还有很多地方其实注释都不用中文的，一则是和编码经常有关跨平台就很容易乱了，再次规范的话都是国外顶出来的，肯定是英文的。也建议英文，起码是拼音
中文的感觉会是很好的，，，，
但是没有英文的，适用
1.通用性较差
2.代码的可一直性差，将源代码拿到其他的开发工具中可能会出现乱码。
3.个人理解在jvm对代码进行编译时候增加了中文转换成unicode编码的过程，如果中文较多影响编译效率。
曾经用中文的类名和方法名做过一份课程设计， 被老师臭骂了一顿。 呵呵， 或许对于程序员而言， 用英文字符写程序都成了习惯。
基于存在即合理的原则， 这种习惯有一定的优势吧， 曾经想尝试对编译器做封装， 把java中的关键字也编程中文的。 但是后来感觉意义不大，放弃了。
不过真用中文的话，肯定会有许许多多的问题的。 因为现在项目中需要用到许多开源的包， 而那些包可能不兼容你的代码。
还有当你的代码放到其他语言的操作系统中是否支持呢， 相信你那样开发的系统跨平台应该会有问题吧。
使用中文可移植性会降低
核心的东西都是老外写的，整个环境就是用的英文写的。如果用中文最常碰到的就是编码的问题，如果你采用与你开发用到的框架完全一致的编码理论上是没有问题，可是往往是几个框架一起用，例如strurs+spring+hibernate 他们开发时用的编码不一定相同这是你就没有办法统一编码了，用英文就不存在这个问题。
不用中文的原因主要就是通用性、易维护。
如果只是限制在一个很小的范围之内那中文就有可能可以用。，在实际项目中这种可能性很小，从个人的发展来看你肯定不能那样用中文的。
没有绝对的东西，所有的利弊都是相对的。
回答的帖子自己不能删除啊
我本只想试试你们编辑器的效果。
vsdfsfd[b]fsdfsdfsd 引用fsdfsdfsdfsdfsdfsdfsd
fsdfsdfsdfsdfsdfsdfsdfdsfdsfds
可读性和可维护性的根本在于“统一”，是否是中文、英文无所谓。就像你写文章，你不能一句话中既有拼音，又有中文、法语、英语。这样的文章肯定没法读。而既然你编程的环境都是以英文为主体的，包括编译器（中文的空格等符号，很多编译器不支持，难道你把他们手动替换成英文的，自找麻烦？）、系统调用（给所有系统添加包装器？你添加的过来么？）等。除非你把他们都换成中文，否则是行不通的。
主要是编码问题，还有就是麻烦！
在写 java 代码时，是可以用 中文作为变量名和方法名的。从可读性和可维护性来说，似乎用中文作为 变量名和方法名 对我们中国人来说具有更好的可读性和更好的可维护性。
但是从标准上来讲，最好还是用英文，应为用中文的话不同平台文件编码不同，可能会出现乱码情况，而且中文做变量名有点别留
不可否认有些时候使用中文会通俗易懂，但是在编译时，中文的识别性就会差些，有时候就会出现乱码，而且移植性较差，再说在一堆英文当中突然出现几个中文，个人感觉很突兀。
没有必要使用中文作为方法名和方法名，这样会导致通用性移植性不够好
用中文? 老外不懂类.哈哈.
这。。。情何以堪。。。
引用一些业务方法、一些类属性用的英文很难表达，或英文单词本身比较生僻；
这些情况下，我们用这样的代码：City.广州、City.深圳 就比用 City.GuangZhou、City.ShenZhen要强一些。
当然我也没有真正用中文做过编码，更适合的场景也举不出例子来。
2、关于中英文切换和输入的速度的问题。
因为我常用中文来写注释，但我很少会因为中英文需要切换而感到困惑。
而对于输入速度，如果是写注释，我用英文时常因不知道怎么用英文来表达而苦恼，需要思考的时间很长；而对于在代码中的变量和方法名，我常常为了使变量名、方法名能准确地表达我想要表达的意思而去查词典，并且对词典查出来的几个单词，仔细斟酌该那个单词更合适而花费大量的时间。
所以我认为速度并不是使用中文编码而需要考虑的情况。
引用当然我也没有真正用中文做过编码，更适合的场景也举不出例子来。
引用并且对词典查出来的几个单词，仔细斟酌该那个单词更合适而花费大量的时间。
遇到这样的我直接使用ZhongWenPingYing，一般都看得懂的。
这样做。。可能你好理解，可是别人不好理解啊
在little endian的机器上写一段代码，然后往big endian上移植一下？
从jvm和java语法层面来说，完全可以这样做：中文作为变量名甚至方法名。
业界为什么不用呢？
答：
1. english是惯例。
2. 为了使用轮子：类似反射，或者jdbc等等旧有的代码或者数据或者程序，他们未考虑utf8编码的变量名或方法，所以在运行时非常可能无法正常运行。
3. 书写速度：英文比中文更加容易和快速。
4. 阅读：中文读起来并不比英文有优势
5. 出错概率：全角和半角看起来差不多，用中文开发比英文更容易出错。
完全可以使用中文，java编码规约里压根就没提到除英文字母、希腊字母、拉丁字母之外的约定，况且java语言开发者既然支持了广泛编码，那他的本意就是如此。
使用中文好处：
1.便于区分系统关键字和自定义关键字。
2.确如楼主所说：从可读性和可维护性来说，用中文作为变量名和方法名（甚至类名、包名）对我们中国人来说具有更好的可读性和更好的可维护性。
3.汉语具有多义和浓缩特性，需要表达同样的意思，所用字长一定比英文短（对比英文文章和中文翻译就知道了），省空间。
4.关于通用性和兼容性，可以采用折中的方案：把与网页、数据库等外部交互的方法、类、包集中起来，其中与外部传输数据的部分使用英文（这样网页、数据库等的编码就自由定义了，无需考虑平台兼容性、通用性、可移植性了），java程序内部使用中文，与外部交互使用英文，外部数据你想使用什么编码都无所谓。
5.如果使用中文，编码规约里的一部分规定就不必理睬，想怎么写就怎么写（因为没有规定）。
6.关于第三方框架、规范：尽量避免在这里使用中文，即便java本身设计考虑到了广泛编码，第三方毕竟未能领会理解java开发者或者规约本意。对于需要使用的地方，可以采取第4条方法，将这类使用英文的代码集中处理。这里称赞一下eclipse对规约的理解一级在多语言编码上的努力。
PS：让我加入汉化组，我一定连setter和getter也汉化了。
个人感觉可以用，习惯问题，如果你觉得用中文好，只要你所有的东西都同一编码，没有问题，JAVA本来就支持各种语言，只是大家习惯了用英文写。
我刚才试了一下Spring的容器的自动注入，和java的反射，都可以支持中文的类名、方法名和成员变量。
本来我是想的java反射里面会有问题，例如变量名的小写开头如memField，它的set方法是setMemField()，其中的M要变成大写。但是，用中文的成员变量时，用反射方式set值也可以。
这说明，从语言角度是可以支持中文的，至于有一些框架不支持，只因为在数据的传递过程中，有一些地方有编码的问题。
但是，就算支持，用中文也非常的不方便，上面很多人都提到了许多理由。
我试过，Oracle里字段用的中文，Hibernate反向工程，出来的Pojo里属性都是中文，完全没有问题，反正都是utf-8，中文跟英文没有质的区别，编译成class文件就完全没有区别了吧？
可读性太差。效率不好
中文敲起来麻烦
可移植性查&& 乱码问题就更多了
個人認為用英文最大的好處是變量多:比如我要定義一個數字:....可以有很多種特別是用作標識性的東西,本來就沒什么意義的,用英文的就方便多了.
引用javabean 等规范要求必须使用英文作为变量名吗？还有，为什么 java 要支持使用非英文字符作为变量名和方法名呢？这样做有什么意义？
反过来，我们能不能这样认为，既然java支持使用非英文字符作为变量、方法名，但现在很多框架、规范不支持，那是不是这些规范、框架的缺陷和 bug ？
●有没有要求【必须】用，这个问题很扯淡。就算你不按规范，难道会编译不通过，无法运行？只是一种建议，一种良好的约定俗成的规范是很有意义的。
●为什么要支持非英文字符？这是一种长远眼光吧。未来用非英文字编程会不会成为潮流，不好说，但是现在不提倡。
●也许能这样认为吧。等这些框架支持了后，等大多数人适应了后，也许用非英文字母编程就会成为潮流了。
我觉得用中文编程，是软件行业的倒退，
试想如果都像你这样想，俄罗斯人用俄语编程，
日本人用日语编程，依此发展下去，日本人写的
rail 框架你是不可能看得懂的，好的经验很难借鉴过来，
用中文编程只会是给程序员添乱，是目光短浅。
软件这个行业从一诞生就是国际性的，这是与其他行业很大的不同。
中国软件还没有发展起来就想着先封闭自己，愚人自扰之。
一个字：乱！~
从：http://www.iteye.com/topic/19446?page=4 引用过来的，看了有什么感觉？
等值命题( "\u7684", "的" );;
字符串包装 的 = new 字符串包装("的");;
byte[] B5_C4 = new byte[]{(byte);0xB5, (byte);0xC4};
byte[] AA_BA = new byte[]{(byte);0xAA, (byte);0xBA};
byte[] E7_9A_84 = new byte[]{(byte);0xE7, (byte);0x9A, (byte);0x84};
等值命题( new byte[]{'?'},
的.取字节("ISO-8859-1"); );;
等值命题( new byte[]{'?'},
的.取字节("US-ASCII"); );;
等值命题( B5_C4,
的.取字节("GB2312"); );;
等值命题( AA_BA,
的.取字节("BIG5"); );;
等值命题( E7_9A_84,
的.取字节("UTF-8"); );;
等值命题( new byte[]{-1, -2, (byte);0x84, 0x76}, 的.取字节("UNICODE"); );; // 这个不一定对
类 对象类 = 类.取类(Object.class);;
类 类的类 = 类.取类(类.class);;
真命题( 对象类 == 类的类.父类(); );;
真命题( 类的类.有实例(对象类); );;
真命题( 对象类.有实例(类的类); );;
真命题( 对象类.可来自(类的类); );;
假命题( 类的类.可来自(对象类); );;
类 字符串类 = 类.取类(String.class);;
真命题( 字符串类.是一种(对象类); );;
真命题( 对象类.可来自(字符串类); );;
真命题( 字符串类.有实例(""); );;
假命题( 字符串类.有实例(null); );;
真命题( 对象类 == 字符串类.父类(); );;
真想用,就用呗.走自己的路,怕啥.出了问题再找再改就是烦点事多点.我想楼主拿出这个问题讨论时就考虑到了这些.当然如果楼主用到一些第三方的东西,代码本身没考虑到中文会出现的bug,楼主也不用怕源码上改吧.我相信楼主能搞定
http://www.iteye.com/topic/19446& 这里也又讨论。。。
字符集 除非你统一& 不然换个环境 好比win到linux 就会出现很诡异的现象
1、编码问题
2、某些辅助工具可能不支持中文
3、代码规范
4、国际化
5、...乱侃的，不喜请见谅，:)
你要引用变量的话超麻烦 还要切换输入法.
实际上开发效率反而慢
如果中国的开发人员能开发出一系列像我们现在用的软件的话，你再来谈论这个吧
1. 首先从规范来说, 用中文严重违反java规范的描述
2. 字符集问题, 如果你的程序在国外,会有问题
3. 可移植性,可维护性很差, 如果你的代码要一个不懂中文的外国人来维护,还有迁移到一个支持中文字符集不好的环境中, 就很麻烦了.
只说一个事,语境问题.你在中国一个说汉语的地方,你偶尔说两句e文那叫洋气.如果说得了你周边的朋友怎么看你?同样你做软件开发一个理,但英语是计算机编程语言中的母语,你要说中国话,编程世界中绝大多数在说英语的会怎么看你说中国话的.如果坚信一句走自己的路别人去说吧,ok,go on..
首先是移植性差& 其次是通用性差 有违开元之说
编码格式问题，防止出现乱码
1.容易出现乱码
2.在网络上传输慢，浪费资源
通用性应该不是很好！
中文移植性差，且在移植运行中容易出现编码问题，通用性差
不要觉得什么规范是约束，其实是为了让我们更好地合作。
就算你现在有一百万个理由反驳我们，又怎么样？
================================
若干年后会怎样，不清楚。。
但是至少现在，面试你的人，不会赞成用中文。
如果哪个老师推荐用中文，那不得不怀疑这老师的水平，所谓的用中文编码的都是一些demo而已，商业开发谁敢get学生，set学生这么用？
绝对同意，当时我看到那个帖就建议他不要用中文，不过听不听是他的事
他们的老师敢推荐这些学生用中文，如果这些老师自己没有试过就推荐，可能性不大...
你还真说错了。。。。
好吧，就当我不习惯吧。
不过我相信【不习惯】的应该是大部分。
尤其是如果你想去大公司，去外资，你用中文？？？？
我只是想说在理论上没有问题，但是在实践中你会碰到很多问题，有的时候不是改编码为utf8就能解决的，很多东西都是老外设计的，你保证他们在中文环境下都测试过？
如果哪个老师推荐用中文，那不得不怀疑这老师的水平，所谓的用中文编码的都是一些demo而已，商业开发谁敢get学生，set学生这么用？
如果单纯的为了好理解，你可以选择用注解啊？
如果用中文的话会出现编码问题......
引用这个我没有测试过。但从个人经验上分析，你说的这些框架应该是能支持的。
我在Struts2上试过了，是不支持的，拿不到值，返回null。
而且这在理论上也是说不通的，完全违反了javaBean的规约。JavaBean对于变量名和get/set方法有着非常苛刻的要求。
除了Javabean之外，现在很多框架都支持不用配置文件，按照约定来命名就能自动认到。用中文的话，这种方式也可能会有问题。
用中文作变量名和类名，实际上就是给自己找麻烦。
引用我记得在 c 语言的编程规范里有两种，一种是和现在的 java 类似，另一种是，用下划线来分开各个单词。规范的制定，说到底是为了使代码更易于阅读和维护。但现在的 java 编程规范的制定，肯定没考虑过类似中文等其他语言。所以我认为这个规范是有限制的。我们可以考虑用下划线来区分词语。
那JavaBean呢？如果一个类的成员变量都是中文的，那么它的get/set方法怎么写？你自己调用是没问题，放到框架里（Struts2，Hibernate这类的）还能自动设入值吗？
引用统一使用 utf8 是没有问题的，从数据库到网页，全部都用 utf8 相信就不会出现编码的问题。
这样子可移植性大大降低，如果某段代码在其它项目中可以被重用，而那个项目不是UTF-8的，那改动就很大了。
而且中文比英文占用更多的空间，不管是你的原文件还是编译出来的class文件，体积都会变大。
我还真见过人用中文，他说他们老师推荐用中文，容易理解。
看到那些get学生，set学生，我就郁闷。
用中文当变量名、方法名的话可读性没有你想像的那么好吧，你想想你引入的类是英文，而该类对象是中文，让维护的人恶梦啊，不建议这么做。
利：也许你看的时候感觉很好理解
弊：一旦出现编码不一致的问题，中文就会出现乱码，你想一下还能调用的到吗？
虽然我们都知道一般不用中文名，但还真没细想过，关注下
LZ可以看看Java编码规约。
规约不是拍脑袋随便规定的，每一条都有它的道理。
规约里规定类名首字母大写，变量名首字母小写。
如果使用中文的话 将编译好的工程 换个操作系统运行 不知道会出现什么问题
工程内的文件夹的名字一般都统一使用小写
使用小写也是有他的理由 我忘记是那个公司了 好像是sun公司
开发的时候出现了问题 把报名换成小写 就不出问题
所以开始建议 统一用小写
还是按常规来吧
写的时候,要切换输入法.....就这点就相当不方便了.
中文并不一定能改善逻辑的理解.必要的注释还是要的.变量/方法名也不会用很晦涩的单词吧.
相信中国的程序员，都会几句英语吧，编程语言里的关键字全是英文。
没有必要为了自己的母语，把变量也弄成中文。
想让更多人的看懂，可以加些中文注释倒还可以。
用中文倒是真没试过。。。。。
还是英文的通用性高吧。
用中文的话可移植性肯定差了。
已解决问题
未解决问题