函数编写的几大规则 很难一开始就遵循这些规则,但是可以先想什么就写什么,然后再打磨它. 1.短小 函数的第一规则是短小,第二规则是还要更短小. if.else.while语句等,其中的代码块应该只有一行. 2.只做一件事 函数应该做一件事,做好这件事,只做这一件事. 编写函数毕竟是为了把大一些的概念拆分成另一抽象层上的一系列步骤. 3.自顶向下读代码:向下规则 我们想要让代码拥有自顶向下的阅读顺序.让每个函数后面都跟着位于下一抽象层级的函数,这样在查看函数列表时,就能循抽象层级向下阅读. 4.函

最近在看代码整洁之道(Clean code)这本书,其实看的有点痛苦,因为越看就会越想自己写的代码是什么鬼?一些不知所云的命名,不整洁的代码格式,本想诠释代码的意思却添加了一段段废话,还有那些被强制加上去的署名和某年某月的修改信息. 此时的我只想痛改前非,但是我知道看书的时候觉得自己懂了,实际写起来又会很糟糕.我以大牛为榜样,看看自己离这个目标还差的很远我又很烦躁.也许我不该烦,应该从现在开始注意自己写代码的风格. 首先说下命名: 尽管给函数,变量,类等命名没有充斥着a,b,c但是也命名过isD

作者介绍 原文作者: Robert C. Martin, Object Mentor公司总裁,面向对象设计.模式.UML.敏捷方法学和极限编程领域的资深顾问,是<敏捷软件开发:原则.模式.与实践>的作者.翻译作者:韩磊,互联网产品与运营专家,技术书籍著译者.译著有<梦断代码>和<C#编程风格>等.(竟然不是程序员~~~) 内容概要 本书后几章主要讲了java相关的类.系统.和并发的设计介绍,较粗略,与简洁之道不是特别融合,故而省略,想要详细了解的建议去看更优质的详细讲解

这个暑假出来实习,第一次体会到在一个团队中开发的体验,与网上的网站看到的大为不同,以前看网上说什么程序员写了屎山代码,写了一堆模糊的注释或者说垃圾代码不写注释. 但在我的实习体验中,代码虽然看起来很多,但大多都一目了然,第一天去的时候我问了我的实习导师,为什么公司代码没有注释?他说公司的编码全部都是按照代码整洁之道,只写整洁易懂的代码,让人一目了然.我在看了几天代码之后就很快就明白了部分代码含义,并且完成了几项任务.简洁的代码确实会让人如沐春风,公司的三本必读书籍之一就是<Clean Code>

本周我阅读了<Clean Code>. “神在细节中!”,建筑家范德罗如是说.他当然专注于基于宏伟构架之上的永恒建筑形式,他也同样为自己设计的建筑挑选门把手.同样软件开发也是这样,小处见大.在宏伟的建筑作品中,我们也要关注细节的回响.重点便是整理,从而达成Clean.一个很好的例子是对于变量命名,认真对待每个变量名.书中作者说,我们就像一群代码猴子,无视混乱无序,失去代码的真谛.整洁的代码正是迈向编程之美的基础,重要性毋庸置疑. 作者断言,我们永远需要代码.我们可以创造各种工具,但是永远无法抛

@ 目录 第 1 章 Clean Code 整洁代码(3星) ?为什么要整洁的代码 ?什么叫做整洁代码 第 2 章 Meaningful Names 有意义的命名(3星) 第 3 章 Functions 函数(3星) 第 4 章 Comments 注释(2星) 第 5 章 Formatting 格式 (1星) 第 6 章 Objects and Data Structures 对象和数据结构(4星) 第 7 章 Error Handling 错误处理(4星) 第 9 章 Unit Tests 单

前两天参加了公司组织的一个培训,主题是“如何写出好的代码” ,刚看到这个主题,第一反应是又不知道是哪个培训机构来忽悠钱的!老大安排了,就去听听呗. 说实在的,课程内容没有什么新鲜的东西,就是讲讲如何发现代码的坏味道,如何重构函数,如何修改遗留系统的代码.这些东西从本科到研究生到实习到正式工作,也不知道看过多少听过多少了,话说本科的课程设计也和代码重构相关,私底下重构和设计模式方面的书也没少看,感觉应该没啥好培训的,不过两天的课程听完,打心眼里觉得来对了,意犹未尽! 课程结束了,感觉需要把这两天课

