diff > Link > 行内の変更箇所が色強調されるツール / 改行を好まない理由

関連
http://qiita.com/Mura-Mi/items/7fed2867e072f16110b8

ツール

行内の変更箇所だけ色付けが強調されるツールもある。例として、TFS (Visual Studio 2012)。

ファイル比較だけの場合、以下にツールの候補があがっている。
http://unix.stackexchange.com/questions/11128/diff-within-a-line

vimdiffあたりなど変更箇所が分かりやすい。

ただ、gitなどのバージョン履歴にて使うには別途工夫がいるかもしれない。

(追記)
@okzk さんの記事でgitにあることが記載されていた。
http://qiita.com/okzk/items/9756ac2827e78b9beca5

改行を好まない理由

コードに改行を入れた場合、エディタの検索結果が読みにくくなり、ソースリーディングがしにくくなる。
いくつかのエディタでは検索時に検索キーワードを含む１行(＋設定による前後数行)を検索結果窓に表示する。

例として、:nameで検索した結果

改行なし検索結果

params.require[:model].permit(:id, :name, :address, :postal, :score)
params.require[:model].permit(:id, :name, :address, :postal, :score)
params.require[:model].doit(:id, :name, :address, :postal, :score)
params.require[:model].permit(:id, :name, :address, :postal, :score)
params.require[:model].replace(:id, :name, :address, :postal, :score)

改行あり検索結果

                                    :name,
                                    :name,
                                    :name,
                                    :name,
                                    :name,

改行なしの場合は、:nameパラメータがどういう関数で使われているかが一見できる。改行ありの場合は、検索結果の先を開いて見ないと理解できない。

一方で、「変更箇所を明白にしてdiffを読む人が変更箇所を理解しやすく」という意図に賛成する。

「行を分ける．」の例１に賛成する。複数のincludeを１行にまとめる必然性がないと感じているから。
「行を分ける．」の例２には上記の理由から賛成しかねる。

SourceTreeのUIやgithubのwebブラウザUI, bitbucketのwebブラウザUIなどで標準的に行内の変更箇所だけの色づけがされるようになればいいと思う。