项目第一期完成的七七八八了，第一次做web工程，所以总是提醒自己是一个学习者来着，多用自己的眼睛和脑袋去积攒一些经验和知识。
这个记录我想记录下对于命名的思考。这个命名包括很多命名，比如：工程命名、包命名、文件命名、类命名、函数命名、变量命名、常量命名；数据库命名、表命名、字段命名、约束命名等等。下面根据自己的感受一个个的用自己的话说说。
1.工程命名
我们的祖先说‘名不正则言不顺“，这话的重要性在其他的命名中可能不重要，但是在一个实施的工程中就十分重要了。我们在学习语言做一些实验的时候总是用些11，df之类的随便的工程名，自己也不重视这个问题，老师也不指出这个问题。这里就说说我们工程在工程命名上吃的亏吧！当工程开发了一个星期的时候，突然有个人提出：我们的工程名拼写错误，当时大家伙就笑我们这群理科生总是不重视英语的学习。但是笑过之后问题总归是要解决的，因为工程是要验收的，别人一看名都不对，我们哪里还能顺得了呢？那就改了，这个工程可不小啊！切记，在我们启动一个工程的时候，把工程名确定好，名正则言顺！
2.包命名
包命名一般都是用com作为第一层，然后是公司名，这种做法很普遍了也很凑效。我这里想说的不是这个，而是在我们工程中出现的两个问题：一、包的深度；二、包下面是不是只能有包或者只能有类；这两个问题的错误处理，导致我们在开发过程中总是要花很多时间去寻找包，同时包的复杂结构也增加了屏幕的占用，致使留给我们进行编码的空白域更少了。这两个虽然是小问题，但是还是很影响开发进度的。当然还有一点就是，如果我们的工程要开源了或者要展示了，那别人一看”不专业“的包结构就发现好累的。我的感觉是包用个3-5层就足够了，用不着到8层的程度吧！即使工程很大也差不多够，再说一个web工程应该不会十分的大的
，耦合度太高根本就不利于扩展。随便打开几个开源的jar包，里面都可以看到 它们没有那种包下面要么全是包，要么全是类的样式，完全可以共存的，只要它们的存放按照一个原则就可以了。
3.文件命名
工程中有这么几类文件：代码文件，例如java文件，interface文件；配置文件，例如xml，hbm.xml文件等等，代码文件的命名放在类命名那里说。这里只说配置文件。需要提出对于大点的工程有些人喜欢设置有很多个配置文件，这 或许在io上或者cache上能做到灵活，但是这也给我们命名带来了困难的，需要衡量好哦！
4.类命名
这是一个老问题了，类命名用名词就不说了，有一点就是要统一开发组的缩写规范，不要一个单词一个人一种缩写，那是十分的不靠谱的。
5.函数命名
说到函数，在项目中，我们底层写的做多的函数数据的增删查改，即add,delete,select和update，那么执行这些类的函数的名称应该怎么搞呢？项目开发过程中，我发现这么个问题：同样是查，有用get前缀的，有用find前缀的；同样是更新，有用save前缀的，有用update前缀的；同样是删除有用delete前缀的，有用del缩写前缀的。这些对整个项目成员来说是不利的。其他人调用api还要查找你的api是用get还是find。所以我建议，如果是java类的工程用get，是C++类工程，用find（很多stl里面用的是find）。函数的名称都名的很好，就是这个前缀，特此说明。
6.变量命名/常量命名/数据库字段命名
常量命名就不多了。这里把数据字段命名和变量命名放到一起，是因为我们的变量名一般都是持久化到数据库中的，即和数据库中的某个字段是对应着的。有一点要特别指出：我们在命名表的字段的时候喜欢用表名作为字段名的前缀，这个做法挺好，也很普遍（感觉可以用不着这么做，都同在一个表下了，重复的概率不大，不过这不是关键）。但是在命名与之对应的变量的名称时一定要注意（我非常建议）不要再为之加上那样的前缀了。那样有个大的弊端：我们会发现getXXX和setxxx这样的函数里面都冗余了那个前缀，而实际上，对于name这样的属性，完全就只是需要getName这样的函数就可以了，这也是正是我们需要的，冗余那么个前缀影响美观不说还影响开发的进度。一句话概况就是：类的成员变量不要加前缀后缀这样的东西，而是用一个简易的名词就可以了。
7.数据库命名
这个不是那么重要，因为修改工程的数据库名只需要修改一下配置文件就可以了，所以这个名放到后期“正”问题也不大，但是不喜欢这么做。
8.表命名/约束命名
表命名最好加上前缀，这个前缀可以是模块名等，有个经验就是list数据库的表格的时候是按照字典顺序的，所以当工程的表很多时，加上前缀可以很好的定位我们需求的表。而对于约束的命名也同此理。
上面，都是我在项目过程中得到的一些理会。