organize-elixir-functions

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Scope Mode

范围模式

  • File mode: if a file path is provided, only organize that file.
  • Branch mode: if no file path is provided, inspect changed files on the current branch and organize files that need updates.
    • To see ALL changes made on the branch, always check:
      • committed branch-only changes:
        git diff --name-status "$(git merge-base HEAD main)"...HEAD
      • all working tree changes:
        git status --short
  • 文件模式:如果提供了文件路径,仅整理该文件。
  • 分支模式:如果未提供文件路径,检查当前分支中已修改的文件,并整理需要更新的文件。
    • 要查看分支上的所有变更,请始终检查:
      • 已提交的分支专属变更:
        git diff --name-status "$(git merge-base HEAD main)"...HEAD
      • 所有工作区变更:
        git status --short

Selection Mode

选择模式

  • Changed-only mode (default):
    • only organize candidate functions touched on the current branch
    • candidate functions are newly added, renamed, or changed visibility (
      def
      <->
      defp
      )
    • place candidate functions using this skill's ordering rules (see Ordering Rules below), not ad hoc file habits
    • do not keep candidate functions anchored near the edit area if that conflicts with proper placement
    • do not move untouched function definitions, even if out of order
  • Override mode (explicit request only):
    • organize all functions in the selected scope, including unchanged definitions
  • 仅变更模式(默认):
    • 仅整理当前分支中被修改的候选函数
    • 候选函数包括新增、重命名或可见性变更的函数(
      def
      <->
      defp
    • 根据本技能的排序规则(见下方排序规则)放置候选函数,而非遵循文件的临时习惯
    • 如果与正确放置位置冲突,不要将候选函数固定在编辑区域附近
    • 即使顺序混乱,也不要移动未被修改的函数定义
  • 覆盖模式(仅显式请求时使用):
    • 整理所选范围内的所有函数,包括未变更的定义

Precedence over file conventions

优先于文件约定

  • These rules outrank local or file-specific habits. If the file clusters related helpers together, keeps private functions near their call sites, or otherwise departs from the ordering below, still place candidate (changed) functions according to this skill.
  • Do not preserve a one-off layout for edited code when it conflicts with Ordering Rules (for example, grouping related functions out of typical order). Correct placement for touched definitions takes priority over "staying consistent" with a non-standard arrangement elsewhere in the file.
  • In changed-only mode, leave untouched definitions where they are even when the file mixes styles; only moved candidates must follow this skill end-to-end.
  • 这些规则优先级高于本地或特定文件的习惯。 如果文件将相关辅助函数归为一组、将私有函数放在其调用位置附近,或偏离以下排序规则,仍需根据本技能放置候选(已变更)函数
  • 当编辑代码的临时布局与排序规则冲突时(例如,将相关函数按非典型顺序分组),不要保留该布局。已修改定义的正确放置优先级高于与文件中其他非标准布局“保持一致”。
  • 在仅变更模式下,即使文件混合了多种风格,未被修改的定义仍保持原位;只有被移动的候选函数必须完全遵循本技能的规则。

Ordering Rules

排序规则

  • LiveView modules:
    • use this default callback order:
      mount/3
      ,
      handle_params/3
      ,
      handle_event/3
      ,
      handle_info/2
      ,
      handle_async/3
      (and other handlers), then
      render/1
    • keep callback groups contiguous, especially
      handle_event/3
      ,
      handle_info/2
      , and
      handle_async/3
    • order
      handle_event/3
      clauses alphabetically by event name
    • if
      render/1
      is not defined in the module (for example, template-backed LiveViews), skip render-ordering rules
    • private functions last (
      defp
      ), sorted alphabetically by function name
  • LiveComponent modules:
    • use this default callback order:
      mount/1
      ,
      update/2
      ,
      handle_event/3
      ,
      handle_info/2
      ,
      handle_async/3
      (and other handlers), then
      render/1
    • keep callback groups contiguous, especially
      update/2
      and
      handle_event/3
    • order
      handle_event/3
      clauses alphabetically by event name
    • private functions last (
      defp
      ), sorted alphabetically by function name
  • Non-LiveView modules:
    • public functions first (
      def
      ), sorted alphabetically by function name
    • private functions last (
      defp
      ), sorted alphabetically by function name
  • Test modules:
    • order
      test
      blocks so the happy path (success) case comes first for a given behavior; place related error-path tests immediately after that happy path (not interleaved with other features)
    • when reordering, keep
      describe
      /
      test
      groupings consistent with this: success scenario first, then its failure/edge cases in the same cluster
    • private functions last (
      defp
      ), sorted alphabetically by function name
  • LiveView 模块:
    • 使用默认回调顺序:
      mount/3
      ,
      handle_params/3
      ,
      handle_event/3
      ,
      handle_info/2
      ,
      handle_async/3
      (及其他处理器),最后是
      render/1
    • 保持回调组连续,尤其是
      handle_event/3
      ,
      handle_info/2
      , 和
      handle_async/3
    • 按事件名称的字母顺序排列
      handle_event/3
      子句
    • 如果模块中未定义
      render/1
      (例如,基于模板的LiveViews),则跳过render排序规则
    • 私有函数最后(
      defp
      ),按函数名称的字母顺序排序
  • LiveComponent 模块:
    • 使用默认回调顺序:
      mount/1
      ,
      update/2
      ,
      handle_event/3
      ,
      handle_info/2
      ,
      handle_async/3
      (及其他处理器),最后是
      render/1
    • 保持回调组连续,尤其是
      update/2
      handle_event/3
    • 按事件名称的字母顺序排列
      handle_event/3
      子句
    • 私有函数最后(
      defp
      ),按函数名称的字母顺序排序
  • 非LiveView模块:
    • 公共函数优先(
      def
      ),按函数名称的字母顺序排序
    • 私有函数最后(
      defp
      ),按函数名称的字母顺序排序
  • 测试模块:
    • 排列
      test
      块,使特定行为的正常路径(成功)用例排在最前面;将相关的错误路径测试紧跟在该正常路径之后(不要与其他功能的测试交错)
    • 重新排序时,保持
      describe
      /
      test
      分组符合此规则:成功场景在前,然后是同一组中的失败/边缘情况
    • 私有函数最后(
      defp
      ),按函数名称的字母顺序排序

Structural Safety Rules

结构安全规则

  • Treat all clauses of the same function name and arity as one unit.
  • Preserve existing pattern-match clause order unless explicitly asked to change behavior.
  • Keep callback clause groups contiguous (for example, all
    handle_params/3
    clauses together).
  • Keep each moved function body unchanged except for location.
  • Preserve module structure, comments, spacing conventions, and non-function code.
  • 将相同函数名和元数的所有子句视为一个整体。
  • 除非明确要求更改行为,否则保留现有的模式匹配子句顺序。
  • 保持回调子句组连续(例如,所有
    handle_params/3
    子句放在一起)。
  • 除位置外,保持每个被移动函数的主体不变。
  • 保留模块结构、注释、间距约定和非函数代码。

Output Expectations

输出预期

  • Move each candidate function to its correct ordered position in the file, even when that means crossing the original change area.
  • In changed-only mode:
    • file mode: if the target file has no candidate functions, make no reordering changes
    • branch mode: skip files with no candidate functions and only modify files that need reordering
  • In override mode, organize all functions in the selected scope, even if definitions are unchanged.
  • Preserve behavior: do not make ordering changes that alter pattern matching outcomes.
  • In LiveView and LiveComponent modules, callback lifecycle order wins over alphabetical order.
  • 将每个候选函数移动到文件中正确的排序位置,即使这意味着跨越原始变更区域。
  • 在仅变更模式下:
    • 文件模式:如果目标文件没有候选函数,则不进行任何重排变更
    • 分支模式:跳过没有候选函数的文件,仅修改需要重排的文件
  • 在覆盖模式下,整理所选范围内的所有函数,即使定义未变更。
  • 保留行为:不要进行会改变模式匹配结果的排序变更。
  • 在LiveView和LiveComponent模块中,回调生命周期顺序优先于字母顺序。