RDocのコードフォーマット記法を修正

rails/rails

ActionView::Helpers::TextHelperのドキュメントで、+String#sub+という記述が正しくレンダリングされない問題を修正しました。RDocの記法ルールに従い、<tt>String#sub</tt>に変更することで、APIドキュメントの表示が正常化されます。

背景

RDocでは、インラインコードのマークアップに+code+<tt>code</tt>の2つの記法が使用できます。しかし、+記法は単純な識別子にのみ有効で、String#subのようにシャープ記号を含むメソッド参照では機能しません。この制約により、Rails Edge APIドキュメントのTextHelper#highlightのページで、:highlighterオプションの説明文が意図した形式で表示されていませんでした。

RDocパーサーは+String#sub+を正しく解釈できず、コードとして認識されないままプレーンテキストとして出力されていました。

技術的な変更

actionview/lib/action_view/helpers/text_helper.rbhighlightメソッドのドキュメントコメントを修正しました。

変更前:

# [+:highlighter+]
#   The highlighter string. Uses <tt>\1</tt> as the placeholder for a
#   phrase, similar to +String#sub+. Defaults to <tt>"<mark>\1</mark>"</tt>.
#   This option is ignored if a block is specified.

変更後:

# [+:highlighter+]
#   The highlighter string. Uses <tt>\1</tt> as the placeholder for a
#   phrase, similar to <tt>String#sub</tt>. Defaults to <tt>"<mark>\1</mark>"</tt>.
#   This option is ignored if a block is specified.

+String#sub+<tt>String#sub</tt>に置き換えることで、RDocパーサーが確実にコードとして認識し、適切なフォーマットで出力されるようになります。同じ文中の<tt>\1</tt><tt>"<mark>\1</mark>"</tt>と記法を統一することで、ドキュメントの一貫性も向上しています。

設計判断

<tt>タグによる明示的なマークアップが選択されました。

RDocの+記法はシンプルですが、適用範囲に制約があります。一方、<tt>タグはHTMLタグベースの記法であり、より複雑な構文を確実にマークアップできます。PRの説明にある通り、「The simple + style doesn't work with more complicated snippets」という実用上の判断から、確実性を重視した記法への統一が行われています。

同一の説明文内で複数のコード断片が存在する場合、すべて同じマークアップ記法で統一することで、ドキュメント生成の予測可能性が高まります。

まとめ

本PRは、RDocのマークアップ記法の制約に対処するための1文字の修正です。+から<tt>への変更により、メソッド参照を含む複雑なコード断片が正しくレンダリングされるようになり、Rails APIドキュメントの品質が向上します。

記事メタデータ

Generated by:
Claude Sonnet 4.5 for DiffDaily

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ PASS

Title, Context, Technical Detailの存在と明確さ

リード文(総論)→背景・技術詳細・設計判断(各論)→まとめ(結論)という「総論→各論→結論」の構成が明確に適用されており、非常に分かりやすいです。

カスタムMarkdown構文 ⚠ WARNING

シンタックスハイライト・GitHubリンク記法の正確性

ファイル名付きシンタックスハイライトは正しく使用されています。しかし、フッターのPRリンク記法がガイドラインの推奨形式([#123](URL))と若干異なります。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

RDocの記法という専門的なトピックを、過度な初心者向け解説なしに簡潔に説明しており、対象読者であるエンジニアに適した内容です。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクションが総論→各論の構成になっており、各段落もトピックセンテンスで始まるなど、パラグラフ・ライティングの原則が守られています。これにより、記事の骨子が掴みやすくなっています。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事内のコードブロックは、提供されたDiffの内容を正確に反映しており、ファイルパスも一致しています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

「RDoc」「<tt>タグ」「String#sub」など、使用されている技術用語はすべて正確で、文脈に適しています。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

「+記法が複雑なスニペットで機能しない」というPRの記述に基づき、技術的な制約を正確に説明できています。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

記事内のすべての主張は、PRのDescriptionやDiffの内容によって裏付けられており、ハルシネーション(捏造)は見られません。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号(#56763)やその他の固有名詞(ActionView::Helpers::TextHelperなど)はすべて正確に記載されています。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事のタイトル「RDocのコードフォーマット記法を修正」は、PRのタイトル「Fix rdoc code formatting」と内容を正確に反映しています。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

PR情報に記載のないバージョン情報やリリース予定などの外部知識は含まれておらず、事実に基づいた記述が徹底されています。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

PRの文脈(修正前のエラーが見られる状態)を「表示されていませんでした」と過去形で表現するなど、時間表現は正確です。