如何编写优雅的代码：01

[如何练就优雅的谈吐]谈吐，是有声的语言；举止，是无声的语言。前者有声，后者有形，声形兼备，能共同表现出一个人的内在素质、外表气度和交际水平与风格。因此，在社交和商务活动中，不仅要注意仪表，更要注重谈...+阅读

如何编写优雅的代码：01

笔者认为所谓优雅的代码包含三部分涵义：风格好、结构好和性能好的三好代码。所有的编程语言都适用，只不过每种语言的特性和语法不同，实践三好代码的方式和途径也不尽相同。需要注意的是，在有些时候这三种内涵之间是矛盾的。例如，结构好的代码，有时候却会导致性能的下降。遇到这种情况，也不必纠结，在各种利弊之间做好权衡，保证全局利益的最大化才是王道。本文以C#语言为例，总结C#编程实践中，如何做到代码的优雅。

一、简洁的代码风格代码风格顾名思义，即程序员编写代码的书写风格。笔者认为简洁的代码风格，将大大的提高代码的可读性以及降低后续的维护代价。早前，程序员编写代码有一个误区，认为代码是写给计算机读的，只要程序正确，风格不重要。其实并不然，程序员的代码是写给其他人看的，代码风格的简洁统一对于其他人的阅读非常重要。近些年来，代码风格的重要性在业界已达成共识，然而在紧张的开发进度压力下，程序员也往往会忽略代码风格。从系统的整个生命周期来看，这种只顾眼前，不顾长远的做法是不可取的。代码风格主要包含以下部分：1. 命名规范：C#语言中，推荐使用驼峰式命名法。对于公共变量、函数和类等使用大驼峰；对于私有变量、局部变量等使用小驼峰。如：用户名（user name）的大驼峰命名为：UserName，小驼峰命名为：userName。除命名形式外，对于命名的语义也非常重要，尽量用简短、清晰和常见的单词来命名。当你发现命名仍然很长时（通常不超过30个字符），往往是因为该命名承载的逻辑太多所导致，此时应该拆分逻辑。2. 代码注释：关于注释的讨论有很多，笔者不赞成通篇的注释，也不赞成完全不写注释。注释的目的是为了帮助程序员阅读代码，所以一切都以代码的可读性为目的。不能为了注释而注释，本末倒置。笔者认为，在一个命名恰到好处的系统中，不需要存在太多的注释，只需对一些公共接口进行注释。因为通过命名空间、类名和函数名等上下文环境已清晰的表达了大部分程序逻辑的含义。3. 代码布局：利用好换行会使代码的布局比较美观。例如：函数之间应该换行，函数内部实现可用换行作为逻辑片段的结束。对于代码风格的讨论有很多，在此只对一些经常被忽略或者有争议话题做一个简单的说明。更多代码规范的细节，应该系统的阅读相关书籍。同时，在C#编程中，笔者推荐Resharper代码重构工具。Resharper会在编程过程中实时地给出一些代码风格的建议，并且有很好的可视化提示。如果你对Resharper默认的风格不满意，还可以定制你自己或者团队的代码风格。

二、高复用的代码结构如果说代码风格是外功，那么代码结构属于内功，需要一段时间的积累，才能写出代码结构好的程序。前人总结了很多代码规范，开发人员只需遵守，就可以写出易读的代码。而代码结构则不同，很多书籍说明了如何实现好的代码结构，但对解决方案的解释都比较抽象。例如，四人帮的设计模式将实践中经常遇到的很多业务问题，抽象成几类固定的模式，并总结出了如何组织代码结构，实现高复用性。开发人员需要具备一定的编程经验后，再去理解这些抽象的模式，才能够做到在实践中举一反三，学以致用。在面向对象编程中，编写可复用程序有三种方式：继承、多态和泛型。设计模式的实现也是通过这三点特性来实现的。通过继承，子类可以复用父类的数据和行为；通过多态，可以简化编译期的代码量，子类的实际行为可以在运行时决定。例如：子类可以在复用父类的行为的基础上，还可以定义自己的特殊行为，并可以以父类的类型进行传参，运行时会调用子类的具体行为；通过泛型，可以实现类型的参数化，相比多态，泛型是编译期特性，不仅可以保证类型安全，而且在编译期就决定行为，效率比多态的运行时寻址更高。除上面提到的代码逻辑结构以外，代码的物理结构也有讲究。一般而言：单个文件只放一个类；单个代码文件的长度不应该超过255行；一个函数的长度应该不超过屏幕的可视范围；即不用滚动条就能看到完整的函数体；括号的嵌套层级应控制在三层以内，可以通过转置判断逻辑的方式来降低嵌套层级；上面这些建议都是统计的结果，大量的实践证明这些方式是最佳的。仔细思考这些看似没有技术含量的建议，实则背后透露出来软件设计的理念：分离关注点、单一职责的逻辑单元等。从软件质量的角度说，大量的代码逻辑集中在一处，代码的质量往往比较差。还有一个奇怪的现象，代码缺陷总是扎堆出现，在某个代码缺陷的附近往往还存在其他的缺陷。代码结构是一个很大的话题，建议有兴趣的同学看看两本书史蒂夫·迈克康奈尔的《代码大全》和四人帮的《设计模式》。读完之后，相信对于代码结构的理解会更加深入。

