「匈牙利java」匈牙利国旗

今天给各位分享匈牙利java的知识，其中也会对匈牙利国旗进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、使用Java作为程序语言时，好的命名规范有哪些
• 2、关于java里类名和class文件名的首字母大小写问题。
• 3、如何写出优雅Java编程
• 4、java中方法的命名问题 什么by with for 代表什么意思,比如getCardByNo 中的by

使用Java作为程序语言时，好的命名规范有哪些

Package 的命名

Package 的名字应该都是由一个小写单词组成。

Class 的命名

Class 的名字必须由大写字母开头而其他字母都小写的单词组成

Class 变量的命名

变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。

Static Final 变量的命名

Static Final 变量的名字应该都大写，并且指出完整含义。

参数的命名

参数的名字必须和变量的命名规范一致。

数组的命名

数组应该总是用下面的方式来命名:

byte[] buffer;

而不是:

　byte buffer[];

方法的参数

使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字:

SetCounter(int size){

this.size = size;

}

变量名

普通变量命名应该采用首字母小写，其他字母首字母大写的方式。

final static变量的名字应该都大写，并且指出完整含义。如果一个常量名称由多个单词组成，则应该用下划线来分割这些单词如。

NUM_DAYS_IN_WEEK MAX_VALU

如果需要对变量名进行缩写时，一定要注意整个代码中缩写规则的一致性

context=ctx message=msg

通过在结尾处放置一个量词，就可创建更加统一的变量

First(一组变量中的第一个) Last(一组变量中的最后一个) Next(一组变量中的下一个变量) Prev(一组变量中的上一个) Cur(一组变量中的当前变量)

无论什么时候，均提倡应用常量取代数字、固定字符串。也就是说，程序中除0，1以外，尽量不应该出现其他数字。

索引变量：i、j、k等只作为小型循环的循环索引变量。

逻辑变量：避免用flag来命名状态变量，用is来命名逻辑变量。

if(isClosed){ dosomeworks; return; }

数组

总是使用以下方式定义数组：

int[] arr = new int[10];

禁止使用C语言的是形式：

禁止 int arr[] = new int[10];

集合

数组或者容器推荐命名方式为名词+s的方式，例如：

　List persons = getPerson(); for(Person person : persons){ dosomeworks; }

泛型

应该尽量简明扼要(最好是一个字母)，以利于与普通的class或interface区分

Container中的Element应该用E表示;Map里的key用K表示，value用V;Type用T表示;异常用X表示

如果需要接收多个Type类型的参数，应该用邻接T的大写字母——例如S——来依次表示，当然也可以用T1, T2这样的方式

public class HashSet extends AbstractSet {…} public class HashMapextends AbstractMap {…} public class ThreadLocal {…} public interface Functor { T val() throws X; }

推荐的命名

1.当要区别接口和实现类的时候，可以在类的后面加上“Impl”。

interface Container class ContainerImpl

2.Exception类最好能用“Exception”做为类命名的结尾

DataNotFoundException InvalidArgumentException

3.抽象类最好能用“Abstract”做为类命名的开头

AbstractBeanDefinition AbstractBeanFactory

4. Test类最好能用“Test”做为类命名的结尾

ContainerTest

5.简称与缩写(不推荐使用)

cp代表colorPoint buf代表buffer off代表offset len代表length

除非是在循环中，否则一般不推荐使用单个字母作为变量名，不过也有例外，即约定俗成的单个字母

b代表byte c代表char d代表double e代表Exception f代表float i, j, k代表整数 l代表long o代表Object s代表String v代表某些类型的特定值

代码风格

花括号

花括号统一采用以下格式：

if(bool experssion){ dosomework; }

除非花括号中为空，不然任何情况下不能省略花括号，并且花括号必须换行，例如：

if(i==0){ return; } while(true) {}

以下写法禁止出现：

禁止 if(i != 0) return; 禁止 if(i !=0) {return;}

括号

括号的前，后一个字符不需要空格，例如：

　Person p = new Person(“Jack”， 17);

空格

逗号之后紧跟一个空格。

Person p = new Person(“Jack”， 16, “China”);

二元操作符前后跟空格。

int i = a + b – c * d;

3. 一元操作符不需要空格，for语句分号后有空格。

for(int i = 0; I 10; i++){ dosomework; }

