ESLint space-infix-ops 规则详解强制中缀运算符两侧空格与自动修复【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslintspace-infix-ops是 ESLint 核心代码库lib/rules/中的一条布局layout类规则其作用是强制要求代码中所有中缀infix运算符两侧保留空格例如1 2、a ? b : c、a b。本指南以 docs/src/rules/space-infix-ops.md 官方文档为主体结合 规则源码 与 规则测试 的 680 余行用例完整讲解该规则的配置选项、可检查的运算符范围、int32Hint特例、自动修复逻辑与底层实现原理帮助你精确掌控中缀运算符空格的代码风格一致性。规则动机空格让意图一目了然虽然格式化偏好非常个人化但大量主流代码风格指南都要求在运算符周围留出空格例如var sum 1 2;该规则的支持者认为空格能显著提升代码可读性并能更容易暴露潜在的笔误。例如下面的代码虽然语法合法var sum i2;但读者很难判断作者究竟想表达i 2还是i 2抑或是i2本身。这正是space-infix-ops规则希望消灭的歧义场景——通过强制空格让运算符的优先级与结合关系在视觉上一目了然。规则详情它检查哪些语法结构根据 规则源码 中create(context)返回的监听器该规则会检查以下所有包含中缀运算符的 AST 节点类型节点类型覆盖的语法运算符示例BinaryExpression二元运算 - * / % ** ! ! \| ^ in instanceofLogicalExpression逻辑运算 \|\| ??AssignmentExpression赋值运算 - * / % ** \| ^ \|\| ??AssignmentPattern默认参数 / 解构默认值function foo(a 0)、var {b 0} barConditionalExpression三元条件运算a ? b : c同时检查?与:VariableDeclarator变量声明初始化var a b、const a {b:1}PropertyDefinition类字段class C { a b }ES2022配置选项该规则接受一个对象类型的选项参数默认配置如下space-infix-ops: [error, { int32Hint: false }]对应的 JSON Schema 定义在 规则源码 中选项必须是一个对象唯一允许的属性是int32Hint布尔类型默认false且不允许出现其他多余属性additionalProperties: false。int32Hint将int32Hint选项设置为true默认是false后允许写出不带空格的a|0形式。a|0是 JavaScript 中一个经典技巧与 0 做按位或运算会把操作数强制截断为 32 位有符号整数常用于数值取整或类型转换var foo bar|0; // foo is forced to be signed 32 bit integer启用该选项后形如bar|0这种整体式的 int32 转换表达式可以省略空格但其他普通|运算仍然必须加空格。从源码 checkBinary 的实现可见该特例的判定逻辑是仅当命中了未加空格的中缀运算符且int32Hint为true且整个节点的源码文本以|0结尾时才放行sourceCode.getText(node).endsWith(|0)否则照常上报。需要注意该特例的精确边界测试用例 tests/lib/rules/space-infix-ops.js 中给出了佐证a|0与a |0即|右侧紧贴0在int32Hint: true时视为合法但a| 0|左侧紧贴a、右侧与0之间留了空格在int32Hint: true时仍被判为违规并自动修复为a | 0因为此时getText得到的文本是a| 0并不以|0结尾。错误示例incorrect以下代码片段在该规则下均会被判定为错误假设/*eslint space-infix-ops: error*/已启用规则/*eslint space-infix-ops: error*/ ab a b a b a?b:c const a{b:1}; var {b0}bar; function foo(a0) { }逐条解读这些错误背后的触发点ab、a b、a b二元运算符两侧缺少完整空格a?b:c三元运算符的?与:两侧均缺少空格规则会分别上报两条missingSpace错误测试用例 a?b:c 两处错误 对此有精确验证包括每个错误的行列位置const a{b:1};变量声明的两侧缺少空格注意对象字面量内部b:1的冒号不在此规则管辖范围它属于对象属性间距问题var {b0}bar;解构默认值的与变量声明初始化的均缺少空格function foo(a0) { }函数默认参数的AssignmentPattern节点缺少空格。正确示例correct/*eslint space-infix-ops: error*/ a b a b a ? b : c const a {b:1}; var {b 0} bar; function foo(a 0) { }注意a b也是合法的该规则只要求运算符两侧至少存在一个空格并不限制空格数量多空格、对齐式写法均被允许对应测试用例a b。源码级实现原理核心检查getFirstNonSpacedToken规则的核心逻辑集中在 getFirstNonSpacedToken 中。它通过sourceCode.getFirstTokenBetween(left, right, ...)在两个操作数节点之间定位运算符 token然后取出运算符前后的相邻 token用sourceCode.isSpaceBetween(prev, operator)与sourceCode.isSpaceBetween(operator, next)分别判断运算符左右两侧是否留有空白。只要有一侧没有空格就返回该运算符 token 作为违规者。自动修复fixable: whitespace该规则在 meta 中声明fixable: whitespace意味着它支持--fix自动修复。修复逻辑位于 report 函数通过比较相邻 token 的range起止位置精确判断运算符左侧还是右侧缺少空格然后仅在被缺失的那一侧补上一个空格最终用fixer.replaceText(culpritToken, fixString)完成修复。测试文件中的每个invalid用例都携带output字段例如ab→a b、a?b:c→a ? b : c、var {a0}bar;→var {a 0} bar;完整验证了修复结果的正确性。类型注解与类字段的边界处理实现中还有两个值得注意的细节类型注解感知在checkBinary与checkVar中当左侧操作数带有类型注解如 TypeScript 的a: number时会取typeAnnotation作为左边界lib/rules/space-infix-ops.js#L142-L144、#L197-L199避免把注解内的:误当成检查对象。测试用例如var a: Foo b;→var a: Foo b;即是对该场景的验证。类字段PropertyDefinition由于类字段可能带有计算属性[a]或类型注解与node.key之间可能夹杂其他 token因此实现采用sourceCode.getTokenBefore(node.value, isEqToken)从右侧向左寻找真正的运算符lib/rules/space-infix-ops.js#L223-L246。isEqToken定义于 lib/rules/utils/ast-utils.js#L673-L675用于精确匹配类型为Punctuator、值为的 token。测试覆盖了class C { ab; }、class C { a b; }、class C { [a] b; }等多种类字段写法。覆盖的运算符范围由于该规则直接监听 AST 节点类型而非逐个枚举运算符因此对运算符的覆盖是全量的包括算术运算**幂运算、关系运算in、instanceof、逻辑赋值、||、??ES2021等均在检查范围内。测试文件中的a**b→a ** b、fooin{}→foo in {}、ab→a b等用例可以佐证。版本状态与迁移说明从 规则源码 的meta.deprecated字段可以看出该规则在ESLint v8.53.0 起被标记为废弃原因是 ESLint 官方正在将格式化类规则逐步移出核心库。其deprecatedSince为8.53.0availableUntil为11.0.0即核心库支持该规则至 ESLint 11.0.0之后将由ESLint Stylistic项目stylistic/eslint-plugin继续维护同名规则space-infix-ops。文档元数据 docs/src/rules/space-infix-ops.md 中的rule_type: layout也印证了其属于布局类规则配置元数据可参见 conf/rule-type-list.json 中的规则分类体系。如果你正在使用较新版本的 ESLint建议关注迁移指南将样式类规则的检查职责交给专门的格式化插件如果你仍在维护旧版配置或想了解该规则的行为细节本文描述的检查范围、选项语义与修复行为均以当前仓库的 规则实现 和 测试用例 为准。何时不使用该规则如果你并不关心中缀运算符周围的空格一致性可以关闭此规则space-infix-ops: off另外需要留意的是该规则不检查一元运算符如!a、-x、对象属性冒号、箭头函数等语法——这些分别由space-unary-ops、key-spacing、arrow-spacing等其他规则负责。如果你只希望约束某类运算符例如仅约束赋值与二元运算也可以考虑通过overrides或组合多条规则来实现更细粒度的控制。小结space-infix-ops是 ESLint 中最基础也最常用的布局规则之一它通过检查BinaryExpression、LogicalExpression、AssignmentExpression、ConditionalExpression、AssignmentPattern、VariableDeclarator与PropertyDefinition七类节点强制中缀运算符两侧必须存在空格并提供int32Hint选项放行a|0这类有意的紧凑写法。其源码实现围绕isSpaceBetween的空格判定与基于 token range 的精确修复展开测试覆盖完整含类型注解、逻辑赋值、类字段等现代语法。虽然该规则已被标记为废弃并计划在 ESLint 11 移出核心但理解其设计对迁移到 ESLint Stylistic 或编写自定义布局规则仍具有直接的参考价值。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ESLint space-infix-ops 规则详解：强制中缀运算符两侧空格与自动修复
ESLint space-infix-ops 规则详解强制中缀运算符两侧空格与自动修复【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslintspace-infix-ops是 ESLint 核心代码库lib/rules/中的一条布局layout类规则其作用是强制要求代码中所有中缀infix运算符两侧保留空格例如1 2、a ? b : c、a b。本指南以 docs/src/rules/space-infix-ops.md 官方文档为主体结合 规则源码 与 规则测试 的 680 余行用例完整讲解该规则的配置选项、可检查的运算符范围、int32Hint特例、自动修复逻辑与底层实现原理帮助你精确掌控中缀运算符空格的代码风格一致性。规则动机空格让意图一目了然虽然格式化偏好非常个人化但大量主流代码风格指南都要求在运算符周围留出空格例如var sum 1 2;该规则的支持者认为空格能显著提升代码可读性并能更容易暴露潜在的笔误。例如下面的代码虽然语法合法var sum i2;但读者很难判断作者究竟想表达i 2还是i 2抑或是i2本身。这正是space-infix-ops规则希望消灭的歧义场景——通过强制空格让运算符的优先级与结合关系在视觉上一目了然。规则详情它检查哪些语法结构根据 规则源码 中create(context)返回的监听器该规则会检查以下所有包含中缀运算符的 AST 节点类型节点类型覆盖的语法运算符示例BinaryExpression二元运算 - * / % ** ! ! \| ^ in instanceofLogicalExpression逻辑运算 \|\| ??AssignmentExpression赋值运算 - * / % ** \| ^ \|\| ??AssignmentPattern默认参数 / 解构默认值function foo(a 0)、var {b 0} barConditionalExpression三元条件运算a ? b : c同时检查?与:VariableDeclarator变量声明初始化var a b、const a {b:1}PropertyDefinition类字段class C { a b }ES2022配置选项该规则接受一个对象类型的选项参数默认配置如下space-infix-ops: [error, { int32Hint: false }]对应的 JSON Schema 定义在 规则源码 中选项必须是一个对象唯一允许的属性是int32Hint布尔类型默认false且不允许出现其他多余属性additionalProperties: false。int32Hint将int32Hint选项设置为true默认是false后允许写出不带空格的a|0形式。a|0是 JavaScript 中一个经典技巧与 0 做按位或运算会把操作数强制截断为 32 位有符号整数常用于数值取整或类型转换var foo bar|0; // foo is forced to be signed 32 bit integer启用该选项后形如bar|0这种整体式的 int32 转换表达式可以省略空格但其他普通|运算仍然必须加空格。从源码 checkBinary 的实现可见该特例的判定逻辑是仅当命中了未加空格的中缀运算符且int32Hint为true且整个节点的源码文本以|0结尾时才放行sourceCode.getText(node).endsWith(|0)否则照常上报。需要注意该特例的精确边界测试用例 tests/lib/rules/space-infix-ops.js 中给出了佐证a|0与a |0即|右侧紧贴0在int32Hint: true时视为合法但a| 0|左侧紧贴a、右侧与0之间留了空格在int32Hint: true时仍被判为违规并自动修复为a | 0因为此时getText得到的文本是a| 0并不以|0结尾。错误示例incorrect以下代码片段在该规则下均会被判定为错误假设/*eslint space-infix-ops: error*/已启用规则/*eslint space-infix-ops: error*/ ab a b a b a?b:c const a{b:1}; var {b0}bar; function foo(a0) { }逐条解读这些错误背后的触发点ab、a b、a b二元运算符两侧缺少完整空格a?b:c三元运算符的?与:两侧均缺少空格规则会分别上报两条missingSpace错误测试用例 a?b:c 两处错误 对此有精确验证包括每个错误的行列位置const a{b:1};变量声明的两侧缺少空格注意对象字面量内部b:1的冒号不在此规则管辖范围它属于对象属性间距问题var {b0}bar;解构默认值的与变量声明初始化的均缺少空格function foo(a0) { }函数默认参数的AssignmentPattern节点缺少空格。正确示例correct/*eslint space-infix-ops: error*/ a b a b a ? b : c const a {b:1}; var {b 0} bar; function foo(a 0) { }注意a b也是合法的该规则只要求运算符两侧至少存在一个空格并不限制空格数量多空格、对齐式写法均被允许对应测试用例a b。源码级实现原理核心检查getFirstNonSpacedToken规则的核心逻辑集中在 getFirstNonSpacedToken 中。它通过sourceCode.getFirstTokenBetween(left, right, ...)在两个操作数节点之间定位运算符 token然后取出运算符前后的相邻 token用sourceCode.isSpaceBetween(prev, operator)与sourceCode.isSpaceBetween(operator, next)分别判断运算符左右两侧是否留有空白。只要有一侧没有空格就返回该运算符 token 作为违规者。自动修复fixable: whitespace该规则在 meta 中声明fixable: whitespace意味着它支持--fix自动修复。修复逻辑位于 report 函数通过比较相邻 token 的range起止位置精确判断运算符左侧还是右侧缺少空格然后仅在被缺失的那一侧补上一个空格最终用fixer.replaceText(culpritToken, fixString)完成修复。测试文件中的每个invalid用例都携带output字段例如ab→a b、a?b:c→a ? b : c、var {a0}bar;→var {a 0} bar;完整验证了修复结果的正确性。类型注解与类字段的边界处理实现中还有两个值得注意的细节类型注解感知在checkBinary与checkVar中当左侧操作数带有类型注解如 TypeScript 的a: number时会取typeAnnotation作为左边界lib/rules/space-infix-ops.js#L142-L144、#L197-L199避免把注解内的:误当成检查对象。测试用例如var a: Foo b;→var a: Foo b;即是对该场景的验证。类字段PropertyDefinition由于类字段可能带有计算属性[a]或类型注解与node.key之间可能夹杂其他 token因此实现采用sourceCode.getTokenBefore(node.value, isEqToken)从右侧向左寻找真正的运算符lib/rules/space-infix-ops.js#L223-L246。isEqToken定义于 lib/rules/utils/ast-utils.js#L673-L675用于精确匹配类型为Punctuator、值为的 token。测试覆盖了class C { ab; }、class C { a b; }、class C { [a] b; }等多种类字段写法。覆盖的运算符范围由于该规则直接监听 AST 节点类型而非逐个枚举运算符因此对运算符的覆盖是全量的包括算术运算**幂运算、关系运算in、instanceof、逻辑赋值、||、??ES2021等均在检查范围内。测试文件中的a**b→a ** b、fooin{}→foo in {}、ab→a b等用例可以佐证。版本状态与迁移说明从 规则源码 的meta.deprecated字段可以看出该规则在ESLint v8.53.0 起被标记为废弃原因是 ESLint 官方正在将格式化类规则逐步移出核心库。其deprecatedSince为8.53.0availableUntil为11.0.0即核心库支持该规则至 ESLint 11.0.0之后将由ESLint Stylistic项目stylistic/eslint-plugin继续维护同名规则space-infix-ops。文档元数据 docs/src/rules/space-infix-ops.md 中的rule_type: layout也印证了其属于布局类规则配置元数据可参见 conf/rule-type-list.json 中的规则分类体系。如果你正在使用较新版本的 ESLint建议关注迁移指南将样式类规则的检查职责交给专门的格式化插件如果你仍在维护旧版配置或想了解该规则的行为细节本文描述的检查范围、选项语义与修复行为均以当前仓库的 规则实现 和 测试用例 为准。何时不使用该规则如果你并不关心中缀运算符周围的空格一致性可以关闭此规则space-infix-ops: off另外需要留意的是该规则不检查一元运算符如!a、-x、对象属性冒号、箭头函数等语法——这些分别由space-unary-ops、key-spacing、arrow-spacing等其他规则负责。如果你只希望约束某类运算符例如仅约束赋值与二元运算也可以考虑通过overrides或组合多条规则来实现更细粒度的控制。小结space-infix-ops是 ESLint 中最基础也最常用的布局规则之一它通过检查BinaryExpression、LogicalExpression、AssignmentExpression、ConditionalExpression、AssignmentPattern、VariableDeclarator与PropertyDefinition七类节点强制中缀运算符两侧必须存在空格并提供int32Hint选项放行a|0这类有意的紧凑写法。其源码实现围绕isSpaceBetween的空格判定与基于 token range 的精确修复展开测试覆盖完整含类型注解、逻辑赋值、类字段等现代语法。虽然该规则已被标记为废弃并计划在 ESLint 11 移出核心但理解其设计对迁移到 ESLint Stylistic 或编写自定义布局规则仍具有直接的参考价值。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考