三、高效的代码性能前面提到代码风格是外功，代码结构是内功，那么代码的性能就是内功心法。看过武侠小说的人都明白内功心法的重要性，心法不对容易“走火入魔”。在当前计算机硬件速度飞速发展的年代，代码的性能仿佛是一个被遗忘的角落，尤其是在中小型系统中，低效的程序逻辑可以用昂贵的计算机硬件来弥补。但...

如何写出高质量的PHP代码

写给初生牛犊不怕虎的童鞋们，大佬可随意摘看本章基于PHP Laravel前言经常会有人问目录如何设计比较好？代码如何分布好？怎么写一个可维护的项目？“烂”项目我也没少写，以下是参考互联网各大佬的文章总结及个人开发经验而来。 ControllerController顾名思义是控制器，在入门PHP的时候，就知道Controller代表MVC中的C层，MVC本身的概念就代码分离，教你如何如何将业务分开，但面临着业务的不断发展，代码的复杂度也随之提高，功能与功能之间的链接错综复杂，最后你的MVC就变成了下图，所以仅仅依托MVC的设计思想已经无法支撑不断发展的业务。现在我们将Controller的任务和能力重新定义，控制器仅仅控制Http Reqeust的请求，这样就符合了SOLID 单一功能原则。直接将业务代码写在Controller中，会使得代码及其臃肿，不易于维护和扩展username = $request->input('username');$user->password = $request->input('password');$result = $user->save();return $result；}}复制代码这时就应该思考如何分离业务代码，我们引入Service的概念ServiceService本身译为服务将外部方法，公共方法注入到Service将Service注入到控制器像上图这样UserControllerrequest = $request;$this->userService = $userService;}public function register(){//。

validationreturn $this->userService->register ($this->request->all（)）；}}复制代码UserServiceusername = $username;$user->password = $password;$result = $user->save();return $result；} }复制代码到现在为止，我们至少将业务与请求彻底分开了。但还是不如人意，如果把所有的业务及CURD全部写在Service中，那只不过是将Controller的臃肿转移到了Service，那Service就没有什么存在意义了。所以我们需要继续分割Service，将对数据库的R操作独立出来，因为CUD的操作基本是一贯不变的，而R操作根据业务的复杂度则变的多姿多彩。所以独立R操作。这个时候我们引用Repository的概念。Repository我们使用Repository辅助Model，将相关的查询逻辑封装到不同的repository中，方便逻辑代码的维护符合SOLID的单一原则符合SOLID的依赖反转UserControllerrequest = $request;$this->userService = $userService;}public function getUserInfo(){//。

validationreturn $this->userService->getUserInfo ($this->request->all（)）；}}复制代码UserServiceuserRepository = $userRepository; } public function getUserInfo(){ return $this->userRepository->getUserInfo($data)；} }复制代码UserRepositoryfirst();return $result；} }复制代码解决了R的问题，有人就问了，难道因为CUD比较统一简单就可以放在一起了吗？答案是NO，我们引用一个新的名词Action。 Action这是看了Charlie_Jade的文章才学到的独立每个操作文件，例如CreateUser,DeleteUser,UpdateUser符合SOLID的单一原则UserControllerrequest = $request;$this->userService = $userService;} public function register(){ //。 validation return $this->userService->register($this->request->all()); }public function getUserInfo(){return $this->userService->getUserInfo ($this->request->all（)）；}}复制代码UserServiceuserRepository->getUserInfo($data);} public function register(){ $result = (new CreateUser())->execute($this->request->all()); return $result； } }复制代码UserRepositoryfirst();return $result；} }复制代码CreateUsertel = $data['tel'];$models->password = $data['password'];$result = $models->save ();return $result；}}复制代码以上代码逻辑见下图除模版（V）等HTML,JS等，还需要一些其他的规则，或者说是方式去实现一些代码的解耦合，以下不再提供代码案例。

Common译为公共的，常用的，再部分开发中，你可能需要一些公共的方法（并非公共的类，例如邮件发送等，用他并不合适），比如查询用户余额，查询用户是否注册或者是否在线，生成订单号等。使用Common更要简单。他更像一个公共函数库的样子Event不关心执行结果时可以选使用，不过Event的Listen也是提供了队列。 Exception不要将你的所有错误提示都使用Return返回，很多时候你的返回未必是你的返回致谢感谢各位同学看完这篇文章，如果你有新的想法欢迎在评论区讨论。推荐教程：《php教程》。

什么是高质量代码

5个方面很大程序上决定了一份代码的质量高低。来看一下这5方面：

1、编码标准：这个想必都很清楚，每个公司几乎都有一份编码规范，类命名、包命名、代码风格之类的东西都属于其中。

2、代码重复：顾名思义就是重复的代码，如果你的代码中有大量的重复代码，你就要考虑是否将重复的代码提取出来，封装成一个公共的方法或者组件。

3、代码覆盖率：测试代码能运行到的代码比率，你的代码经过了单元测试了吗？是不是每个方法都进行了测试，代码覆盖率是多少？这关系到你的代码的功能性和稳定性。

4、依赖项分析：你的代码依赖关系怎么样？耦合关系怎么样？是否有循环依赖？是否符合高内聚低耦合的原则？通过依赖项分析可以辨别一二。

5、复杂度分析：以前有人写的程序嵌套了10层 if else你信吗？圈复杂度之高，让人难以阅读。通过复杂度分析可以揪出这些代码，要相信越优秀的代码，越容易读懂。