4. 括号前后不需要空格

类

类的定义结构按照顺序为：

1) 常量

2) 成员变量

3) 构造函数

4) 成员函数

5) get和set方法

各个部分之间留出一个空行。

例如：

规范类模板：

class Person{ private final static int MAX_AGE = 100; private String firstname = “Jack”; public Person(){} public Person(String firstname){ this.firstname = firstname; } public void doExercise(){ dosomeworks; run(); } private void run(){ dosomeworks; } public getFirstname(){ return firstname; } public setFirstname(String firstname){ this.firstname = firstname; } }

2.构造函数

1) 参数为空的构造函数出现在最上方

2) 有调用关系的构造函数相邻

3) 参数尽量由少到多从上至下排序

3.使用成员变量

在类的方法内引用成员变量了命名冲突以外，不使用this。非特殊情况在类的方法内都不使用get和set方法存取成员变量。

4.方法

有调用关系的方法尽量放在相邻的位置，public和private方法可以交叉放置。

5.get和set方法，所有需要公开的成员变量都要符合良好的javabean规范，提供get和set方法，尽量使用IDE工具自动生成。

Javadoc注释

在每个程序的最开始部分，一般都用Javadoc注释对程序的总体描述以及版权信息，之后在主程序中可以为每个类、接口、方法、字段添加 Javadoc注释，每个注释的开头部分先用一句话概括该类、接口、方法、字段所完成的功能，这句话应单独占据一行以突出其概括作用，在这句话后面可以跟随更加详细的描述段落。在描述性段落之后还可以跟随一些以Javadoc注释标签开头的特殊段落，例如上面例子中的@auther和@version，这些段落将在生成文档中以特定方式显示

关于java里类名和class文件名的首字母大小写问题。

小写是可以，但是习惯首字母大写；并且java文件名要和类名一样，这是规定。

网上找了个编程规范，供参考：

3. 命名约定

所有变量的定义应该遵循匈牙利命名法，它使用3字符前缀来表示数据类型，3个字符的前缀必须小写，前缀后面是由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行正确的断句。

这样，在一个变量名就可以反映出变量类型和变量所存储的值的意义两方面内容，这使得代码语句可读性强、更加容易理解。

3.1 包、类及方法命名

标示符类型 命名约定 例子

包 全部小写。

 标识符用点号分隔开来。为了使包的名字更易读，Sun 公司建议包名中的标识符用点号来分隔。

 Sun 公司的标准 java 分配包用标识符 .java 开头。

 全局包的名字用你的机构的 Internet 保留域名开头 。 局部包：

interface.screens

全局包：

com.rational.www. interface.screens

类，接口  类的名字应该使用名词。

 每个单词第一个字母应该大写。

 避免使用单词的缩写，除非它的缩写已经广为人知，如HTTP。 Class Hello ;

Class HelloWorld ;

Interface Apple ;

方法  第一个单词一般是动词。

 第一个字母是小些，但是中间单词的第一个字母是大写。

 如果方法返回一个成员变量的值，方法名一般为get+成员变量名，如若返回的值是bool变量，一般以is作为前缀。

 如果方法修改一个成员变量的值，方法名一般为：set + 成员变量名。

getName();

setName();

isFirst();

变量  第一个字母小写，中间单词的第一个字母大写。

 不要用_或作为第一个字母。

 尽量使用短而且具有意义的单词。

 单字符的变量名一般只用于生命期非常短暂的变量。i,j,k,m,n一般用于integers；c,d,e一般用于characters。

 如果变量是集合，则变量名应用复数。

 命名组件采用匈牙利命名法，所有前缀均应遵循同一个组件名称缩写列表。 String myName;

int[] students;

int i;

int n;

char c;

btNew;

(bt是Button的缩写)

常量  所有常量名均全部大写，单词间以‘_’隔开。 int MAX_NUM;

3.2 其它

开发人员如果遇到上述表格中未列举的类型，请书面通知相关管理人员，由管理人员集中更新列表内容，不得擅自启用未经确定的新变量前缀。

4. 使用常量

4.1 使用常量

1. 常数很容易在数据输入时出错

