OS全体がこれらのソースファイルを中心に構築されてるんだよね。一方で、Unixの哲学は「プレーンテキスト」を解析するコードが組み込まれたツールが設計されて初めて「繁栄」するんだ。

その通り。こういうアイデアは何度も出てくるけど、コストと利益が全然合わないんだよね。シンプルなフォーマッターを使うのを避けるために、信じられないほど複雑なツールを追加してるだけだし。全ての開発者が自分の好みでコードを見れることなんて、そんなに重要じゃないと思う。私が関わったチームでは、標準のスタイルガイドを使って、フォーマッターで強制してるけど、全員が全てのルールに同意するわけじゃない。それでも、慣れちゃうんだよね。コードのフォーマットについて議論したりこだわったりするのは、単なる無駄なバイクシェディングだと思う。

もし共通の中間エンコーディングがテキストで、バイナリじゃなかったらどうなる？そうすればgrepやdiff、sedはまだ使えるよね。ASTに基づいて動作するフォーマッティングツールがあれば、チェックインされたコードは特定のASTのための標準的な形式にできる。エディタはASTを解析して、ユーザーの選択した異なるフォーマットでソースを表示し、ファイルをディスクに書き込むときに標準形式に変換できるんだ。

DIANA irから元のソースコードみたいな形に戻すことってできるの？その逆変換の結果をgrepしたりできるし…

ソースを標準フォーマットで保存して、各開発者に合わせて unpack するなら…なんで標準フォーマットが普通のソースコードでなきゃいけないの？全てのツールはテキストバックエンドでも存在できるし、grepやsedのサポートもタダでついてくるよ！

もし初期のスペース幅が好きなエディタで設定できるなら、タブを好む人たちは他に何か意見があるのかな？もちろんあるよ。だってタブ幅は動的に柔軟だから、初期のスペース幅だけじゃ足りないんだ。

Grepやdiff、sed、行ベースの非セマンティックマージは、コードを操作するにはひどいツールだよ… それらでさらに深みにハマるより、何かもっと良いものを考える理由があった方がいいかもね。

これが機能するイメージは、gitフィルターみたいな感じだね。バージョン管理からチェックアウトすると、好みのフォーマットでテキストに変換されて、それを期待通りに扱うことができる。ステージングすると、保存された表現に変換される。gitでは、これはsmudgeとcleanフィルターを使って行われる、git LFSのようにね。フォージやその類のためのビューアもあって、必要に応じて保存された表現を解釈するように作られてる。テキストで作業するけど、そのテキストは標準の保存表現じゃない。構造が変わった時だけdiffが出てくる。事前コミットのリンターフックでもほとんど同じメリットが得られるけどね。

テキスト以外のものは、grepやdiff、sed、バージョン管理をあまり効果的にしないよね。UNIXの設計ミスかもしれないけど、テキストにこだわりすぎてる気がする。

テキストは確かに重要なポイントだけど、私たちが短期的な視野で谷に入ることを避けているせいで、ローカルな問題にハマっていると思う。あなたの例は構造的な知識があるコードに対してはうまく機能するよね：- grep: シンボル検索（テキストのgrepより100倍使ってる）や https://github.com/ast-grep/ast-grep - diff: https://semanticdiff.com（他にもいろいろ）、つまり：ノイズの多い構文の変更を隠して、移動したコードを捉えようとする。投影プログラミングがあれば、コードが移動することの表現力がもっと高くなると思う。- sed: https://npmjs.com/package/@codemod/cli - バージョン管理：Unisonのような言語を見て、ここでできる面白いことを探るのがいいと思う。特にライブラリに関しては。一般的な例としては、非意味的な変更（順序の変更や無関係な空白など）による競合がないこと。

その例にはあまり納得できないな。> 私たちの中には、他のコードの部分を揃える人もいるし、繰り返しのインラインコメントもそうだよね。> さて、引数のブロックは三列のテーブルを形成してる。修飾子が第一列、データ型が第二列、名前が第三列に揃ってる。これって、コードフォーマットでカバーできるかなり些細なルーチンに感じる。forループみたいなもっと極端な例を考えることもできるけど、そんな超カスタムフォーマット（「組版」）は、いつも私を気まずくさせるし、みんなが好き勝手なフォーマットを使う理由を与えちゃう気がする。著者には意図があるけど、一貫性のないコードにぶつかると、変動が情報的でも役立つわけでもない。単に面倒で、疲れるだけだよ。保存されているものはおそらくもっとミニマルで、何らかの参照エンコーディング、もしかしたらjs用の見栄えを良くするものかもしれない。この文章の本質は、そんなことはどうでもいいってことだと思う。IDEは自分の好きなように表示・編集できるべきだよね。> みんなが自分の好きなように見るためのプリティプリント設定を持ってたんだ。

