Atitit. 提升存储过程与编程语言的可读性解决方案v3 qc25.docx

Atitit. 提升存储过程与编程语言的可读性解决方案v3 qc25.docx

1. 大原则：分解+命名1

1.1. 命名规范1

1.2. 分层、DI和AOP是继OO1

1.3. 运算符可读性一般要比函数好1

1.4. 函数式样 流程控制全部函数化2

1.5. 递归代替循环2

1.6. 中缀表达式  取代 前后缀表达式2

1.7. 有时候异常处理也会提升可读性2

1.8. dsl2

2. Refactor2

2.1. 方法链2

2.2. 其他2

2.3. PIE 原则：意图清楚而且表达明确地编程；3

2.4. 恰到好处的注释3

2.5. 简单就是美，避免简单的功能写出复杂的代码；4

2.6. 坚持操作方法的原子性，而后使用组合模式实现业务逻辑；4

2.7. 参考4

1. 大原则：分解+命名

1.1. 命名规范

参考知名api  参考知名sdk 游戏cocos2d、等..

Sql style api

这样可以大大减少资料文档的编撰。。互联网上已经有了

命名可以添加版本时间后缀，方便脚本语言重构

1.2. 分层、DI和AOP是继OO

1.3. 运算符可读性一般要比函数好

函数式语言同时具有良好的简单性和正交性

赋值

Assign(“var1”,22);

加法

Add(“var1”,”var2”);

1.4. 函数式样 流程控制全部函数化

特殊字(如while、class和for)

1.5. 递归代替循环

1.6. 中缀表达式  取代 前后缀表达式

1.7. 有时候异常处理也会提升可读性

异常处理

1.8. dsl

2. Refactor

2.1. 方法链

2.2. 其他

以下是摘选的可供参考的策略：

· 编码风格一致

· 代码清晰表达意图

· 写别人看得懂的单词，如果选用英语，那么避免日语、法语和汉语拼音等，尽量使用语义化的命名组合；

2.3. PIE 原则：意图清楚而且表达明确地编程；

· 能够让人快速看懂（最低限度的要求是自己一个月后能快速读懂）；

2.4. 恰到好处的注释

· 不能太多或太少，注释的形式根据代码具体的情况有不同；

· 避免用注释包裹代码；

· 尽量留下简明扼要的注释；

· 评估取舍（不要编写大段的代码）

· 避免写一些现在不需要、将来也不太可能需要的功能：

· 不完美主义：不多写代码（如会话存储拆分）；

· 避免做没有太大价值的优化工作；

· 区分任务的轻重缓急：

· 头疼医头也医脚：先容忍失败，再解决问题（如节点关闭逻辑）；

· 不头疼不医头：量化分析（如参数调整回滚等）；

· 综合考虑一下性能、便利性、生产力、成本和上市时间……

2.5. 简单就是美，避免简单的功能写出复杂的代码；

· 保持简单的代码远比写出复杂代码要难得多，但这是值得的；

· 不编写讨巧的代码；

· 避免无谓的条件嵌套和过度封装；

· 第一眼看上去就能知道其用处的代码，才是简单而美的代码

2.6. 坚持操作方法的原子性，而后使用组合模式实现业务逻辑；

· 避免大段代码，要写高内聚、低耦合的代码；

2.7. 使用德摩根定理 “分别取反，转换与/或”（

如果你学过“电路”或者“逻辑”课，你应该还记得德摩根定理。对于一个布尔表达式，有两种等价的写法：

1.         not (a or b or c) <=> (not a) and (not b) and (not c)

2.         not (a and b and c) <=> (not a) or (not b) or (not c)

如果你记不住这两条定理，一个简单的小结是“分别取反，转换与/或”（反向操作是“提出取反因子”）。

有时，你可以使用这些法则来让布尔表达式更具可读性。例如，如果你的代码是这样的：

if (!(file_exists && !is_rotected)) Error("Sorry, could not read file.");

那么可以把它改写成：

if (!file_exists || is_protected) Error("Sorry, could not read file.");

2.8. 代码难以跟踪

阅读代码时，通常需要频繁的从一个函数或类跳转到另一个函数或类。 掌握你使用的集成开发环境(IDE)，可以节约很多阅读时间。 通过使用集成开发环境(例如Visual Studio)的“跳转至声明”，“查找使用”，“导航至”，“检查”等特性，你可以将整个代码看作是一幅连通图。

