谈“良好的代码书写习惯”
有段时间项目要用到其它页面的结构和样式，在使用他人的代码时，出现一些问题
- 从页面上属于该模块的某个图标或按钮的样式却不在这段模块代码中
- class或id定义的路径太深
- 对某个class甚至是从模块的祖先级开始定义
虽然有诸如“图标和按钮要放在公共模块中”，“要通过从祖先级开始定义提高class的优先级”的原因。但是为了提高代码的可移植性应该努力避免这些问题。
不禁想到一些招聘要求中写到的“有着良好的代码书写习惯”，下面这些问题也是工作中常常遇到并需要改正的：
属性书写的排列方向
虽然回车和空格在DW中均能出现代码提示，但是同样一屏横向排列却比纵向排列容纳更多的信息。减少了鼠键的多余操作即提高了开发人员的效率。
尽量合并影响同一元素的属性。
两个相邻兄弟元素之间10像素的补白被“硬生生”分成上一个元素5像素补白和后面元素5像素补白，而且完全可以只定义在其中一个元素上面。导致清除这个10像素的补白要修改两处地方，同时也能减少对浏览器的再次渲染。
css的路径太深。
定义li标签的属性习惯性的从ul标签开始。但如果是从模块的class开始定义，可以省略ul标签。例如父级是类名为module_a的模块下的列表单项li，可以写成
.module_a li而不用.module_a ul li。定义标签或class应该以模块为单位。
这也是近来大家提倡的模块化，提高可移植性及降低耦合。那如何确定这段代码为一个模块呢？其实模块和人一样，也有头部，身体和底部三个部分，可能界限不明显，但还是较容易的划分出来。例如商品详情页面中的浏览历史，头部即标题“最近浏览”，商品列表就是身体部分，“清除历史”是底部。
如何定义公共代码？
按照以前的习惯，我是把所有的图标、按钮和颜色定义都扔在公共代码中即页面中的common部分。但发现有的按钮只有某模块使用，在页面中的其它部分并没有用到过，如果把这个按钮的样式放在公共区域中，会降低模块的可移植性。所以公共代码的界限不应以描述的页面内容区分，而应该通过使用频率界定。
以页面位置还是内容命名？
简单说这两者都不可取。以位置命名容易出现改变位置后该命名并不符合对该模块的描述，十分尴尬-_|||。而以内容命名，例如“热门商品”命名hot_sale，但该模块移植到浏览历史模块后发现也不符合对其描述。正确的命名应该采用命名规范文档中提倡的关键字，例如“side_item”就能对其很好的描述。
古语有云：独乐乐不如众乐乐
，良好的代码书写习惯不仅能提高自身的工作效率，更重要的是有利于团队成员之间无阻碍的合作。