そうなんだよね！みんなそれが見えないのが信じられない。

Cの引数宣言は修飾子（register, const）、データ型（char ）、名前（from）で構成されてるんだ。じゃあ「char argv[]」みたいな宣言を説明してみて… > それに加えて、データ型のスペースをcharとの間に入れないように再設定したんだ。この2つの変数のデータ型は「charへのポインタ」だから、引数名の前にスペースを置く方が理にかなってるよね（追記：これは単一の宣言にだけ意味があるってことは指摘しておくべきだね。char a, bみたいな構文は、charへのポインタaと通常のchar bを作ることになる）。ああ、そうだ、妄想的なC++のフォーマットスタイルね。少なくとも、更新でそれを避ける理由が説明されてるのは良いことだね。

そうだね。Pythonでは、blackフォーマッターがSQLAlchemyのクエリを読みにくい形で常に壊しちゃう（例えば、条件を必要以上に複数行に分けて、読みにくくする）。

それに、タイポグラファーはテーブルや数式を整えるために、全てを揃えて適切な間隔を保つために本当に努力してるんだよね。何世紀も手作業でやってきたのは、それが重要だから。外部の人には気づかれないことも多いけどね。（とはいえ、ソースコード用のもっと洗練されたフォーマッターを作ることもできるはず。）

タイポグラフィに気を使うのはいいけど、疑わしいプログラミング言語の慣習に盲目的に従うのは、本当に間違ったスタート地点に努力を注いでいるように感じる。そんなに意図を隠すことに意味があるの？最初の例を見てみよう。char * strcpy(to, from) register char *to; register const char *from; { char *save = to; for (; (*to = *from) != 0; ++from, ++to); return(save); } "長ったらしい" registerが許されるなら、なぜ全単語で文字を使わないの？それとも、もっと短いものが欲しいなら、signの方が一般的に意味的に合ってるよね。ポインタを設計するのに星を使うのはどうなの？sign-pointerにしてもいいし、もっとストレートなメタファーを使うならpinでもいい。ああ、ちなみに「ドット」(.)や「ダッシュ、グレーターザン」(->)を使うのは、タイポグラフィ的に全く意味がないよ。charはsign-pin-pinと比べて可読性を何ももたらさない。ほとんどの人は言葉や言葉の連なりを全体として読むからね。charをsign-pin-back-5と比べてみよう。strcpyはどうする？この文字列の山をデコードできることで賢く見せようとするの？string·copyやstringcopy（photocopyと比較して）でいいじゃん。あるいは単にcopyでも。冗長な識別子を避けたいなら、英語には同義語が豊富にあるよ。例えばduplicate、replicate、reproduce。さまざまな括弧は、適切なタイポグラフィがすでに整っているなら、オプションにしてもいいし、英語にはそれを置き換えたり補完したりできる副詞や前置詞がたくさんある。前置詞について言えば、物事を名詞で表現する方が適切なのに、fromやtoを識別子として使うのは本当に混乱を招く選択だよね。origin/sourceやdestination/targetの方がいいじゃん。識別子は興味の主なポイントなのに、その宣言文の最後に置くのはちょっと逆効果だよね。代入のための=も、←や≔のようなもっと関連性のある記号のアーティファクトに過ぎない。ほとんどのキーボードレイアウトはひどいデザインから来てるから。もっと適切な記号を使うことは、本当に不必要に曖昧な表記を推進することになる。文を終えるための必須セミコロンも、明らかにタイポグラフィ的に意味がないよ。forでパラメータを空白にするなら、何かを強調する方法よりも、別の制御フロー構文の方が明らかに良いと思う。すべてをまとめると：duplicateを関数として ⟨ requiring ( origin as sign-pin-register, destination as sign-pin-register ) making { save as sign-pin save assigned origin destination-pin assigned origin-pin until ( zeroized, whilst [ origin-increment, destination-increment wrought ] done ) return save made } built ⟩ こういう場合、括弧やコンマは純粋に装飾的なもので、コンパイラはそれらを無視しても十分な情報を持つことができる。例えば、duplicateを関数として requiring origin as sign-pin-register destination as sign-pin-register making save as sign-pin save assigned origin destination-pin assigned origin-pin until zeroized whilst origin-increment destination-increment wrought done return save made built とか、あるいは duplicateを関数として requiring origin as sign-pin-register destination as sign-pin-register making save as sign-pin save assigned origin destination-pin assigned origin-pin until zeroized whilst origin-increment destination-increment wrought done return save made built でもいい。

