开发前端时的代码风格

1.前端传递到后台的数据要有验证。但是验证规则不必太复杂

2.对于<input type="text“ />输入框，最好trim()一下。对用户输入的内容头尾进行去空格处理

3.对用户输入信息的长度要作必要的限制

2.错误提示信息要有统一的风格。比如弹出框提示错误，比如在输入栏旁边加一个提示错误的span,比如在页面上醒目的位置专门留出一个div.显示错误信息

3.错误信息要简洁明了。如果验证的数据非常多的话，在弹出框的时候，最好不要一次性显示所有的错误信息。

4.可以在每个输入栏输入完成的时候验证，也可以在提交表单的时候验证。推荐前者

后台方法的代码风格

1.所有的dao继承一个共同的业务BizDao,所有的service继承一个共同的业务BizService，所有的实体类继承一个共同的BaseEntity.然后把所有的dao都用到的方法写在BizDao里面，比如获取session的方法。把所有的service都用到的方法写在BizService里面。比如记录日志的方法

2.在写service的时候，最好将service和dao分开。关于service和dao的区别，我自己的个人理解是，service是面向业务的，dao是面向数据操作的。service里面的方法，可能调用多个dao的方法。而dao里面的方法，理想状态下，只操作一次数据

4.dao里面，不要对异常进行处理，有异常的话全部抛出去，放在servic里处理

4.service里面的方法，命名的时候除了规范，最好有一定的规律。比如如果只是查询数据库，不会对数据进行写操作，将方法统一命名为getXXX().如果要对数据进行写操作，将方法统一命名为doXXX().这样做的好处，你在在管理事务的时候，会非常清晰的感觉到。

5.controller里的方法不要抛出异常。我的确见到过有人在controller里面的方法居然throws Exception.你把这个异常抛出去交给谁处理啊？我的建议是：控制器里面不要有任何对异常处理的代码。把异常全部放在service里面处理.当然,在spring mvc 里面,你可以通过配置文件来处理异常,这个时候你可以在controller里面抛出异常

6.千万千万要记住，写注释。不仅仅是与人方便，于己方便。当有一天需要修改功能的时候，你随手写的一行注释可能会给你带来莫大的帮助。

7.不要用new/old等带有不确定的时间的词语来为方法、类、变量命名。在开发中经常遇到这样的情况，因为需求的变更，不得不修改一些方法。与此同时，以前的方法你还想保留着,假如方法的名字叫做methdo().这个时候，很多人都喜欢把以前的方法改为methodOld(),重新写一个命名为method的方法。这样调用的方法名不变，其它的地方的代码都不用修改，看起来方便极了。但是，一段时间以后，需求又做了变更，或许你就要对着两个方法研究半天才能弄明白两个方法的区别。重新写一个方法，建议命名规则在原方法的基础上，加上改变的功能。比如methodAddLog()

编写前端页面时 须遵循如下原则:

1. 不可利用IDE的视图模式’画’代码;

2. 不可利用IDE生成相关功能代码, 比如Dw内置的一些功能js;

3. 编码必须格式化, 比如缩进;

测试工具: 前期开发仅测试FireFox & IE6 & IE7 & IE8 , 后期优化时加入Opera & Chrome & Safari;

建议测试顺序: FireFox–>IE7–>IE8–>IE6–>Opera–>Chrome–>Safari, 建议安装firebug及IE Tab Plus插件.

其他规范

js的位置有的人喜欢放在body的前面,有的人喜欢放在后面.我个人的理解是,如果不是和页面展示有关的JS,比如页面dom节点的动作的绑定,放在bidy后面,和页面展示有关的JS,放在body的前面,比如加载数据,根据逻辑隐藏页面元素等.如果不确定放在前面还是后面,优先放在前面

通过CSS定义元素属性的时候,继承决定了一个元素没有应用任何样式时应该怎么显示,而特殊性则决定了应用多个规则时应该怎么显示.根据特殊性原则,选择器越特殊,规则就越强.内联样式表定义的规则(在节点内定义,如:<div style="background:#FFF;">)是最特殊的,其次是id选择器定义的规则,带有class的选择器比不带有class的选择器特殊性要强,多个class属性选择器比单个class属性选择器要强.元素名的选择器的特殊性最低,可以被其他任何选择器规则覆盖.如果选择器规则的特殊性相同,那么晚出现的规则具有较高的特殊性