读《代码整洁之道》前四章浅显印象 和 我所见的不整洁代码引以为戒

1.根本----良好端正的态度。

2.命名----有意义，规范，可搜索的名称，使用源自问题领域的名称，至少避免误导。

3.类名----名词或者名词短语。

4.方法----应当是动词或者动词短语。

5.双关----最好不要用这种，谁知道add是添加还是相加呢？

6.函数----要短小，印象最深的就是，一个函数只做一件事儿，即使我们需要用到try -catch，也要再独立成一个方法，并且这个方法的第一个单词应该是try。

7.注释----代码即注释当然是最高境界，当我们想写注释才能更好的表达程序的时候，想想有没有更好的修改办法。如果必须注释，那么注释必须要。

              简洁，并且注释同样需要维护，也许随着代码的演变，旧的注释就变得没有意义了。

 

---------------------------以上内容有待后续追加---------------------------------------------

反例：我所见到的让人厌恶的代码，引以为戒

         1.处理相似的逻辑和功能时，完全复制代码，毫无个人思想，甚至方法，对象，变量命名都不做修改，更甚至复制来的注释也不修改。

         2.一个方法几十行甚至更多--一个屏幕装不下，就拿一段jq异步代码来说吧，异步是一件事儿，获取异步需要传递的参数是一件事，异步中的success或者error的回调实现又是一件事儿，回调方法里的更多的操作还是一件事儿，种种事情一行行写下来，还能看？

         3.某些自认为大牛的人实现某些复杂的功能需求，并不感兴趣完善某些校验和细节工作，留给实习生们，然而整洁度并不让人恭维。引起的问题一是其他人修改起来并不方便，二是其让人在为你完善细节的时候，还要重新读一遍两遍代码，我想这样并不会提高工作效率吧。

         4.一个七八个参数的方法，要求传递的参数并没有留下注释？不光是修改的时候很困难，在调用方法的时候，也让人一头雾水。

         5.某个业务基本不需要处理逻辑，能把为了方便，直接在逻辑层操作数据库？不可思议！

         6.在使用aspx时，cs文件一行代码都没有，为了项目整体的漂亮，却要坚持使用aspx?这样真的漂亮？

         7.几十甚至上百个页面，放在相同的文件夹下更好还是稍微分下类好呢！

         8.一个负责增删改查的ashx,能命名为addadmin?  我们ManageAdmin不好吗

 

-------15.07.29新增

         9.个人反对不同的命名空间或者程序集下下使用相同的类名，DAL层和BLL层都有一个User.cs 这样虽然不会有什么问题，但是用UserService和UserDal不更好吗