代码大全读后感4

Posted 2023-06-02 zhaoshengfu

要想写好 PDL，首先要用易懂的自然语言，避免拘泥于某种程序语言，其次要在意向
层次上写 PDL，描述设计作什么而不是如何作。
· PDL 到代码流程方法是详细设计的有力工具，而且使得编码非常容易。可以把 PDL 直
接翻译成注释，但要注意保证注释是精确而有用的。
· 应该在工作的每一步中都检查子程序，并鼓励同事们检查。这样，可以在投入的资金
和工作努力最少时便发现错误，从而极大降低改错成本。

作者在书中，反复提及，不要在代码还没有写好或者自己根本就没有弄清代码逻辑的时候，就采用简单的尝试方法让程序编译和运行起来，查看结果是否正确，当结果正确后就认为已经完工了；一个典型的例子便是更改循环时候的比较条件，试试能不能干活。
我想很多人在还是新手的时候都犯过类似的错误吧，至少我犯过类似的错误。在学生时代实验室的项目里面，能够成功的编译是主要的工作目标之一，很多时候根本没有弄清楚代码的逻辑，只求为了编译通过急切的看一下运行的结果。运行结果不正确的时候，再凭空猜想一下哪里出了问题去改一改，运行结果正确后就觉得万事大吉了。
等到工作后才发现，要想让程序健壮可靠，首先必须自己弄懂了程序，即使不能做到明白每一句代码是做什么的，也要明白每个函数是在做什么，是不是正确完成了功能。当然，最好是能够弄明白每一句代码是做什么的，至少明白自己为什么要写这一句代码，为什么是+1而不是-1，即使是因为架构或者历史代码或者进度的原因，不得已需要添加一些不够好的代码或者设计，也请给自己留下注释，而不是简单的根据当前是否能够工作来进行编码工作。要知道，在你开发的机器上没有出现问题，可能是因为你测试的Case不具备一般性，或者是本身的环境特殊等等原因。

代码精进之路读后感

由于最近加班的严重就把看文章写读后感的事情耽搁了，昨天刚忙完，所以恢复每日看文章的习惯，今天读了读范学雷老师的代码精进之路第六篇：代码整理

于我而言，代码的规范是十分必要的，我一直觉得自己可能有点强迫症，代码一定要对齐，所以导致我现在一看别人不规范的代码就感觉很难受，可能有的人会觉得项目有时候特别赶还管什么规范不规范，其实不然，规范的代码会在某种程度上提高你的效率，不规范的代码寻找并修改某个参数花费三分钟，可能规范的代码一分钟就能改好。

根据文章我整理了一下进行代码规范的一些小方法

给代码分块

原则:

1. 保持代码块的单?性，?个代码块只能有?个目标。代码块内所有的内容都是为了?个目标服务的，不能把无关的内容放在同?个代码块里。同?个代码块里语句的相互联系比与相邻代码块里的语句关系更为紧密；

2. 注意代码块的完整性。代码块是?个完整的信息块。?个代码块要表达?个相对完整的意思

3. 代码块数量要适当。代码块过多，会让?觉得路径太长，逻辑复杂，不容易阅读理解。?个基础的代码块最好不要超过25行（通常显示屏小半个页面），否则就会有增加阅读理解的困难。

方法

合理地运用空白

1.同级别代码块靠左对齐

2.同级别代码块空行分割

3.下一级代码块向右缩进

4.同行内代码块空格区隔

5.一行一个行为,?个重要的原则是每一行代码仅仅表示一个行为这样每一行的代码才是一个常规大小的、可以识别的基础信息块

　　基本的换行原则

　　　　基本的换?规范需要考虑以下三点。

　　　　　　1. 每?代码字符数的限制。?般情况下，每?代码不要超出80个字符（ 80个字符是传统终端的宽度，?如vi编译器）。由于屏幕尺?和代码阅读终端的变化，现在的很多规范，开始使?120个字符的限制。所以我们编码的时候，需要留意?下；

　　　　　　2. 如果??不?以容纳?个表达式，就需要换?；
　　　　　　3. ?般的换?原则包括以下五点

　　　　　　　　在逗号后换?。

　　　　　　　　在操作符前换?

　　　　　　　　?级别的换?优先

　　　　　　　　新的换?与上??同级别表达式的开头对?。

　　　　　　　　如果上述规则导致代码混乱或者代码太靠右，使?8个空格作为缩进（两个缩进单位）

 

可以使用各种各样的规范的插件来达到代码规范的目的，例如ESlint等