代码缩进与格式

代码缩进与格式的重要性

良好的代码缩进与格式是提升代码可读性的关键因素。合理的缩进能清晰展示代码结构层次，让逻辑关系一目了然。在团队协作中，统一的格式规范可以减少理解成本，提高开发效率。

基本缩进规则

JavaScript 社区普遍采用 2 个空格作为标准缩进单位。相比制表符(Tab)，空格在不同编辑器和环境中显示更一致。

// 正确的 2 空格缩进
function calculateTotal(items) {
  let total = 0;
  items.forEach(item => {
    if (item.available) {
      total += item.price * item.quantity;
    }
  });
  return total;
}

避免混合使用空格和制表符，这会导致在不同环境中显示混乱。现代编辑器都可以设置"将制表符转换为空格"。

块级作用域格式化

花括号 {} 的使用主要有两种风格，推荐使用"同一行"风格：

// 推荐：左花括号与语句在同一行
if (condition) {
  // ...
} else {
  // ...
}

// 不推荐：左花括号独占一行
if (condition)
{
  // ...
}

对于多级嵌套的代码，每层嵌套都应增加一级缩进：

function processData(data) {
  if (data) {
    try {
      data.items.forEach(item => {
        if (item.valid) {
          console.log(item.value);
        }
      });
    } catch (error) {
      console.error('Processing failed', error);
    }
  }
}

链式调用格式化

当方法链过长时，应该换行并保持正确的缩进：

// 好的写法
const result = array
  .filter(x => x > 10)
  .map(x => x * 2)
  .reduce((sum, x) => sum + x, 0);

// 不好的写法
const result = array.filter(x => x > 10).map(x => x * 2).reduce((sum, x) => sum + x, 0);

函数参数格式化

函数参数较多时应该换行，并保持对齐：

// 多个参数换行
function animate(
  element,
  duration,
  easing = 'linear',
  callback = () => {}
) {
  // 实现代码
}

// 调用时也保持同样风格
animate(
  document.getElementById('box'),
  300,
  'ease-in-out',
  () => console.log('Animation complete')
);

数组和对象格式化

对于多行数组和对象，应该保持一致的缩进：

// 数组格式化
const colors = [
  'red',
  'green',
  'blue',
  'yellow'
];

// 对象格式化
const config = {
  apiUrl: 'https://api.example.com',
  timeout: 5000,
  retries: 3,
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token'
  }
};

三元运算符格式化

复杂的三元表达式应该换行并正确缩进：

// 简单的可以保持一行
const accessLevel = isAdmin ? 'admin' : 'user';

// 复杂的应该换行
const message = isError
  ? 'An error occurred'
  : isLoading
    ? 'Loading...'
    : 'Data loaded successfully';

模板字符串格式化

多行模板字符串应该保持缩进对齐：

function createEmailTemplate(user) {
  return `
    Dear ${user.name},
    
    Thank you for registering on our platform. Your account details:
    
    Username: ${user.username}
    Email: ${user.email}
    
    Regards,
    The Team
  `.trim();
}

条件语句格式化

复杂的条件判断应该合理换行：

if (
  user.isAuthenticated &&
  user.hasPermission('edit') &&
  document.isEditable &&
  !document.isLocked
) {
  // 允许编辑
}

类和方法定义格式化

类定义和方法应该遵循一致的缩进规则：

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  getProfile() {
    return {
      name: this.name,
      email: this.email,
      lastLogin: this.lastLogin
    };
  }

  updateEmail(newEmail) {
    if (validateEmail(newEmail)) {
      this.email = newEmail;
      return true;
    }
    return false;
  }
}

模块导入导出格式化

模块导入应该分组并保持一致的格式：

// 第三方库
import React from 'react';
import PropTypes from 'prop-types';

// 工具函数
import { formatDate, parseCurrency } from './utils';

// 组件
import Button from './Button';
import Input from './Input';

注释的格式化

注释应该与代码保持相同的缩进级别：

function complexCalculation(a, b, c) {
  // 首先计算基础值
  const base = a * b;
  
  /*
   * 然后应用修正因子
   * 这个因子考虑了多种边界条件
   */
  const adjusted = base + (c * 0.5);
  
  return adjusted;
}

自动格式化工具

使用工具可以自动保持代码格式一致：

1. ESLint - 定义并强制执行代码风格
2. Prettier - 自动格式化代码
3. EditorConfig - 跨编辑器保持基本设置一致

示例 .eslintrc.js 配置：

module.exports = {
  indent: ['error', 2],
  'linebreak-style': ['error', 'unix'],
  quotes: ['error', 'single'],
  semi: ['error', 'always'],
  'comma-dangle': ['error', 'always-multiline']
};

特殊情况的处理

某些情况下可能需要临时调整格式以提高可读性：

// 矩阵数据可以保持紧凑格式
const transformationMatrix = [
  [1, 0, 0, 0],
  [0, 1, 0, 0],
  [0, 0, 1, 0],
  [0, 0, 0, 1]
];

// 长数值列表可以每行多个
const PRIMES = [
  2,  3,  5,  7, 11, 13, 17, 19, 23, 29,
  31, 37, 41, 43, 47, 53, 59, 61, 67, 71,
  73, 79, 83, 89, 97
];

团队协作中的格式规范

在团队项目中，应该：

1. 在项目根目录添加 .editorconfig 文件
2. 配置共享的 ESLint/Prettier 规则
3. 在代码审查中检查格式问题
4. 设置预提交钩子自动格式化代码

示例 .editorconfig 文件：

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

历史代码的格式化

处理遗留代码时：

1. 不要在一次提交中只做格式化修改
2. 可以在功能修改时逐步改进格式
3. 对大规模格式化应该单独提交并注明
4. 保持 git blame 信息的可用性

# 单独提交格式化修改
git commit -m "style: reformat code according to new guidelines"