小课堂Week12 Clean Code Part1 今天的主题是函数,让我们看一个函数,找一找其中的"不整洁". 我们也根据这段代码,讨论下对于整洁代码的两个重要原则. public static String testableHtml(PageData pageData, boolean includeSuiteSetup) throws Exception { WikiPage wikiPage = pageData.getWikiPage(); StringBuffer buf

clean code,顾名思义就是整洁的代码,或者说清晰.漂亮的代码,相信大多数工程师都希望自己能写出这样的代码. 也许这是个千人千面的话题,每个工程师都有自己的理解.比如我,从一个天天被骂代码写得烂的人,逐渐学习成长,到现在也能写的出“人模人样”的代码来了.这期间算是积累了一点经验心得,想和大家分享,抛砖引玉. 本文主要针对面向对象编程的clean code来阐述,面向过程代码的思路会比较不同,不在本文的讨论范畴. 代码整洁的大前提 代码大部分时候是用来维护的,而不是用来实现功能的 这个原则适

<Clean Code>一书从翻开至今,已经差不多两个月的时间了,尽管刨去其中的假期,算下来实在是读得有点慢.阅读期间,断断续续的做了不少笔记.之前,每每在读完了一本技术书籍之后,其中的诸多细节会很快的淡忘,最终留下的往往是在阅读时候与自己之前的印象产生极大共鸣的部分,或者在之后实践当中碰巧运用到的一些知识点.所以,根据已往的经验来说,对于一本技术书籍的学习,个人更愿意依照如下两个基本原则来学习: 撷取个人当前认同最深的少数几个知识点,反复进行实践,并在理解之后再扩张到其他的知识点 择期再次阅

Clean Code of JavaScript 代码简洁之道 JavaScript 版 https://github.com/ryanmcdermott/clean-code-javascript 目录 介绍 变量 函数 对象和数据结构 类 测试 并发 错误处理 格式化 注释 介绍 Robert C. Martin <代码整洁之道>总结了适用于 JavaScript 的软件工程原则 <Clean Code JavaScript>. 根据<代码整洁之道>作者多年经验整理

最近花了一些时间看了这本书,书名是 <Writing Clean Code ── Microsoft Techniques for Developing Bug-free C Programs> 这里主要总结了一些里面的编程思想. 为空语句加上NULL 当需要使用空语句的时候,最好写上NULL, 比如: if (music_on()) NULL; else turn_it_on(); 参数类型相同的问题 如果函数中两个参数的类型相同,如果用户调用这个函数时错误替换了参数的顺序,就会出现问题.

Clean Code Part2 对象与数据结构 首先让我们进行一个严肃的思考,对象与数据结构的区别在哪里? 如下两段代码分别用数据结构和对象的方法来描述了一个Point. public class Point { private double x; public double y; } public interface Point { double getX(); double getY(); void setCartesian(double x,double y); double getR(

第一个:FindWindow根据窗口类名或窗口标题名来获得窗口的句柄,该函数返回窗口的句柄 函数的定义:HWND WINAPI FindWindow(LPCSTR lpClassName ,LPCSTR lpWindowName); 第一个参数填窗口的类名,第二个填窗口的标题名,其实是不需要同时填两个参数的,也就是说,你只要知道窗口的类名或窗口的标题就可以了,没有的那个就用NULL代替. 比如现在有一个窗口名为"无标题.txt - 记事本"的记事本程序.那么我就可以用上面的函数获得这个

译者按: 简洁的代码可以避免写出过多的BUG. 原文: JavaScript Clean Code - Best Practices 译者: Fundebug 本文采用意译,版权归原作者所有 引文 作为一个开发者,如果你关心代码质量,除了需要认真测试代码能否正确执行以外,还要注重代码的整洁(clean code).一个专业的开发者会从将来自己或则他人方便维护的角度考虑如何写代码,而不仅仅是机器能够读懂.你写的任何代码有很大几率会被再次重构,希望未来重构代码的那个人不会觉得这是一场灾难. 代码的简

Clean code 看<clean code>一书,学习高手写出的代码,简单高效的代 1.目标 Bjarne Stroustrup:优雅且高效:直截了当:减少依赖:只做好一件事 Grady booch:简单直接 Dave thomas:可读,可维护,单元测试 Ron Jeffries:不要重复.单一职责,表达力(Expressiveness) 代码的书写,一定程度上体现了编程的思想,编码者的功力,标识出红色的部分我觉得体现了函数式编程,面向对象的思想,需要细细体会 2 命名 2.1 前期统一

你是否真正的会命名 前言 这是我第二次看这本书了(Clean Code)的时候,第一次看的时候是,看到某世界五百强在他们的代码中我竟然看不到一句注释,现在我还记得当时的情景,当我Download 下第一份代码的时候,我想在代码中了解一下公司代码编写习惯以及少量的业务,在我以前的认知中,代码中加上很多注释这些注释有助于我了解业务,但是在这份代码中我竟然看不到一行注释,当时我的反应是,一定会有文档的存在,我就向项目的负责人求助了,谁知他回了一句你多理解一下命名就行了,(其实我的英语非常差,后来慢慢习

军规:让营地比你来时更干净. 整洁代码 Leblanc : Later equals never. (勒布朗法则:稍后等于永不) 对代码的每次修改都影响到其他两三处代码. 修改无小事. 如同医生不能遵从病人的意愿,程序员遵从不了解混乱风险的经理的意愿,也是不专业的做法. 赶上期限的唯一方法,做的快的唯一方法,就是始终尽可能保持代码整洁. 破窗理论:环境中的不良现象如果被放任存在,会诱使人们仿效,甚至变本加厉.==一幢有少许破窗的建筑为例,如果那些窗不被修理好,可能将会有破坏者破坏更多的窗户.最终

最近开始研读 Robert C.Martin 的 “Clean Code”,为了巩固学习,会把每一章的笔记整理到博客中.而这篇博文作为一个索引和总结,会陆续加入各章的笔记链接,以及全部读完后的心得体会. 这里也引用一下第一章中提到的 LeBlanc's law: Later equals never. 看到这句话时,脑海中想到的中文翻译居然是 “有些事现在不做,一辈子都不会做了”.所以,为了不留遗憾,开始 "clean code" 吧. 以下为各章读书笔记目录链接: Chapter 2

Error handling is important, but if it obscures logic, it's wrong. Use Exceptions Rather Than Return Codes Separate the normal operations with error handlings. e.g. Bad code: public class DeviceController { ... public void sendShutDown() { DeviceHand

“Don’t comment bad code—rewrite it.”——Brian W.Kernighan and P.J.Plaugher The proper use of comments is to compensate for our failure to express ourself in code. Truth can only be found in one place: the code. Comments Do Not Make Up for Bad Code Rath