常数存在的主要问题之一是你很容易在键入数字时出错，从而颠倒了数字的位置。例如，当你键入数字10876时，很容易的键入10867或18076。与处理变量和保留字的方法不同，编译器并不在乎颠倒了位置和不正确的数字，有时简单的错误造成的问题不会立即表现出来，而当问题表现出来时，它们会以随机的计算错误的形式出现，这些错误很难准确定位。用常量来取代常数时，编译器将在编译时检查常量的有效性。如果常量不存在，编译器便将这一情况通知你，并拒绝进行编译，这可以消除错误键入的数字带来的问题，只要常量拥有正确的值，使用该常量的所有代码也有使用该正确值。

2. 常数很难不断更新

3. 常量使代码更容易阅读

使用常量后，得到的一个额外好处是可使创建的代码更容易阅读。常数很不直观。也许你对常数非常了解，但其他人则根本看不明白。通过合理的给常量命名，使用这些常量的代码就变得比较直观了，更容易阅读。

为常量赋予较宽的作用域，这与使用变量时的情况不同。在一个应用程序中你决不应该两次创建相同的常量。如果你发现自己复制了一个常量，请将原始的常量说明转至较宽的作用域，直到该常量可供引用它的所有方法为止。

5. 变量

5.1 定义有焦点的变量

用于多个目的的变量称为无焦点（多焦点）的变量。无焦点变量所代表的意义与程序的执行流程有关，当程序处于不同位置时，它所表示的意义是不固定的，这样就给程序的可读性和可维护性带来了麻烦。

5.2 只对常用变量名和长变量名进行缩写

如果需要对变量名进行缩写时，一定要注意整个代码中缩写规则的一致性。例如，如果在代码的某些区域中使用Cnt，而在另一些区域中又使用Count，就会给代码增加不必要的复杂性。

变量名中尽量不要出现缩写。

5.3 使用统一的量词

通过在结尾处放置一个量词，就可创建更加统一的变量，它们更容易理解，也更容易搜索。例如，请使用strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。

量词列表：

量词后缀 说明

First 一组变量中的第一个

Last 一组变量中的最后一个

Next 一组变量中的下一个变量

Prev 一组变量中的上一个

Cur 一组变量中的当前变量

5.4 使用肯定形式的布尔变量

给布尔变量命名时，始终都要使用变量的肯定形式，以减少其它开发人员在理解布尔变量所代表的意义时的难度。

5.5 为每个变量选择最佳的数据类型

这样即能减少对内存的需求量，加快代码的执行速度，又会降低出错的可能性。用于变量的数据类型可能会影响该变量进行计算所产生的结果。在这种情况下，编译器不会产生运行期错误，它只是迫使该值符合数据类型的要求。这类问题极难查找。

5.6 尽量缩小变量的作用域

如果变量的作用域大于它应有的范围，变量可继续存在，并且在不再需要该变量后的很长时间内仍然占用资源。

它们的主要问题是，任何类中的任何方法都能对它们进行修改，并且很难跟踪究竟是何处进行修改的。

占用资源是作用域涉及的一个重要问题。对变量来说，尽量缩小作用域将会对应用程序的可靠性产生巨大的影响。

8. 表达式和语句

8.1 每行应该只有一条语句。

8.2 if-else,if-elseif语句，任何情况下，都应该有“{”，“}”，格式如下：

if (condition) {

statements;

} else if (condition) {

statements;

} else{

statements;

}

8.3 for语句格式如下：

for (initialization; condition; update) {

statements;

}

如果语句为空：

for (initialization; condition; update) ;

8.4 while语句格式如下：

while (condition) {

statements;

}

如果语句为空:

while (condition);

8.5 do-while语句格式如下：

do {

statements;

} while (condition);

8.6 switch语句，每个switch里都应包含default子语句,格式如下：

switch (condition) {

case ABC:

statements;

/* falls through */

case DEF:

statements;

break;

case XYZ:

statements;

break;

default:

statements;

break;

}

8.7 try-catch语句格式如下：

try {

statements;

} catch (ExceptionClass e) {

statements;

} finally {

statements;

}

11. 可移植性

1. 尽量不要使用已经被标为不赞成使用的类或方法。

2. 如果需要换行的话，尽量用 println 来代替在字符串中使用"\n"。

3. 用separator()方法代替路径中的”/”或”\” 。

4. 用pathSeptarator()方法代替路径中的 ” : ” 或 ” ;” 。

