环球快报:2022年02月11日整理发布：10种TypeScript编写代码时应改正的坏习惯

现如今大家都会选择在网络上汲取相关知识内容，比如2022年02月11日整理发布：10种TypeScript编写代码时应改正的坏习惯，为了更好的解答大家的问题，小编也是翻阅整理了相应内容，下面就一起来看一下吧！

我来告诉你写10个打字稿时应该改正的坏习惯。相信朋友们也应该很关心这个话题。现在，我来告诉你写10个打字稿时应该改正的坏习惯。边肖还收集了有关写10个打字稿时应该改正的坏习惯的相关信息。我希望你看到他们时会喜欢。

TypeScript和JavaScript近年来发展稳定。我们过去写代码的时候养成了一些习惯，但是有些习惯是没有意义的。这里有10个我们都应该改正的坏习惯。

(相关资料图)

1.不使用严格模式的习惯是什么样子的？tsconfig.json不是以严格模式编写的。

{

compilerOptions": {

目标" : "ES2015 "，

模块" : "commonjs "

}

}我该怎么办？只需启用严格模式：

{

compilerOptions": {

目标" : "ES2015 "，

模块" : "commonjs "，

严格" :真

}

}为什么会有这样的坏习惯？在现有的代码库中引入更严格的规则需要时间。

你为什么不应该这么做？更严格的规则使将来维护代码变得更容易，并为您节省了大量时间。

2.用||定义默认值的习惯是什么样子的？使用旧||来处理备份默认值：

函数createBlogPost (text:字符串，author:字符串，日期？日期){ 0

返回{

文本：文本，

作者：作者，

日期：日期||新日期()

}

}我应该如何使用新的？运算符，或者重新定义参数中的默认值。

函数createBlogPost (text:字符串，author:字符串，date: Date=new Date())

返回{

文本：文本，

作者：作者，

日期：日期

}

}为什么会有这样的坏习惯？运算符是去年才引入的，在长函数中使用时可能很难将该值设置为参数默认值。

你为什么不应该这么做？不像||，仅适用于空值或未定义值，不适用于所有虚数。

3.随意使用任何类型。这个习惯是什么样子的？当您不确定结构时，可以使用任何类型。

异步函数LoadProducts(): PromiseProduct[]{ 0

const response=wait fetch(" https://API . mysite.com/products ")

const products : any=wait response . JSON()

退货产品

}您应该如何将代码中任何使用any的地方更改为unknown？

异步函数LoadProducts(): PromiseProduct[]{ 0

const response=wait fetch(" https://API . mysite.com/products ")

const products : unknown=wait response . JSON()

将产品作为产品[]退回

}为什么会有这个坏习惯any非常方便，因为它基本上禁用了所有类型检查。通常，即使在官方提供的类型中也使用任何。例如，在上面的例子中，TypeScript团队将response.json()的类型设置为Promise any。

你为什么不应该这么做？它基本上禁用了所有类型的检查。任何通过任何途径进入的东西都将完全放弃所有类型的支票。这将使错误很难被发现。

4.什么样的习惯会迫使编译器说出无法推断的类型？

异步函数LoadProducts(): PromiseProduct[]{ 0

const response=wait fetch(" https://API . mysite.com/products ")

const products : unknown=wait response . JSON()

将产品作为产品[]退回

}应该

怎样

这正是 Type Guard 的用武之地。

function isArrayOfProducts (obj: unknown): obj is Product[] { return Array.isArray(obj) && obj.every(isProduct)}function isProduct (obj: unknown): obj is Product { return obj != null && typeof (obj as Product).id === "string"}async function loadProducts(): Promise { const response = await fetch("https://api.mysite.com/products") const products: unknown = await response.json() if (!isArrayOfProducts(products)) { throw new TypeError("Received malformed products API response") } return products}为什么会有这种坏习惯

从 JavaScript 转到 TypeScript 时，现有的代码库通常会对 TypeScript 编译器无法自动推断出的类型进行假设。在这时，通过 as SomeOtherType 可以加快转换速度，而不必修改 tsconfig 中的设置。

为什么不该这样做

Type Guard 会确保所有检查都是明确的。

5. 测试中的 as any这种习惯看起来是什么样的

编写测试时创建不完整的用例。