理論上は、人間が自動フォーマッターよりも良い仕事をすることができるけど、実際には全然そうじゃないから、その主張は無意味だね。

一般的には同意だけど、行の最大長が高すぎてコードを読むときに横スクロールしなきゃいけないのは、生産性にすごく悪影響だよ。

なんでまだコードのプレーンテキスト表現を見てるのか、全然理解できないんだよね。もっと理にかなったコードの可視化があればいいのに。私の考えでは、この可視化は自動生成されたものじゃなくて、他の人に理解してもらいたいと思っている人間が愛情を込めて作ったものなんだ。これは典型的なデザイン文書とは違って、コードの一部としてメタデータに保存されている。変数や関数の命名の延長と考えてもらえればいいよ。もちろん「リテラルプログラミング」もあるけど、なぜかそれが大きなシステムで広がらなかったんだよね。[1] https://en.wikipedia.org/wiki/Literate_programming

なんで人々がリンターの設定にそんなにこだわるのか、全然理解できない。ソースコードフォーマットプログラムは、リンタープログラムとは違うんだ。前者は、出力がレイアウトルールに従うようにソースコードファイルを書き換えるけど、既存のロジックは変更しない。後者は、通常、正しい構文の中で潜在的な実装エラーを特定するために使われる冪等のソースコード分析プログラムの一種だ。いくつかの言語ツールはフォーマットとソースコード分析の両方をサポートしているけど、これは実装の詳細なんだ。0 - https://en.wikipedia.org/wiki/Lint_(software)

特定の保持オプションにはあんまりこだわってないけど（自分の好みが宇宙の中で最高だってのは確かだけど）、共通のリント設定がないと、毎回のPRでノイズが発生するのは避けたい。そう、gitもこれらのプログラミング言語も、アダのようにもっとエレガントに行を扱うべきなのに、ただのテキストとして扱うのは本当に馬鹿だと思う。20年以上のキャリアの中で、アダを使ったプロジェクトに提案されたのはたった一度だけ。エレガントで効率的なものを作るのは難しいし、世界的にトップクラスの存在感を持たせるのはもっと難しい。すでに良いものが揃っているエコロジカルニッチでは特にね。

一部の設定には利点があるよね。例えば、テーブルの末尾にカンマを付ける設定 [ 'apple', 'banana', 'orange', ] は、 [ 'apple', 'banana', 'orange' ] よりも利点がある。なぜなら、テーブルの最後に新しい行を追加する時、(1) 1行の編集で済むし、(2) コードレビューの差分が小さくて読みやすくなるから。だから、悪い選択は私の生活を難しくするんだ。同じことがローカル変数の宣言にも当てはまる。ソートされたリスト（またはソートされたインクルード）は、私の生活を楽にしてくれるものだよ。もしソートされていなかったら、みんなが新しいものを最後に追加することになるから、マージコンフリクトが何倍も増える。ソートされているからといってゼロになるわけじゃないけど、「最後に追加する」よりは少なくなる。だから、自動フォーマッターが時間を節約するためにあるように、可能な限りソートしないことで私の時間を無駄にしないでほしい。あと、私のOCDは不一致が大嫌いなんだ。[1, 2, 3] {a, b, c} はOKだけど、[ 1, 2, 3 ] [ a, b, c ] もOKだけど、[1, 2, 3] { a, b, c } はダメ。どちらでもいいから、スタイルは一つに決めて、二つにしないで！

でも（少なくとも長い間）、自動でリンターを実行する機能はなかったんだよね。Goのgofmtがそのアイデアを人々に植え付けるまでは。あの頃にはいくつかフォーマットツールはあったけど、jslintやeslintには結構ギャップがあって、残念ながらコードレビューでそれを指摘することが多かったんだ。振り返ると、ただの細かいことを言ってたなって思う。