如何写出优雅Java编程

如何写出好的Java代码

1.

优雅需要付出代价。从短期利益来看，对某个问题提出优雅的解决方法，似乎可能花你更多的时间。但当它终于能够正确执行并可轻易套用于新案例中，不需要花上数以时计，甚至以天计或以月计的辛苦代价时，你会看得到先前所花功夫的回报(即使没有人可以衡量这一点)。这不仅给你一个可更容易开发和调试的程序，也更易于理解和维护。这正是它在金钱上的价值所在。这一点有赖某种人生经验才能够了解，因为当你努力让某一段程序代码变得比较优雅时，你并不是处于一种具生产力的状态下。但是，请抗拒那些催促你赶工的人们，因为那么做只会减缓你的速度罢了。

2.

先求能动，再求快。即使你已确定某段程序代码极为重要，而且是系统的重要瓶颈，这个准则依然成立。尽可能简化设计，让系统能够先正确动作。如果程序的执行不够快，再量测其效能。几乎你总是会发现，你所认为的”瓶颈”其实都不是问题所在。把你的时间花在刀口上吧。3.

记住”各个击破”的原理。如果你所探讨的问题过于混杂，试着想像该问题的基本动作会是什么，并假设这一小块东西能够神奇地处理掉最难的部分。这”一小块”东西其实就是对象–请撰写运用该对象的程序代码，然后检视对象，并将其中困难的部分再包装成其他对象，依此类推。

4. 区分class开发者和class使用者(使用端程序员)。Class

使用者扮演着”客户”角色，不需要(也不知道)class的底层运作方式。Class开发者必须是class设计专家，并撰写class，使它能够尽可能被大多数新手程序员所用，而且在程序中能够稳当执行。一套程序库只有在具备通透性的情况下，使用起来才会容易。

5.当你撰写class时，试着给予明了易懂的名称，减少不必要的注解。你给客户端程序员的接口，应该保持概念上的单纯性。不了这个目的，当函数的重载(overloading)适合制作出直觉、易用的接口时，请善加使用。

6. 也必你的分析和设计必须让系统中的classes保持最少，须让其Public

interfaces保持最少，以及让这些classes和其他classes之间的关联性( 尤其是base

classes)保持最少。如果你的设计所得结果更甚于此，请问问自己，是否其中每一样东西在整个程序生命期中都饶富价值?如果并非如此，那么，维护它们会使你付出代价。开发团队的成员都有不维护”无益于生产力提升”的任何东西的倾向;这是许多设计方法无法解释的现象。

7.

让所有东西尽量自动化。先撰写测试用的程序代码(在你撰写class之前)，并让它和class结合在一起。请使用makefile或类似工具，自动进行测试动作。通过这种方式，只要执行测试程序，所有的程序变动就可以自动获得验证，而且可以立即发现错误。由于你知道的测试架构所具备的安全性，所以当你发现新的需求时，你会更勇于进行全面修改。请记住，程序语言最大的改进，是来自型别检查、异常处理等机制所赋予的内置测试动作。但这些功能只能协助你到达某种程度。开发一个稳固系统时，你得自己验证自己的classes或程序的性质。

8. 在你撰写class之前先写测试码，以便验证你的class 是否设计完备。如果你无法撰写测试码，你便无法知道你的class

的可能长相。撰写测试码通常能够显现出额外的特性(features)或限制 (

constraints)__它们并不一定总是能够在分析和设计过程中出现。测试码也可做为展示class 用法的示例程序。

9. 所有软件设计上的问题，都可以通过”引入额外的概念性间接层(conceptual

indirection)”加以简化。这个软件工程上的基础法则是抽象化概念的根据，而抽象化概念正是面向对象程序设计的主要性质。10.

间接层(indirection)应该要有意义(和准则-9致)。这里所指的意义可以像”将共用程序代码置于惟一函数”这么简单。如果你加入的间接层(或抽象化、或封装等等)不具意义，它可能就和没有适当的间接层一样糟糕。

11.

让class尽可能微小而无法切割(atomic)。赋予每个class单一而清楚的用途。如果你的classes或你的系统成长得过于复杂，请将复杂的classes切割成比较简单的几个classes。最明显的一个判断指针就是class的大小：如果它很大，那么它工作量过多的机会就可能很高，那就应该被切割。重新设计class的建议线索是：