interface User { id: string firstName: string lastName: string email: string}test("createEmailText returns text that greats the user by first name", () => { const user: User = { firstName: "John" } as any expect(createEmailText(user)).toContain(user.firstName)}应该怎样

如果你需要模拟测试数据，请将模拟逻辑移到要模拟的对象旁边，并使其可重用。

interface User { id: string firstName: string lastName: string email: string}class MockUser implements User { id = "id" firstName = "John" lastName = "Doe" email = "john@doe.com"}test("createEmailText returns text that greats the user by first name", () => { const user = new MockUser() expect(createEmailText(user)).toContain(user.firstName)}为什么会有这种坏习惯

在给尚不具备广泛测试覆盖条件的代码编写测试时，通常会存在复杂的大数据结构，但要测试的特定功能仅需要其中的一部分。短期内不必关心其他属性。

为什么不该这样做

在某些情况下，被测代码依赖于我们之前认为不重要的属性，然后需要更新针对该功能的所有测试。

6. 可选属性这种习惯看起来是什么样的

将属性标记为可选属性，即便这些属性有时不存在。

interface Product { id: string type: "digital" | "physical" weightInKg?: number sizeInMb?: number}应该怎样

明确哪些组合存在，哪些不存在。

interface Product { id: string type: "digital" | "physical"}interface DigitalProduct extends Product { type: "digital" sizeInMb: number}interface PhysicalProduct extends Product { type: "physical" weightInKg: number}为什么会有这种坏习惯

将属性标记为可选而不是拆分类型更容易，并且产生的代码更少。它还需要对正在构建的产品有更深入的了解，并且如果对产品的设计有所修改，可能会限制代码的使用。

为什么不该这样做

类型系统的最大好处是可以用编译时检查代替运行时检查。通过更显式的类型，能够对可能不被注意的错误进行编译时检查，例如确保每个 DigitalProduct 都有一个 sizeInMb。

7. 用一个字母通行天下这种习惯看起来是什么样的

用一个字母命名泛型

function head (arr: T[]): T | undefined { return arr[0]}应该怎样

提供完整的描述性类型名称。

function head (arr: Element[]): Element | undefined { return arr[0]}为什么会有这种坏习惯

这种写法最早来源于C++的范型库，即使是 TS 的官方文档也在用一个字母的名称。它也可以更快地输入，只需要简单的敲下一个字母 T 就可以代替写全名。

为什么不该这样做

通用类型变量也是变量，就像其他变量一样。当 IDE 开始向我们展示变量的类型细节时，我们已经慢慢放弃了用它们的名称描述来变量类型的想法。例如我们现在写代码用 const name ="Daniel"，而不是 const strName ="Daniel"。同样，一个字母的变量名通常会令人费解，因为不看声明就很难理解它们的含义。

8. 对非布尔类型的值进行布尔检查这种习惯看起来是什么样的

通过直接将值传给 if 语句来检查是否定义了值。

function createNewMessagesResponse (countOfNewMessages?: number) { if (countOfNewMessages) { return `You have ${countOfNewMessages} new messages` } return "Error: Could not retrieve number of new messages"}应该怎样

明确检查我们所关心的状况。

function createNewMessagesResponse (countOfNewMessages?: number) { if (countOfNewMessages !== undefined) { return `You have ${countOfNewMessages} new messages` } return "Error: Could not retrieve number of new messages"}为什么会有这种坏习惯

编写简短的检测代码看起来更加简洁，使我们能够避免思考实际想要检测的内容。

为什么不该这样做

也许我们应该考虑一下实际要检查的内容。例如上面的例子以不同的方式处理 countOfNewMessages 为 0 的情况。

9. ”棒棒“运算符这种习惯看起来是什么样的

将非布尔值转换为布尔值。

function createNewMessagesResponse (countOfNewMessages?: number) { if (!!countOfNewMessages) { return `You have ${countOfNewMessages} new messages` } return "Error: Could not retrieve number of new messages"}应该怎样

明确检查我们所关心的状况。

function createNewMessagesResponse (countOfNewMessages?: number) { if (countOfNewMessages !== undefined) { return `You have ${countOfNewMessages} new messages` } return "Error: Could not retrieve number of new messages"}为什么会有这种坏习惯

对某些人而言，理解 !! 就像是进入 JavaScript 世界的入门仪式。它看起来简短而简洁，如果你对它已经非常习惯了，就会知道它的含义。这是将任意值转换为布尔值的便捷方式。尤其是在如果虚值之间没有明确的语义界限时，例如 null、undefined 和 ""。

为什么不该这样做

与很多编码时的便捷方式一样，使用 !! 实际上是混淆了代码的真实含义。这使得新开发人员很难理解代码，无论是对一般开发人员来说还是对 JavaScript 来说都是新手。也很容易引入细微的错误。在对“非布尔类型的值”进行布尔检查时 countOfNewMessages 为 0 的问题在使用 !! 时仍然会存在。

10. != null这种习惯看起来是什么样的

棒棒运算符的小弟 ! = null使我们能同时检查 null 和 undefined。

function createNewMessagesResponse (countOfNewMessages?: number) { if (countOfNewMessages != null) { return `You have ${countOfNewMessages} new messages` } return "Error: Could not retrieve number of new messages"}应该怎样

明确检查我们所关心的状况。

function createNewMessagesResponse (countOfNewMessages?: number) { if (countOfNewMessages !== undefined) { return `You have ${countOfNewMessages} new messages` } return "Error: Could not retrieve number of new messages"}为什么会有这种坏习惯

如果你的代码在 null 和 undefined 之间没有明显的区别，那么 != null 有助于简化对这两种可能性的检查。

为什么不该这样做

尽管 null 在 JavaScript早期很麻烦，但 TypeScript 处于 strict 模式时，它却可以成为这种语言中宝贵的工具。一种常见模式是将 null 值定义为不存在的事物，将 undefined 定义为未知的事物，例如 user.firstName === null 可能意味着用户实际上没有名字，而 user.firstName === undefined 只是意味着我们尚未询问该用户（而 user.firstName === 的意思是字面意思是 "" 。

原文：https://startup-cto.net/10-bad-typescript-habits-to-break-this-year/

作者：Daniel Bartholomae

译文地址：https://segmentfault.com/a/1190000039368534

更多编程相关知识，请访问：编程入门！！

以上就是10种TypeScript编写代码时应改正的坏习惯的详细内容，更多请关注php中文网其它相关文章！

来源：php中文网

标签： 是什么样的 是什么样子 编译时检查 布尔类型