php怎么post换行，什么样的代码叫好代码？
送大家以下java学习资料
简介： 我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
一句话概括衡量代码质量的唯一有效标准：WTF/min —— Robert C. Martin
Bob大叔对于好代码的理解非常有趣，对我也有很大的启发。我们编写的代码，除了用于机器执行产生我们预期的效果以外，更多的时候是给人读的，这个读代码的可能是后来的维护人员，更多时候是一段时间后的作者本人。
我敢打赌每个人都遇到过这样的情况：过几周或者几个月之后，再看到自己写的代码，感觉一团糟，不禁怀疑人生。
我们自己写的代码，一段时间后自己看尚且如此，更别提拿给别人看了。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。—— Martin Fowler
所以，谈到好代码，首先跳入自己脑子里的一个词就是：整洁。
好的代码一定是整洁的，给阅读的人一种如沐春风，赏心悦目的感觉。
整洁的代码如同优美的散文。—— Grady Booch
好代码的特性很难给好的代码下一个定义，相信很多人跟我一样不会认为整洁的代码就一定是好代码，但好代码一定是整洁的，整洁是好代码的必要条件。整洁的代码一定是高内聚低耦合的，也一定是可读性强、易维护的。
高内聚低耦合
高内聚低耦合几乎是每个程序员员都会挂在嘴边的，但这个词太过于宽泛，太过于正确，所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣：
开闭原则 OCP (The Open-Close Principle)单一职责原则 SRP (Single Responsibility Principle)依赖倒置原则 DIP (Dependence Inversion Principle)最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
里氏替换原则 LSP (Liskov Substitution Principle)接口隔离原则 ISP (Interface Segregation Principle)组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)这些原则想必大家都很熟悉了，是我们编写代码时的指导方针，按照这些原则开发的代码具有高内聚低耦合的特性。换句话说，我们可以用这些原则来衡量代码的优劣。
但这些原则并不是死板的教条，我们也经常会因为其他的权衡（例如可读性、复杂度等）违背或者放弃一些原则。比如子类拥有特性的方法时，我们很可能打破里氏替换原则。再比如，单一职责原则跟接口隔离原则有时候是冲突的，我们通常会舍弃接口隔离原则，保持单一职责。只要打破原则的理由足够充分，也并不见得是坏的代码。
可读性
代码只要具有了高内聚和低耦合就足够好了吗？并不见得，我认为代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该是可读性很强的。可以从以下几个方面考虑整洁代码，提高可读性。
命名
大到项目名、包名、类名，小到方法名、变量名、参数名，甚至是一个临时变量的名称，其命名都是很严肃的事，好的名字需要斟酌。
► 名副其实
好的名称一定是名副其实的，不需要注释解释即可明白其含义的。
/** * 创建后的天数 **/ int d; int daysSinceCreation;
后者比前者的命名要好很多，阅读者一下子就明白了变量的意思。
► 容易区分
我们很容易就会写下非常相近的方法名，仅从名称无法区分两者到底有啥区别（eg. getAccount()与getAccountInfo()），这样在调用时也很难抉择要用哪个，需要去看实现的代码才能确定。
► 可读的
名称一定是可读的，易读的，最好不要用自创的缩写，或者中英文混写。
► 足够短
名称当然不是越长越好，应该在足够表达其含义的情况下越短越好。
格式
良好的代码格式也是提高可读性非常重要的一环，分为垂直格式和水平格式。
► 垂直格式
通常一行只写一个表达式或者子句。一组代码代表一个完整的思路，不同组的代码中间用空行间隔。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
如果去掉了空行，可读性大大降低。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
类静态变量、实体变量应定义在类的顶部。类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。
► 水平格式
要有适当的缩进和空格。
► 团队统一
通常，同一个团队的风格尽量保持一致。集团对于 Java 开发进行了非常详细的规范。（可点击下方阅读原文，了解更多内容）
类与函数
► 类和函数应短小，更短小
类和函数都不应该过长（集团要求函数长度最多不能超过 80 行），过长的函数可读性一定差，往往也包含了大量重复的代码。
► 函数只做一件事（同一层次的事）
同一个函数的每条执行语句应该是统一层次的抽象。例如，我们经常会写一个函数需要给某个 DTO 赋值，然后再调用接口，接着返回结果。那么这个函数应该包含三步：DTO 赋值，调用接口，处理结果。如果函数中还包含了 DTO 赋值的具体操作，那么说明此函数的执行语句并不是在同一层次的抽象。
► 参数越少越好
参数越多的函数，调用时越麻烦。尽量保持参数数量足够少，最好是没有。
注释
► 别给糟糕的代码加注释，重构他
注释不能美化糟糕的代码。当企图使用注释前，先考虑是否可以通过调整结构，命名等操作，消除写注释的必要，往往这样做之后注释就多余了。
► 好的注释提供信息、表达意图、阐释、警告
我们经常遇到这样的情况：注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了，而注释并没有跟进变化。所以，注释最好提供一些代码没有的额外信息，展示自己的设计意图，而不是写具体如何实现。
► 删除掉注释的代码
git等版本控制已经帮我们记录了代码的变更历史，没必要继续留着过时的代码，注释的代码也会对阅读等造成干扰。
错误处理
► 错误处理很重要，但他不能搞乱代码逻辑
错误处理应该集中在同一层处理，并且错误处理的函数最好不包含其他的业务逻辑代码，只需要处理错误信息即可。
► 抛出异常时提供足够多的环境和说明，方便排查问题
异常抛出时最好将执行的类名，关键数据，环境信息等均抛出，此时自定义的异常类就派上用场了，通过统一的一层处理异常，可以方便快速地定位到问题。
► 特例模型可消除异常控制或者 null 判断
大多数的异常都是来源于NPE，有时候这个可以通过 Null Object 来消除掉。
► 尽量不要返回 null ，不要传 null 参数
不返回 null 和不传 null 也是为了尽量降低 NPE 的可能性。
如何判断不是好的代码讨论了好代码的必要条件，我们再来看看好代码的否定条件：什么不是好的代码。Kent Beck 使用味道来形容重构的时机，我认为当代码有坏味道的时候，也代表了其并不是好的代码。
代码的坏味道
► 重复
重复可能是软件中一切邪恶的根源。—— Robert C.Martin
Martin Fowler 也认为坏味道中首当其冲的就是重复代码。
很多时候，当我们消除了重复代码之后，发现代码就已经比原来整洁多了。
► 函数过长、类过大、参数过长
过长的函数解释能力、共享能力、选择能力都较差，也不易维护。
过大的类代表了类做了很多事情，也常常有过多的重复代码。
参数过长，不易理解，调用时也容易出错。
► 发散式变化、霰弹式修改、依恋情结
如果一个类不是单一职责的，则不同的变化可能都需要修改这个类，说明存在发散式变化，应考虑将不同的变化分离开。
如果某个变化需要修改多个类的方法，则说明存在霰弹式修改，应考虑将这些需要修改的方法放入同一个类。
如果函数对于某个类的兴趣高于了自己所处的类，说明存在依恋情结，应考虑将函数转移到他应有的类中。
► 数据泥团
有时候会发现三四个相同的字段，在多个类和函数中均出现，这时候说明有必要给这一组字段建立一个类，将其封装起来。
► 过多的 if...else 或者使用 switch
过多的 if...else 或者 switch ，都应该考虑用多态来替换掉。甚至有些人认为除个别情况外，代码中就不应该存在 if...else 。
总结本文首先一句话概括了我认为的好代码的必要条件：整洁，接着具体分析了整洁代码的特点，又分析了好代码的否定条件：什么样的代码不是好的代码。仅是本人的一些见解，希望对各位以后的编程有些许的帮助。
我认为仅仅编写出可运行的代码是远远不够的，还要时刻注意代码的整洁度，留下一些漂亮的代码，希望写的代码都能保留并运行 102 年！
后续增加一些实际的例子来说明好的和坏的代码；分享下如何编写整洁代码——自己认为有用的一些编程技巧。
学习web前端开发？
黑马程序员web前端中级程序员学习路线图，含配套视频，前端工具，源码等。
黑马程序员学习路线图及能掌握的能力（总，以下会分阶段，加上配套学习视频，小伙伴可继续往下看！）
第一阶段：HTML5+css
配套学习视频：
前端小白零基础入门HTML5+CSS3
第二阶段：移动web网页开发
配套学习视频：
2018移动web进阶教程
第三阶段：JavaScript网页编程
配套学习视频：
前端与移动开发基础入门到精通
javaScript零基础通关必备教程
第四阶段：Node.js与Ajax
配套学习视频：
Nodejs教程精讲
ajax从入门到精通
第五阶段：vue.js项目实战
配套学习视频：
4小时+5个拣选案例让你快速入门Vue.js
2018年Vue.js深入浅出教程
第六阶段：微信小程序
配套学习视频：
一天教你打造企业级微信小程序
微信小程序-个人语音接口功能
分分钟快速入门小程序开发
零基础玩转微信小程序
2小时轻松实现人脸识别的小程序
第七阶段：React.js项目实战
配套学习视频：
Reactjs入门教程
ReactJs精品教程
第八阶段：框架阶段与原理
第九阶段：移动APP开发
第十阶段：node.js进阶
第十一阶段：可视化游戏
第十二段阶段：架构与运维
还有前端免费工具下载
另外，关注加转发，然后私聊我发送：前端，就能获得上面这些资源咯。
怎么发送HTTPget请求？
客户端向WEB服务端发送请求报文，HTTP协议的请求报文格式为：请求消息=请求行（实体头信息）CRLF[实体内容]请求行=方法URLHTTP版本号CRLF方法=GET|HEAD|POST|扩展方法URL=协议名称＋宿主名＋目录与文件名其中"CRLF"表示回车换行。"请求行"中的"方法"描述了对指定资源执行的动作，常用的方法"GET"、"HEAD"和"POST"等3种·数据库查询类型对象，获取该查询的结果。
HEAD要求服务器查找对象的元信息。POST从客户端向WEB服务器发送数据。"实体头信息"中记载了报文的属性，利用这些信息可以实现客户端与WEB服务器之间的请求或应答，它包括报文的数据类型、压缩方法、语言、长度、压缩方法、最后一次修改时间、数据有效期等信息。
如何优化网站服务器提升网站访问速度？
您好，我是仙人掌热点。网站运营的任何时候，网站访问速度都是至关重要的部分，它是网站友好体验中最基本的一项，如果访问体验都令人不满意，那么后期所做的营销推广模式都有可能徒劳无功，因为网络中客户的选择成本很低，加上普遍客户的耐心都不高，页面访问超过6秒客户就会选择离开，这对于一些流量本来就不高的企业网站来说无疑是雪上加霜。网站访问速度既然如此重要，今天笔者也要跟大家分享几个关于提升速度体验的方法，虽然网上有很多类似的文章和观点，但是大多数都是网站内部去解析，今天笔者要从服务器方面聊聊如何优化网站服务器提升网站访问速度。
大多数网站运营优化人员都知道通过页面优化来提升访问速度，当你已经完成了优化操作之后，发现没有什么大的改善，此时你就应该去思考是不是其它因素导致访问速度缓慢。比如：长期使用的服务器性能下降所致，为了保障业务不受影响，你或许应该对正在使用的服务器进行升级和优化了。
一、升级正在使用中的服务器
进行服务器升级工作之前，要考虑多方面的问题，是升级已有的服务器还是购置新的服务器设备须根据实际情况抉择。首先来说升级现有的服务器设备，一般来说网站运营到后期随着业务不断增加，多平台应用的开发对于服务器性能的要求也逐步提升，长而久之服务器遇到性能瓶颈也是情理之中的事情，对于这种情况，我们可以通过升级服务器(例如增加硬件设备或网络带宽)等相关配置来满足不断扩大的业务需求，那么服务器性能瓶颈问题就可以得到解决。再来说说购置新的服务器设备，也许有人会问为什么要重新购置呢，升级已有的服务器不可以吗?这里笔者也当然想替大家节省一笔开支，但是根本问题在于大多数企业选购服务器时并不合理，加上网站建设之初为节约成本而选择了扩展性较差的服务器，导致即便是我们对现有的服务器进行升级，其性能提升的强度依然不够。此时，就需要重新购置服务器配合了，对于服务器的购置也有很多技巧，这里简单的做个推荐，如果用户群体是国内的建议选择国内知名的服务器供应商，若客户群体是遍布全球，大家可以选择香港服务器或美国服务器，除此之外，更重要的是要根据自身行业的特性做出合理的选择。
二、优化正在使用的服务器
不管是完成升级后的服务器，还是新购置的服务器，我们都要对其进行优化，从而提升服务器的性能以及利用率。下面从四个方面跟大家谈谈如何优化服务器：
要点一：尽可能的减少HTTP请求数
从客户访问网站页面到整个页面内容完全展现出来，这其中要花费较多的时间来下载各种Scripts、CSS样式表、Flash以及图片，而每一类下载都相当于一次HTTP请求，这样的请求越多网站被完全加载出来所花的时间会越长，意味着客户端的访问会很慢，那么此时就需要尽可能的减少HTTP请求数，通常我们可以直接把css和js写入到页面中，避免了外部的调用;或者我们可以把CSS文件和JS文件分来，在后台再进行合并，这样客户端浏览器相当于一次请求。总而言之，减少HTTP请求数我们可以通过减少外部各类文件的数量调用次数来达到其目的。
要点二：降低DNS查询时间
众所周知网络服务器端的域名和IP地址是相互对应的，当客户端发出请求时，计算机还需要通过域名和IP地址的相互转换来判断，而这个转换工作便是域名解析DNS，通常DNS的查询需要10~20毫秒时间，客户端浏览器也只会等待DNS查询结束之后才会加载此域名下的内容。因此，我们要加快页面的访问速度，就可以从降低DNS查询时间方面去做改善。
要点三：启用服务器Gzip压缩功能
对于大中型网站来说，页面的内容多且比较多样化，单个页面的大小可能是几百K以上了，客户端访问的时候下载会比较慢，此时我们可以采用服务器Gzip页面压缩功能，可以将一个大小为100K的页面文件压缩成25K以下，这样就可以减少网络传输的数量从而提高客户端访问速度。一般服务器都是可以使用Gzip压缩功能的，并且能够针对JS文件、CSS文件和Html进行压缩，多方面去进行优化网站访问速度。
要点四：推荐大中型网站使用CDN加速工具
CDN加速是目前大型网站普遍使用的页面加速方式，它对于网站优化几乎没有影响的，基本原理是将网站镜像备份到很多服务器节点上，使服务器节点周围的用户访问速度更快，从而提升客户端高速访问网站的体验;但是并不是所有的网站都适合使用CDN加速，一般对于小规模站点个人站的话，就不需要使用CDN加速，毕竟从长期来看这可是一笔不小的开支;建议图片站以及多媒体站点可使用CDN加速。
至此，以上为大家讲到了可以通过优化和升级服务器两个方面提升网站访问速度，如果你的网站目前的访问体验不佳，可以尝试进行以上操作，相信能够帮助大家改善此类问题。