品牌科技公司排名,seo是什么缩写,群晖docker wordpress设置,软装设计师主要做什么放寒假回家有些颓废#xff0c;就是不想看书。但是已经大三了#xff0c;春节过后就要找实习了。哎#xff0c;快乐的大学生活终于要过去了。 先从简单的书看起吧#xff01;在图书馆借了本《The Art of Readable Code》#xff0c;就是教你咋写好优雅的代码的#xff0c… 放寒假回家有些颓废就是不想看书。但是已经大三了春节过后就要找实习了。哎快乐的大学生活终于要过去了。 先从简单的书看起吧在图书馆借了本《The Art of Readable Code》就是教你咋写好优雅的代码的感觉还不错。整理一下学习心得。 书中总共分了四大部分总共15个章节。我也打算边看边记下笔记用四篇文章来记录一下学习心得。如下 第一部分初级的一些优化第二部分简化循环和逻辑第三部分重新组织你的代码第四部分一些选定的主题 前戏 看原版书而不是翻译版的有个好处就是英文的表达很精确。 整本书始终就围绕了一个主题来写的 Code Should Be Easy to Understand 什么样的代码才算好呢有一个判断的标准缩短别人能看明白你代码的时间。这时候估计又有同学会问了我写的就是给自己看的或者团队里就我一个人设计到实现到测试全是我一个人要写给别人明白干什么好吧老实说我之前也是这样想的。“别人”不一定是其他人也可能是三个月后的你自己。 代码越短越好吗代码当然应该清晰易懂这谁都知道但是往往大牛们都不这么想。一些大牛认为代码越短越好在leetcode上经常可以看见这样的话Python One line Solution Beats 100% .确实只用了一行但是往往读懂它却要用半天:(还有三元运算符? :到底该不该用简单的情况下是可以使用的比如return max -1 ? 0 : max可以不必用if else来代替了但是有些情况下如果为了把代码写到一行中而在三元运算符中添加复杂的逻辑以至于别人为了看懂你这行代码要去查一查其中运算符的优先级那就不是好代码了。 第一部分 初级的一些优化 比如取个好点的名字写上必要的注释格式化代码等等它们影响了代码库中的每一行代码虽然这些改变不破坏整体的逻辑但是却能使代码更容易读懂。 A. 在名字中包含信息 Man-Eater plant食人花这个名字让人一看就懂。 使用特定的单词。比如def GetPage(url){...}这个就不够具体get本身有很多种意思你到底是要干啥替换成具体的单词FetchPage() DownLoadPage()都是可以的让人一看就明白了。 避免使用通用的名字。像tmpretval我以前就喜欢这样写为什么还不是嫌取个名字太麻烦了自己英文水平又不行用拼音吧也太low了。这种变量名字不能传达任何信息尽量不要用。除非在某些情况下比如交换两个变量的值这时候需要一个中间变量tmp这个没问题大家都也都能看明白。多重循环的时候也避免使用i,j,k这样没有任何信息的变量名可以使用club_i, members_i, users_i这样的或者缩写ci,mi,ui防止搞混淆。 使用更详细的名字。尽量详细的将信息表达在名字中ServerCanStart()相对于CanListenOnPort来说就很含糊。 添加额外的关键信息。比如时间单位开始和结束时间start_ms end_ms后面就可以加上单位来防止在接下来遇到其他不同单位时间的变量中出错。 为大范围的变量起个长名字小范围的变量可以取个短一点的名字。如果变量只存在于一个很小的范围中比如只有几行那么mapString, int m这样就没毛病。但如果map存在一个很大的范围里面,m就不便于阅读了。 使用大写下划线等去表达特定的信息。比如在C中类中的变量名以下划线结尾比如offset_这就说明它是一个类的成员变量而不是局部变量。B. 名字不能模棱两可 英语中有很多模棱两可的单词比如filterresults Database.all_objects.filter(years 2011)。那问题来了results中到底是包含的 2012的还是not 2012表达范围如果要表示高低的范围那么加上max_和min_是很好的选择如果要表示两个边界都包含在内那么应该用first和last如果要左闭右开那么应该选择begin和end。当命名一个布尔型变量的时候要多使用is、has等使它表达的意思更明确。尽量不要使用负面的词汇比如不应该用boolean disable_ssl false而是用boolean use_ssl true。还有命名的时候要注意大家默认的习惯比如会认为带有get的方法是一个代价很小的轻量级的方法但你却用getMean()这个方法去计算了一个时间复杂度为On*n的平均值这时候就应该写成computeMean而不是getMean。 C.在代码中审美 这让我想起了云栖社区之前搞的一个活动第83行代码就是大家秀一秀自己写的代码。反正我看一些大牛的代码就感觉哇塞大牛就是大牛写代码都感觉像是在创作虽然看不懂写的啥吧但是单单从审美上就让你震撼了。那么如何使自己代码看起来更优雅呢 如果有很多个代码块做的事相似那么也给它们相同的风格包括注释上下对齐保持注释结构一致保持代码的对齐等等。给多个变量赋值选择有意义的排列顺序并且始终保持这种排序。将许多个声明语句分成块在相应的块上注释好大概的功能。给代码分段每段前写上注释段与段之间一个空格隔开。还有就是大括弧的问题class Logger{
...
}
or
class Logger
{
...
} 这两种写法都没问题但要选择一种并且始终保持风格一致不能混用。 D.学会去写注释 什么是好的注释有一个判断标准让读代码的人尽可能多地知道和写代码的人一样的信息。 当然注释不是什么都要地方都需要写的。一些能直接从变量名读出来的信息那就不要画蛇添足了。也不要为了注释而注释。可能会觉得不写注释不妥那就干脆写一个注释吧但是注释中其实没有包含什么有用信息。也不要为了修正代码中糟糕的变量名来写注释这时候应该直接去修改代码而不是在注释中写明。注释也斜体文本可能就是直接的记录了你当时写代码的想法这也ok。写出来或许对读代码的人有帮助。为代码中的一些缺点注释比如标记意思TODO:我还没抽空去解决的事FIXME:这里的代码有点问题HACK:对于这个问题的解决方案有待改善XXX:危险重灾区。。给自己定义的常量注释给代码的关键部分主要功能写注释。写总结性的注释让读者不要纠结于一些小细节之中。可以宏观的角度看这些代码而不是去计较每一行。写注释反正对于我是蛮难的一方面写的代码不多感觉自己注释可能会很幼稚一方面也觉得写好一个注释要花时间。看了这一章以后写项目代码的时候无论如何也要适当的把注释加上。 E.使自己的注释精确、紧凑 感觉这个没什么好说的谁都不喜欢听别人唠叨那就从我们写注释开始吧 避免使用它这个那个这样的代词防止产生歧义润色一些那些“唠叨的话”阐释你的方法的输入、输出时用一些例子陈述你代码中和宏观的意图而不是纠结于细节之中。用一些能表达更多信息的词可能一个词就能说明你原来用一句话想说明的意思。ok刚看完了这本书的第一部分万事开头难。寒假生活开始喽剩下的我会陆续更新哒~希望对你有所帮助︶↗