1) 复杂的switch语句：请考虑运用多态(Polymorphism)。 2)

许多函数各自处理类型极为不同的动作：请考虑切割为多个不同的(classes)。

12. 小心冗长的引数列(argument

lists)。冗长的引数列会使函数的调用动作不易撰写、阅读、维护。你应该试着将函数搬移到更适当的class中，并尽量以对象为引数。

13. 不要一再重复。如果某段程序代码不断出现于许多derived class函数中，请将该段程序代码置于某个base class

函数内，然后在derived

class函数中调用。这么做不仅可以省下程序代码空间，也可以让修改该段程序代码动作更易于进行。有时候找出此种共通程序代码还可以为接口增加实用功能。

14. 小心switch语句或成串的if-else 子句。通常这种情况代表所谓的”type-check

coding”。也就是说究竟会执行哪一段程序代码，乃是依据某种型别信息来做抉择(最初，确切型别可能不十分明显)。你通常可以使用继承和多态来取代此类程序代码;Polymorphical

method (多态函数)的调用会自动执行此类型别检验，并提供更可靠更容易的扩充性。

15. 从设计观点来看，请找出变动的事物，并使它和不变的事物分离。也就是说，找出系统中可能被你改变的元素，将它们封装于classes中。

16. 不要利用subclassing来扩充基础功能。如果某个接口元素对class而言极重要，它应该被放在base class

里头，而不是直到衍生(derivation)时才被加入。如果你在继承过程中加入了函数，或许你应该重新思考整个设计。

17. 少就是多。从class

的最小接口开始妨展，尽可能在解决问题的前提下让它保持既小又单纯。不要预先考量你的class被使用的所有可能方式。一旦class被实际运用，你自然会知道你得如何扩充接口。不过，一旦class被使用后，你就无法在不影响客户程序代码的情况下缩减其接口。如果你要加入更多函数倒是没有问题–不会影响既有的客户程序代码，它们只需重新编译即可。但即使新函数取代了旧函数的功能，也请你保留既有接口。如果你得通过”加入更多引数”的方式来扩充既有函数的接口，请你以新引数写出一个重载化的函数;通过

这种方式就不会影响既有函数的任何客户了。

18. 大声念出你的classes,确认它们符合逻辑。请base class和derived class

之间的关系是”is-a”(是一种)，让class和成员对象之间的关系是”has-a”(有一个)。

19.

当你犹豫不决于继承(inheritance)或合成(组合，composition)时，请你问问自己，是否需要向上转型(upcast)为基础型别。如果不需要，请优先选择合成(也就是是使用成员对象)。这种作法可以消除”过多基础型别”。如果你采用继承，使用者会认为他们应该可以向上转型。

20. 运用数据成员来表示数值的变化，运用经过覆写的函数(overrided method)来代表行为的变化 。也就是说，如果你找到了某个

class, 带有一些状态变量，而其函数会依据这些变量值切换不同的行为，那么你或许就应该重新设计，在subclasses 和覆写后的函数(overrided

methods)中展现行为止的差异。

21.

小心重载(overloading)。函数不应该依据引数值条件式地选择执行某一段程序代码。这种情况下你应该撰写两个或更多个重载函数(overloaded

methods)22. 使用异常体系(exception hierarchies)最好是从Java标准异常体系中衍生特定的classes,

那么，捕捉异常的人便可以捕捉特定异常，之后才捕捉基本异常。如果你加入新的衍生异常，原有的客户端程序仍能通过其基础型别来捕捉它。

23.

有时候简单的聚合(aggregation)就够了。飞机上的”旅客舒适系统”包括数个分离的元素：座椅、空调、视讯设备等等，你会需要在飞机上产生许多这样的东西。你会将它们声明为Private成员并开发出一个全新的接口吗?不会的，在这个例子中，元素也是Public接口的一部分，所以仍然是安全的。当然啦，简单聚合并不是一个常被运用的解法，但有时候的确是。

24. 试着从客户程序员和程序维护的角度思考。你的class应该设计得尽可能容易使用。你应该预先考量可能性有的变动，并针对这些

可能的变动进行设计，使这些变动日后可轻易完成。

25.

