我先给出我的编程规范:
<变量的命名>
结构:[有效范围]+<类型识别>+[变量具体有意义的名称]
说明:有效范围是指如类的数据成员(属性)还是成员方法里的局部,m_代表类的数据成员(属性),没有该有效范围标识时,该变量的有效范围只是成员方法里的局部的。
类型标识是指该变量的类型,如n表示int类型。
变量具体有意义的名称要求要表明该变量的实际意义,名称长一点也无所谓,最重要是标识它代表的实际意义,名称里面每个单词的首字母大字。
举例:m_szLogPath,表示该变量是类的数据成员(属性),是字符串类型,用来存放日志的路径的,这样整个变量看起来就一目了然了,知道它代表的意义和作用范围,不用花功夫向前翻看它代表的意义了。成员方法局部变量:
int类型以n开头,如nNum
char类型以ch开头,如chState
boolean类型以b开头,如bAutoDump
String类型以sz开头,如szSql 特殊类型:
数组类型,以List结尾,如int数组类型,nPosList类数据成员变量:
都以m_开头(m代表member),如m_szLogPath<函数的命名>
与java中函数一般命名规范差不多
动词+名词,其中动词的字母全小写,名词的第一个字母大写
如:getParameter()<文件的命名>
尽量使用名词其中每个单词的首字母都要大写
如:CfgFile希望大家踊跃讨论一下!

解决方案 »

  1.   

    看到n,sz...,就想起c++,这样看着比较清楚,但getNxx,setSzXxx看起来好像有点别扭可以参考  Java语言编码规范(Java Code Conventions)
      

  2.   

    其实getNxx的话,可以变通一下,不要N,就getXx()就ok了
      

  3.   

    但有些代码是用工具产生get/set的规范就是一个约定了,各公司也都不完全一致,适合自己就行
      

  4.   

    楼主列举的基本上我觉得毫无意义看jdk的各个包、类、方法命名,尽可能遵照
      

  5.   

    个人感觉在java语言中,这样的命名规则有的适合有的不适合,要分别讨论1、成员方法局部变量的命名用类型开头,这其实是匈牙利命名法,在c、c++中非常有用,但在java中却价值不大,因为:
    java语言是一种强类型语言,不同类型的变量之间赋值时,一定要先转型,否则开发工具肯定会报错,如果你用EditPlus等来写代码,编译的时候也肯定
    会报错。但反过来说,这样做也没什么坏处。2、特殊类型: 数组类型,以List结尾,如int数组类型,nPosList这样做有好处,如果是对象的List,最好把对象的类型写上,在支持泛型的jdk1.5中这样做可能意义不大,但在jdk以前的版本,这样做可以知道List中该放什么值。3、类数据成员变量:都以m_开头(m代表member),如m_szLogPath
    答:感觉这样做十分没有必要,而且会降低开发效率。
      因为从外部看一个class除了成员变量就是成员方法,没有必要加一个"m_"的前缀,如果要加的话,是不是成员方法前也要加一个"m_"?
    java本身不存在全局变量,类数据成员变量与方法内的局部变量同名时,类数据成员变量会被隐藏,其值不会受到影响,
    实际中我们也经常这么用 如:setVar1(String var1){this.var1 = var1;} ,如果你要在成员方法中大量的使用成员变量的话,建议在变量前加this关键字,或者直接用
    该变量的setter或getter进行操作,这样做会更灵活。如果以“m_” 开头,除了多敲两个字符外,没有实际意义,而且生成的getter,setter 会是这个样子getM_var1(),难看且难以理解。
    手工改成getVar(),serVar()明显会增加工作量,有的class可能会有十几、二十个类变量,每个都要手工改?而且改完之后还必须用肉眼去检查
    改的对不对,全不全。相反用开发工具可就方便多了,一个快捷键直接全部生成,还有检查的作用,而且在有些情况下默认的getter、setter还有其他作用,
    如struts,在加载form时 会利用setter将<html:form>的属性 填充到formBean中,如果手工改了setter,恐怕Struts这里会出问题。<函数的命名>
    <文件的命名>
    都没什么意见。
    但包的命名一定要都用小写,否则会出问题(Think in java中有提到,但会出什么问题,没有说)。最后摘了一段Think in java 2nd 中的话,大家可以参考参考。
    Don’t create your own “decorated” private data member names. This is usually seen in the form of prepended 
    underscores and characters. Hungarian notation is the worst example of this, where you attach extra characters 
    that indicate data type, use, location, etc., as if you were writing assembly language and the compiler provided
     no extra assistance at all. These notations are confusing, difficult to read, and unpleasant to enforce and
      maintain. Let classes and packages do the name scoping for you.
      

  6.   

    5年前匈牙利命名法(就是楼主你这种)是当时的经典,但是自从
    design pattern流行,讲究小巧结构,功能明确的类,变量名也不会太多,因此表示变量类型的字母就没什么作用了。自从java code conventions出来后,标志着匈牙利命名法的时代已经过去。
      

  7.   

    hanIyan(寒)-----谢谢这位兄弟,给予我宝贵的意见
    特别是:
    如果你要在成员方法中大量的使用成员变量的话,建议在变量前加this关键字,或者直接用
    该变量的setter或getter进行操作,这样做会更灵活。这句话给予我启发。我觉得用匈牙利命名法还是必要的,如果是大项目的话,变量名也会很多,难以避免的,为了提高可读性,这种方法也是有好处的“过渡追求编程规范,也许是另一个《人月神话》”
    re:规范总得有的
        学政治上的一句话:有法必依,执法必严
      

  8.   

    大项目就不行?建议你读一读<<重构>>,多看看开源项目的源码,尤其是那些框架级的。