在Notepad中编写代码是不错的选择，但是如果你想有效的阅读代码，必须掌握一个集成开发环境。

那么，究竟什么是连通图呢？

连通图是在拓扑空间中连接的图，即图中任意两点之间都有一条通路。(来源)

换句话来说，在“连通”代码中，你可以方便的从一个方法中跟踪到另一个方法中，并在你头脑中建立这段代码的功能框架。

如果代码中某一部分链接被破坏（在这种情况下，集成开发环境不能帮助你实现函数间的跳转)，通常你必须花一些时间自己查找链接。代码中被破坏的链部分越多，越难以跟踪，代码也就越难以阅读。

那么，为什么代码图会被断开？原因是多方面的，下面将列出一些常见情况：

2.8.1.1. 1. 使用字符串引用方法和属性

一些框架就喜欢这样做，他们将”回调”作为字符串传递并在需要时使用反射。 此时你需要使用CMD+F查找。

最可恶的是动态语言中的动态字符串…… 对这个问题，向JavaScript或AS3致敬!

2.8.1.2. 2. 代码被分割成互不相连的部分

例如，你的代码一半使用C#编写，另一半是在可视化节点编辑器生成。 在这两者之间跳转非常不易。

依赖注入框架和其他XML配置工具也是。虽然没有明确说明，但编写XML配置文件也属于编程。 这就是所谓的的声明式编程(更不用说那些构建基于XML命令式语言的疯狂的人)。

2.8.1.3. 3. 巨大的图节点

20个链接跳转到这个包含1000行代码的函数？。。哎哟。 你不需要包含这种节点的图。

2.8.1.4. 4. 一切都过于抽象

通过跳转至声明，你可到达一个接口或者一个抽象类，必须弄清楚有哪些实现。 依赖注入，抽象工厂和其他所有反对依赖的方法使得这一切变得更糟。 代码图中节点间的联系过于抽象。

这样说来，我讨厌依赖注入（DI）和扩展标识语言（XML）。但DI是一个很棒的工具，它可以让你避免书写面条式代码并让程序的架构更加模块化，更具可测试性。但像其他好的事物一样，过度依赖必然产生负面效果。

我曾在审查一个应用程序时感到完全气馁，因为我意识到自己弄不明白程序从何处开始。。。例如它的入口点在哪。 这一切都是在程序开始时从XML配置工具自动生成。

但我确实讨厌XML配置工具。

2.9. 参考

Atitit.提升语言可读性原理与实践

Atitit usrQBF2312 命名空间pkg 以及 api命名 spec规范

如何提高代码可读性、可维护性.html

提高代码可读性的 10 个注释技巧 - 文章 - 伯乐在线.html

编写可读性代码的艺术 - tiewen的专栏 - 博客频道 - CSDN.NET.html

程序员，请优先提高代码的可读性 - 文章 - 伯乐在线.html

作者:: 绰号:老哇的爪子claw of Eagle 偶像破坏者Iconoclast image-smasher

捕鸟王"Bird Catcher 王中之王King of Kings 虔诚者Pious 宗教信仰捍卫者 Defender Of the Faith. 卡拉卡拉红斗篷 Caracalla red cloak

简称：： Emir Attilax Akbar 埃米尔 阿提拉克斯 阿克巴

全名：：Emir Attilax Akbar bin Mahmud bin  attila bin Solomon bin adam Al Rapanui 埃米尔 阿提拉克斯 阿克巴 本 马哈茂德 本 阿提拉 本 所罗门 本亚当  阿尔 拉帕努伊

常用名：艾提拉（艾龙），  EMAIL:1466519819@qq.com

头衔：uke总部o2o负责人，全球网格化项目创始人，

uke宗教与文化融合事务部部长， uke宗教改革委员会副主席

，Uke部落首席大酋长，

uke制度与重大会议委员会委员长，uke保安部首席大队长,uke制度检查委员会副会长，

奶牛科技cto ，uke 首席cto

uke波利尼西亚区大区连锁负责人，克尔格伦群岛区连锁负责人，莱恩群岛区连锁负责人，uke汤加王国区域负责人。布维岛和南乔治亚和南桑威奇群岛大区连锁负责人

Uke软件标准化协会理事长理事长 uke终身教育学校副校长

Uke 数据库与存储标准化协会副会长 uke出版社编辑总编

Uke医院方面的创始人

转载请注明来源：attilax的专栏  ?http://www.cnblogs.com/attilax/

--Atiend