核心是结合mix format和Credo：前者负责代码排版，后者检查代码风格与质量。在VSCode中通过ElixirLS扩展实现自动格式化与实时反馈，并通过credo.exs定制规则，配合Git Hooks确保提交代码符合规范。
要在VSCode里让Elixir代码看起来整洁规范，并且符合团队或个人定义的风格，最核心的其实是两件事：一是利用Elixir自带的
mix format进行基础格式化，二是引入Credo这个强大的静态分析工具来检查和指导代码风格。两者结合，才能真正做到“格式化”和“风格统一”。
解决方案
说实话，很多人在刚接触Elixir的时候，会把“格式化”和“代码风格检查”混为一谈，觉得Credo就是用来格式化的。这其实是个常见的误区。
mix format才是Elixir官方自带的格式化工具，它负责代码的结构和排版，比如缩进、换行、操作符间距等。而Credo呢，它更像是一个代码风格的“警察”和“导师”，它会根据一系列规则来检查你的代码，找出潜在的问题、不符合规范的写法，甚至是一些“坏味道”。所以，在VSCode中“格式化”Elixir代码并配置Credo，本质上是让这两个工具协同工作。
以下是具体的步骤和我的实践经验：
安装VSCode ElixirLS扩展： 这是VSCode里Elixir开发体验的基石。在VSCode扩展市场搜索“ElixirLS”，然后安装。这个扩展会提供语法高亮、智能提示、跳转定义、调试等一系列功能，当然也包括与
mix format
和Credo的集成。-
在项目中引入Credo： Credo通常作为项目的开发依赖来使用。打开你的Elixir项目根目录下的
mix.exs
文件，在deps
函数中添加Credo：defp deps do [ # ... 其他依赖 {:credo, "~> 1.6", only: [:dev, :test], runtime: false} ] end然后运行
mix deps.get
来下载并安装Credo。这样，Credo就成为了你项目的一部分，ElixirLS就能自动检测到它。 -
配置VSCode自动运行
mix format
： 这是实现“格式化”的关键一步。ElixirLS默认会使用mix format
，但为了让它在保存文件时自动运行，你需要在VSCode的设置（Ctrl+,
或Cmd+,
）中进行配置。搜索editor.formatOnSave
，确保它被勾选。如果你的工作区有特定的设置，可以在
.vscode/settings.json
中添加或修改：{ "editor.formatOnSave": true, "[elixir]": { "editor.defaultFormatter": "JakeBecker.elixir-ls" } }这样，每次你保存
.ex
文件时，mix format
就会自动运行，你的代码就会按照Elixir的官方规范进行排版。 -
Credo的集成与反馈： 一旦你在
mix.exs
中引入了Credo，ElixirLS会自动在后台运行Credo，并将检查结果实时显示在VSCode的“问题”（Problems）面板中，或者在代码旁边以波浪线或下划线的形式提示。你不需要额外配置ElixirLS去“运行”Credo，它会自己找到并使用项目中的Credo。这才是Credo真正发挥作用的地方：它会告诉你哪里有“魔法数字”、函数参数过多、注释不足、命名不规范等等。这些都不是
mix format
能处理的，而是需要你根据Credo的提示去思考和修改代码逻辑或风格。
为什么我的Elixir代码格式化后还是有风格问题？理解mix format
与Credo的区别
这个问题我被问过太多次了，甚至我自己刚开始用Elixir的时候也困惑过。说白了，
mix format和Credo扮演的角色是完全不同的。
mix format，就像它的名字一样，是一个纯粹的“格式化”工具。它的目标是让Elixir代码在视觉上保持一致性，减少因个人习惯造成的排版差异。它处理的是代码的物理结构：缩进多少个空格、操作符前后有没有空格、列表元素如何换行、管道操作符怎么对齐等等。它非常“固执己见”，有一套官方推荐的格式规则，而且基本上不提供太多自定义选项（除了少数几个）。它的好处是，团队成员的代码提交上来，格式都是统一的，减少了不必要的代码审查噪音。
而Credo，它是一个静态代码分析工具，它的关注点是代码的逻辑结构和风格。它不负责改变你的代码排版，而是去“阅读”你的代码，然后告诉你：“嘿，这个函数参数有点多啊，是不是可以重构一下？”或者“你这里用了一个魔法数字，最好定义成一个常量。”再比如，“这个模块的责任是不是有点重了？”Credo有一套非常丰富的规则集，涵盖了从命名规范、复杂度、代码重复到最佳实践等多个方面。而且，Credo是高度可配置的，你可以根据团队的具体需求，启用、禁用或者调整它的规则。
所以，当你运行
mix format后，代码看起来整齐了，但Credo可能仍然会指出一堆问题。这并不是说
mix format没做好它的工作，而是因为这些问题根本就不在
mix format的职责范围之内。它们是关于代码质量、可读性、可维护性层面的问题，需要通过Credo的指导和你的手动修改来解决。两者是互补的，
mix format保证了代码的“面子”，Credo则帮助你打理好代码的“里子”。
如何在项目中定制Credo规则以适应团队风格？credo.exs
配置详解
团队协作时，代码风格统一是件大事。虽然Credo自带了一套默认规则，但每个团队都有自己的偏好。这时候，
credo.exs文件就派上用场了，它是Credo的“大脑”，让你能精细地控制Credo的行为。
首先，如果你还没有
credo.exs文件，可以在项目根目录运行：
mix credo gen.config
这会生成一个默认的
credo.exs文件，里面包含了所有可用的检查项和它们的默认配置。这个文件通常位于项目的根目录。
打开
credo.exs，你会看到几个主要的部分：
-
configs
: 这是最核心的部分，定义了Credo要运行哪些检查以及如何运行。每个配置项都是一个元组，通常是{Credo.Check.Category.CheckName, [key: value]}的形式。-
启用/禁用检查： 如果你想禁用某个检查，只需把它从
checks
列表中删除，或者在配置中设置false
。比如，如果你觉得Credo.Check.Readability.MaxLineLength
这个检查太严格，可以这样调整：# 默认是80，我们可以放宽到120 {Credo.Check.Readability.MaxLineLength, priority: :low, max_length: 120} # 如果想完全禁用，就直接删掉这行或者注释掉 # {Credo.Check.Readability.MaxLineLength, priority: :low} 调整优先级（
priority
）： Credo会根据优先级来排序问题。priority: :high
表示这是个严重问题，priority: :low
则相对次要。你可以根据团队对不同问题的重视程度来调整。特定检查的参数： 很多检查都支持自定义参数。比如
MaxLineLength
有max_length
，MaxNesting
有max_nesting
。仔细阅读Credo的文档，了解每个检查支持的参数。-
排除文件或目录（
exclude
）： 有些文件或目录你可能不想让Credo检查，比如一些自动生成的文件、测试辅助文件或者第三方库的拷贝。你可以在exclude
列表中添加模式：exclude: [ ~r"/lib/my_app_web/views/.*", # 排除所有视图文件 ~r"/priv/repo/migrations/.*" # 排除数据库迁移文件 ]
-
strict
模式： 在credo.exs
的顶部，你可能会看到strict: true
或strict: false
。当strict: true
时，Credo会把所有非priority: :low
的问题都当作错误（exit code非零），这在CI/CD流程中非常有用，可以强制代码质量。read_from_stdin
： 这个设置通常用于IDE集成，当设置为true
时，Credo可以从标准输入读取代码进行检查，而不是文件系统，这使得ElixirLS等工具能更高效地提供实时反馈。
我的建议是：
- 从默认配置开始： 不要一上来就改太多，先用默认的跑几遍，看看哪些问题是你团队真正关心的。
- 逐步调整： 每次只调整几个规则，然后运行Credo，看看效果。
- 团队讨论： 最好是团队成员一起讨论，哪些规则是必须遵守的，哪些可以放宽。这能确保大家对代码风格有共识。
-
结合
mix credo suggest
： 运行mix credo suggest
可以找出项目中哪些检查项目前没有被用到，或者哪些可以优化。
通过定制
credo.exs，你可以让Credo成为团队代码风格的守护者，确保代码库的长期健康和一致性。
VSCode中的ElixirLS如何与Credo协同工作？优化你的开发体验
ElixirLS和Credo的结合，可以说是我在VSCode里开发Elixir最舒服的体验之一。它不是简单地把两个工具堆在一起，而是实现了一种相当智能的协同工作模式，极大提升了开发效率和代码质量。
首先，自动检测与实时反馈是核心。一旦你的Elixir项目在
mix.exs中声明了Credo依赖，ElixirLS就会自动识别到它。你不需要在VSCode的设置里手动指定Credo的路径或者配置它如何运行。当你在编辑
.ex文件时，ElixirLS会默默地在后台运行Credo对当前文件进行分析。Credo发现的任何问题，无论是警告（Warning）还是建议（Suggestion），都会立即显示在VSCode的“问题”面板（通常在底部）中，并且在代码行旁边以波浪线或小灯泡图标的形式提示你。这种实时反馈意味着你几乎可以在犯错的瞬间就得到纠正，避免了等到提交代码或者运行测试时才发现风格问题。
其次，这种集成带来的无缝体验非常重要。你不需要频繁地切换终端去运行
mix credo命令。所有关于代码风格的提示都直接呈现在你的编辑器界面上，和语法错误、类型提示等信息混在一起，形成了一个统一的开发视图。这减少了上下文切换的开销，让你可以更专注于代码本身。
再来，考虑一下性能和资源消耗。ElixirLS在设计上考虑了效率。它不会每次保存都对整个项目运行一次Credo，而是通常只对你正在编辑的文件或最近修改的文件进行增量分析。这确保了即使是大型项目，Credo的实时反馈也能保持快速响应，不会拖慢你的开发节奏。
最后，我想提一个我个人觉得非常重要的实践：结合Git Hooks。虽然ElixirLS在开发时提供了实时反馈，但人总有疏忽的时候。为了确保团队提交的代码都符合Credo的规范，我强烈建议在项目的Git Hooks中加入Credo检查。最常见的是使用
pre-commithook。
你可以通过一些工具（比如
huskyfor JavaScript/Node.js projects, 或者直接写shell脚本）来配置
pre-commithook。当你在
git commit之前，这个hook会自动运行
mix credo（可能只针对暂存区的文件）。如果Credo发现任何高优先级的问题，提交就会被阻止，强制你先修复代码。这就像是最后一道防线，确保没有不符合规范的代码进入版本库。
举个简单的
pre-commit脚本例子（如果你在项目根目录创建
.git/hooks/pre-commit并赋予执行权限）：
#!/bin/sh # # An example hook script to verify what is about to be committed. # Called by "git commit" with no arguments. The hook should exit with non-zero # status after issuing an appropriate message if it wants to stop the commit. # # To enable this hook, rename this file to "pre-commit". echo "Running Credo checks before commit..." # Only check staged files that are .ex files git diff --cached --name-only --diff-filter=ACM | grep '\.ex$' | xargs mix credo --read-from-stdin if [ $? -ne 0 ]; then echo "Credo checks failed. Please fix the issues before committing." exit 1 fi echo "Credo checks passed." exit 0
通过这种方式，ElixirLS在开发过程中提供“即时指导”，而Git Hooks则在提交前提供“最终把关”，两者共同构建了一个健壮的Elixir代码质量保障体系。
