我喜欢的5种编程模式

在这篇文章中，我介绍了一些我在编程时尝试使用的模式。这些模式是我最近在工作时所做的观察以及我多年来从同事那里偷走的一对。

这些模式没有特别的顺序只是一个简单的集合。

1.早退

功能 transformData（原始数据） {   //检查是否没有数据   如果 （原始数据） {     返回 （）;   }    //检查具体情况   如果 （原始数据。长度 == 1） {     返回 （）;   }    //实际的功能代码在这里   返回 原始数据。地图（（项目） => 项目）; } 

我将这种模式称为“早期退出”，但有些人也将此称为“保镖模式”或“保护条款”。除了命名之外，该模式首先采用检查无效用例并从该函数返回的方法，否则它继续到函数的预期用例并执行。

对我来说，这种方法有一些我非常喜欢的积极因素：

• 鼓励思考无效/边缘情况以及如何处理这些情况
• 避免意外和不必要的代码处理意外用例
• 在心理上允许我更清楚地处理每个用例
• 一旦采用，您可以快速浏览功能并了解流程和执行情况，这通常遵循自上而下的方法 – 无效情况 – >小案例 – >预期案例

更多信息：

• Rik Schennink的保镖模式

2.切换到对象文字

//切换 让 createType = 空值; 开关 （内容类型） {   案件 “后”：     createType = （） => 安慰。日志（“创建一个帖子......”）;     打破;   案件 “视频”：     createType = （） => 安慰。日志（“制作视频......”）;     打破;   默认：     createType = （） => 安慰。日志（'无法识别的内容类型'）; }  createType（）;  //对象文字 常量 CONTENTTYPES = {   岗位： （） => 安慰。日志（“创建一个帖子......”）   视频： （） => 安慰。日志（“创造视频......”）   默认： （） => 安慰。日志（'无法识别的内容类型'） };  常量 createType = CONTENTTYPES（内容类型） || CONTENTTYPES（'默认'）; createType（）; 

接下来是删除 开关。每次写作时我经常会犯错误 案件 而且经常忘记一个 打破。这会导致各种有趣的问题。该 开关 在编写代码时，语句不会添加很多值。它似乎妨碍了。

我更喜欢使用对象文字，这就是为什么：

• 不必担心 案件 要么 打破
• 更容易阅读并快速了解正在发生的事情
• 对象文字很容易写
• 更少的代码

更多信息：

• 切换案例，if else或May Shavin的循环图
• 用Todd Motto替换带有对象文字的switch语句
• 重写Javascript：替换Chris Burgin的Switch语句

3.一个循环两个数组

常量 exampleValues = （2， 15， 8， 23， 1， 32）; 常量 （truthyValues， falseyValues） = exampleValues。降低（（阵列， exampleValue） => {   如果 （exampleValue > 10） {     阵列（0）。推（exampleValue）;     返回 阵列;   }    阵列（1）。推（exampleValue）;   返回 阵列; }， （（）， （）））; 

这种模式并不是特别的，我应该早点意识到它，但我发现自己过滤了一系列项目以获得符合某种条件的所有项目，然后再次针对不同的条件再做一次。这意味着两次循环数组，但我可以做一次。

事实证明这有一个名字（bifurcate），我从30secondsofcode.org偷了它。如果您从未检查过该网站，我建议您去那里。这么多好的信息和有用的代码。

我知道reduce可能有点令人生畏，并且不是很清楚发生了什么，但是如果你能够熟悉它，你可以真正利用它来构建循环收集时所需的任何数据结构。他们真的应该叫它 建设者 代替 降低。

更多信息：

• 30secondsofcode.org

4.没有'foo'变量

//糟糕 常量 FOO = ÿ && ž;  //好 常量 isPostEnabled = isPost && postDateValid; 

这个看起来有点明显，但我确信我们都看到过这样做的代码。花点时间，尽力给出恰当的名字。

这对于工作专业人员或处于教育他人职位的人员来说尤为重要。变量命名应该用于帮助解释和给出代码中发生的事情的上下文。

有人应该能够阅读你的代码，然后开始理解想要解决的问题。

更多信息：

• Richard Tan命名变量的艺术

5.嵌套三元组

让 结果 = 空值; 如果 （conditionA） {   如果 （conditionB） {     结果 = “A＆B”;   } 其他 {     结果 = “一个”;   } } 其他 {   结果 = “不是”; }  常量 结果 = conditionA   ？ “不是”   ： conditionB   ？ “A＆B”   ： “一个”; 

我承认，一开始，嵌套三元组的想法令人反感。它似乎是一种编写条件的聪明方法。然后我开始编写业务逻辑，发现自己使用嵌套的if else子句和一些非常有问题的条件逻辑。

我认为 如果 和 其他 更容易阅读，因为它们是实际的单词，但当这些变成嵌套时，我开始真的很难跟踪正在发生的事情并精神上跟踪所有事情。

我开始推迟三元和嵌套三元组，我发现我能够快速了解​​发生了什么。

我认为这种模式完全取决于您和您的团队以及您的偏好。我曾在代码库中工作过，并且能够很好地看到这两方面，但个人嵌套的三元组实际上正在增长。

更多信息：

• 埃里克·艾略特（Eric Elliot）的嵌套三元组很棒