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

 

posted @ 2016-12-27 15:11  attilaxAti  阅读(281)  评论(0编辑  收藏  举报