それは明らかにバイクシェッドの話だと思うけど、自分でその質問に答えたんじゃない？ ;-)

いいリンティングルールが設定されていれば、その通りだね。99%のケースで有効なエラーやコードの匂いを見つけるのに役立つルールや、正しいことがない場合の純粋なフォーマットルールが必要だよ。リンティングが問題になるのは、意見が強くて根拠が疑わしい場合で、問題を見つけるのを助けるどころか邪魔になる時だね。リンティングルールと戦う必要はないはずなのに、残念ながらそうなることが多いんだ。俺の他のコメントも見てみて： https://news.ycombinator.com/item?id=45166670

同意するよ。リンターは現代の開発で一番イライラする部分の一つだね。関係ないことなのに、マージする時にかなりの時間を取られちゃう。多くのエディタや言語の組み合わせは、初めから自動リンティングを提供してないし、もしあってもCIパイプラインが推測するルールとは違うことが多いと思うよ。

Rustがコラボレーションに向いている理由の一つは、意見がはっきりしているから、みんなが本当の問題解決に集中できることだね。ESLintやPrettierの設定について無駄に議論するのは、時間の使い方としてはあまり良くないと思う。

フォーマットに無関心でいることは、私に次のことを示している：- おそらく1人以上の人が編集するコードベースで働いたことがない - ブランチ間でのマージをまともにやったことがない - 大きなコードベースを維持したことがない - 大きなコードベースをリファクタリングしたことがない - コードベースの履歴を読むためにdiff/比較ツールを使ったことがない - コードベースのためのツールを作ったことがない - チームプレイヤーとしては良くないし、自分のことだけにしか興味がない

ブログのエントリーは短くてシンプルだから、タイトルに反応する前に一度読んでみるといいよ。そうすれば「すべき」と「不必要」がそのタイトルでどういう意味を持つのか理解できるかもしれない。

特定のフォーマットでテキストを整えたい時ってあるよね。例えば、リストを視覚的にテーブルに変えたいとか。

もしその質問に対する答えが「絶対にノー」って状況なら、コードを保存・コミットする時に自動でフォーマットするツールを設定しちゃえばいいと思う。それに、誰かがそれをスキップしたらCIが文句を言うようにしておけば、もうそれでいいんじゃないかな。細かいことにこだわるより、デフォルトの設定のままでいいと思う。自分のスタイルを捨てて、みんなが使ってるツールでのリントやフォーマットに従った方が、コードを引き継ぐ人にとっても馴染みやすいしね。フォーマットとリントは違うけど、どちらかを設定したら、もう片方もやっちゃった方がいいかもね。

誰かのコードフォーマットって、シボレットみたいなものだと思う？フォーマッターやリントに関してどう感じてる？

同じ性格の特徴は、筆跡からもより良く評価できるから、これからは全てのPRを cursive で提出することを求めるつもりだよ。

あなたの例の後半の2行は、LoD違反の匂いがするね。フォーマットの問題じゃなくて、構造の問題だよ。

でも「望ましいコードフォーマット」って主観的だよね。2スペース、4スペース、8スペースが好きな人もいれば、あなたが示したようなカラムレイアウトが好きな人もいるし。ASTだけからフォーマットを推測するのは無理だよ。ASTはソースコードじゃないし、フォーマット情報も持ってないから。

あなたの言いたいことはわかるけど、実際には最初の2つのフォーマットしか使ったことがないし、私の目標は常に可読性だったんだ。テキストの代わりにASTを保存するのは情報が失われるけど、得られるものより失うものが価値があるのかな？もしあなたの例が失う中で一番良いものなら、やっぱりそれでも大きな勝利だと思うよ。異なる部分を強調する方法もあって、ASTへの往復でも生き残るんだ。例えば、深さを強調する方法：setValue([bar, glob], 1) や setValue([bar, plu, a1], 21) あるいはデータを強調する方法：configure(bar, 1, 21, fol)。それに、もし本当にこのスタイルを維持したいなら、スタイルのオーバーライドを許可することもできるよ：// $formatblk: tabular_keypaths, aligned_assignments bar .glob = 1 bar .plu .a1 = 21 // $formatblk-end