小心”巨大对象并发症”。这往往是刚踏OOP领域的过程式(procedural)程序员的一个苦恼，因为他们往往最终还是写出一个过程式程序，并将它们摆放到一个或两个巨大对象中。注意，除了application

framework (应用程序框架，译注：一种很特殊的、大型OO程序库，帮你架构程序本体)之外，对象代表的是程序中的观念，而不是程序本身。

26. 如果你得用某种丑陋的方式来达成某个动作，请将丑陋的部分局限在某个class里头。

27.

如果你得用某种不可移植方式来达成某个动作，请将它抽象化并局限于某个class里头。这样一个”额外间接层”能够防止不可移植的部分扩散到整个程序。这种作法的具体呈现便是Bridge设计模式(design

pattern)。28.

对象不应仅仅只用来持有数据。对象也应该具有定义明确界限清楚的行为。有时候使用”数据对象”是适当的，但只有在通用形容器不适用时，才适合刻意以数据对象来包装、传输一群数据项。

29.

欲从既有的classes身上产生新的classes时，请以组合(composition)为优先考量。你应该只在必要时才使用继承。如果在组合适用之处你却选择了继承，你的设计就渗杂了非必要的复杂性。

30.

运用继承和函数覆写机制来展现行为上的差异，运用fields(数据成员)来展现状态上的差异。这句话的极端例子，就是继承出不同的classes表现各种不同的颜色，而不使用”color”field.31.

当心变异性(variance)。语意相异的两个对象拥有相同的动作(或说责任)是可能的。OO世界中存在着一种天生的引诱，让人想要从某个class继承出另一个subclass,为的是获得继承带来的福利。这便是所谓”变异性”。但是，没有任何正当理由足以让我们强迫制造出某个其实并不存在的superclass/subclass关系。比较好的解决方式是写出一个共用的base

class,它为两个derived

classes制作出共用接口–这种方式会耗用更多空间，但你可以如你所盼望地从继承机制获得好处，而且或许能够在设计上获得重大发现。

32.

注意继承上的限制。最清晰易懂的设计是将功能加到继承得来的class里头;继承过程中拿掉旧功能(而非增加新功能)则是一种可疑的设计。不过，规则可以打破。如果你所处理的是旧有的class程序库，那么在某个class的subclass限制功能，可能会比重新制定整个结构(俾使新class得以良好地相称于旧

class)有效率得多。

33. 使用设计模式(design patterns)来减少”赤裸裸无加掩饰的机能(naked

functionality)”。举个例子，如果你的class只应该产出惟一一个对象，那么请不要以加思索毫无设计的手法来完成它，然后撰写”只该产生一份对象”这样的注解就拍拍屁股走人。请将它包装成singleton(译注：一个有名的设计模式，可译为”单件”)。如果主程序中有多而混乱的”用以产生对象”的程序代码，请找出类似

factory method这样的生成模式(creational patterns)，使价钱可用以封装生成动作减少”赤裸裸无加掩饰的机能”(naked

functionality)不仅可以让你的程序更易理解和维护，也可以阻止出于好意却带来意外的维护者。

34. 当心”因分析而导致的瘫痪(analysis

paralysis)”。请记住，你往往必须在获得所有信息之前让项目继续前进。而且理解未知部分的最好也最快的方式，通常就是实际前进一步而不只是纸上谈兵。除非找到解决办法，否则无法知道解决办法。Java拥有内置的防火墙，请让它们发挥作用。你在单一class或一组classes中所犯的错误，并不会伤害整个系统的完整性。

35.

当你认为你已经获得一份优秀的分析、设计或实现时，请试着加以演练。将团队以外的某些人带进来-他不必非得是个顾问不可，他可以是公司其他团队的成员。请那个人以新鲜的姿态审视你们的成果，这样可以在尚可轻易修改的阶段找出问题，其收获会比因演练而付出的时间和金钱代价来得高。实现

(Implementation)

36. 一般来说，请遵守Sun的程序编写习惯。

37.

无论使用何种编写风格，如果你的团队(或整个公司，那就更好了)能够加以标准化，那么的确会带来显著效果。这代表每个人都可以在其他人不遵守编写风格修改其作品，这是个公平的游戏。标准化的价值在于，分析程序代码时所花的脑力较小，因而可以专心于程序代码的实质意义。

38. 遵守标准的大小写规范。将

class名称的第一个字母应为大写。数据成员、函数、对象(references)的第一个字母应为小写。所有识别名称的每个字都应该连在一块儿，所有非首字的第一个字母都应该大写。例如：

ThisIsAClassName thisIsAMethodOrFieldName 如果你在static final

基本型别的定义处指定了常量初始式(constant initializers),那么该识别名称应该全为大写，代表一个编译期常量。

Packages是个特例，其名称皆为小写，即使非首字的字母亦是如此。域名(org, net, edu 等等)皆应为小写。(这是Java 1.1迁移至Java

2时的一项改变) 。

39、不要自己发明”装饰用的”Private数据成员名称。通常这种的形式是在最前端加上底线和其他字符，匈牙利命名法(Hungarian

notation)是其中最差的示范。在这种命名法中，你得加入额外字符来表示数据的型别、用途、位置等等。仿佛你用的是汇编语言(assembly

language)而编译器没有提供任何协肋似的。这样的命名方式容易让人混淆又难以阅读，也不易推行和维护。就让classes和packages来进行”名称上的范围制定(name

scoping)”吧。

40、当你拟定通用性的class时，请遵守正规形式(canonical form)。包括equals( )、hashCode( )、clone( )

( 实现出Cloneable),并实现出Comparable和Serialiable等等。

41、对于那些”取得或改变Private数据值”的函数，请使用Java Beans

的”get”、”set”、”is”等命名习惯，即使你当时不认为自己正在撰写Java

Bean。这么做不仅可以轻易以Bean的运用方式来运用你的class,也是对此类函数的一种标准命名方式，使读者更易于理解。

42、对于你所拟定的每一个class，请考虑为它加入static public test(

)，其中含有class功能测试码。你不需要移除该测试就可将程序纳入项目。而且如果有所变动，你可以轻易重新执行测试。这段程序代码也可以做为class的使用示例。

43、有时候你需要通过继承，才得以访问base class的protected成员。这可能会引发对多重基类(multiple base

types)的认识需求。如果你不需要向上转型，你可以先衍生新的class发便执行protected访问动作，然后在”需要用到上述

protected成员”的所有classes中，将新class声明为成员对象，而非直接继承。

44、避免纯粹为了效率考量而使用final函数。只有在程序能动但执行不够快时，而且效能量测工具(profiler)显示某个函数的调用动作成为瓶颈时，才使用final函数。

45、如果两个classes因某种功能性原因而产生了关联(例如容器containers和迭代器iterators),那么请试着让其中某个class成为另一个class

的内隐类(inner class)。这不仅强调二者间的关联，也是通过”将class名称嵌套置于另一个class 内”而使同一个class

名称在单一Package中可被重复使用。Java 容器库在每个容器类中都定义了一个内隐的(inner)Iterator

class,因而能够提供容器一份共通接口。运用内隐类的另一个原因是让它成为private实现物的一部分。在这里，内隐类会为信息隐藏带来好处，而不是对上述的class关联性提供肋益，也不是为了防止命名空间污染问题(namespace

pollution)。

46、任何时候你都要注意那些高度耦合(coupling)的 classes.请考虑内隐类(inner

classes)为程序拟定和维护带来的好处。内隐类的使用并不是要去除classes间的耦合，而是要让耦合关系更明显也更便利。

47、不要成为”过早最佳化”的牺牲品。那会让人神经错乱。尤其在系统建构初期，先别烦恼究竟要不要撰写(或避免)原生函数(native

methods)、要不要将某些数声明为final、要不要调校程序代码效率等等。你的主要问题应该是先证明设计的正确性，除非设计本身需要某种程度的效率。

java中方法的命名问题 什么by with for 代表什么意思,比如getCardByNo 中的by

首先，程序开发中，变量、方法名应该尽可能的定义做到顾名思义，即让人看到你的名称就大概的知道其的含义了。

其次，by with for三个都是英语中的介词，他们在上面的定义中跟在英语的意思是一样的，即是"以...、用....、通过...."的意思，就比如你题目中方法，意思就是通过卡号获取卡片信息。

现在大体明白了吧。

有问题欢迎提问，满意请采纳！

匈牙利java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于匈牙利国旗、匈牙利java的信息别忘了在本站进行查找喔。