コマンドラインインターフェースガイドライン

コマンドラインインターフェースガイドライン 従来のUNIXの原則を取り入れ、現代向けにアップデートした、より優れたコマンドラインプログラムを作成するためのオープンソースガイド。 著者 Aanand Prasad Squarespaceのエンジニア、Docker Composeの共同制作者。 @aanandprasad Ben Firshman Replicateの共同創業者、Docker Composeの共同制作者。 @bfirsh Carl Tashian Offroadのエンジニア、Zipcarの最初のエンジニア、Troveの共同創業者。 tashian.com @tashian Eva Parish Squarespaceのテクニカルライター、O'Reillyの寄稿者。 evaparish.com @evpari デザイン：Mark Hurrell。 初期の貢献をしてくれたAndreas Jansson、ドラフトのレビューをしてくれたAndrew Reitz、Ashley Williams、Brendan Falk、Chester Ramey、Dj Walker-Morgan、Jacob Maine、James Coglan、Michael Dwan、Steve Klabnikに感謝します。 ガイドやCLIデザインについて議論したい場合は、Discordにご参加ください。 まえがき 1980年代、パーソナルコンピュータに何かをさせたい場合、C:\> や ~$ に直面したときに何を入力すべきかを知る必要がありました。ヘルプは厚い、スパイラル綴じのマニュアルの形で提供されました。エラーメッセージは不透明でした。あなたを救うStack Overflowはありませんでした。しかし、幸運にもインターネットにアクセスできたなら、あなたと同じようにフラストレーションを感じている他の人々でいっぱいの初期のインターネットコミュニティであるUsenetから助けを得ることができました。彼らはあなたの問題を解決するのを助けるか、少なくともいくらかの道徳的なサポートと仲間意識を提供してくれました。 40年後、コンピュータは、低レベルのエンドユーザーコントロールを犠牲にして、すべての人にとってよりアクセスしやすくなりました。多くのデバイスでは、壁に囲まれた庭やアプリストアといった企業の利益に反するため、コマンドラインへのアクセスがまったくありません。ほとんどの人は今日、コマンドラインが何であるかを知りませんし、ましてやなぜそれにこだわる必要があるのかも知りません。 コンピューティングのパイオニアであるAlan Kayは2017年のインタビューで、「人々はコンピューティングが何であるかを理解していないため、iPhoneにそれがあると思っています。そしてその幻想は、『ギターヒーロー』が本物のギターと同じであるという幻想と同じくらい悪いのです」と述べています。 Kayの「本物のギター」はCLIではありません。正確には。彼は、CLIのパワーを提供し、テキストファイルでソフトウェアを書くことを超えるコンピューティングの方法について話していました。 Kayの弟子たちの間には、数十年間住んできたテキストベースの局所的極大値から抜け出す必要があるという信念があります。コンピューターを非常に異なる方法でプログラムする未来を想像するのはエキサイティングです。今日でさえ、スプレッドシートは圧倒的に最も人気のあるプログラミング言語であり、ノコード運動は、才能あるプログラマーへの激しい需要の一部を置き換えようとして、急速に勢いを増しています。 しかし、その古びた、数十年前の制約と説明不能な奇妙さにもかかわらず、コマンドラインは依然としてコンピュータの最も汎用的なコーナーです。それは、カーテンをめくり、何が本当に起こっているのかを見て、GUIでは得られない洗練された深さでマシンと創造的に対話することを可能にします。それは、それを学びたい人なら誰でも、ほぼすべてのラップトップで利用できます。インタラクティブに使用することも、自動化することもできます。そして、システムの他の部分ほど速く変化しません。その安定性には創造的な価値があります。 したがって、まだそれがある間は、その有用性とアクセシビリティを最大化すべきです。 それらの初期の日以来、コンピューターのプログラムの方法は大きく変わりました。過去のコマンドラインはマシンファーストでした。スクリプトプラットフォームの上に載ったREPLに過ぎませんでした。しかし、汎用的なインタプリタ言語が繁栄するにつれて、シェルスクリプトの役割は縮小しました。今日のコマンドラインはヒューマンファーストです。あらゆる種類のツール、システム、プラットフォームへのアクセスを提供するテキストベースのUIです。 過去には、エディタはターミナルの内部にありました。今日では、ターミナルはエディタの機能として同様によく使われます。そして、gitのようなマルチツールコマンドの増加が見られます。コマンド内のコマンド、そしてアトミックな機能ではなく、ワークフロー全体を実行する高レベルコマンド。 伝統的なUNIX哲学に触発され、より楽しくアクセスしやすいCLI環境を奨励することへの関心に駆られ、そしてプログラマーとしての私たちの経験に導かれて、私たちはコマンドラインプログラムを構築するためのベストプラクティスと設計原則を再検討する時が来たと判断しました。 コマンドラインよ永遠なれ！ はじめに このドキュメントは、高レベルの設計哲学と具体的なガイドラインの両方をカバーしています。実践者としての私たちの哲学は、あまり哲学しすぎないことなので、ガイドラインに重点を置いています。私たちは例から学ぶことを信じているので、それらをたくさん提供しました。 このガイドは、emacsやvimのようなフルスクリーンターミナルプログラムをカバーしていません。フルスクリーンプログラムはニッチなプロジェクトです。私たちのごくわずかな人しか、それらを設計する立場にはなりません。 このガイドは、プログラミング言語やツール全般についても中立です。 このガイドは誰のためのものですか？ CLIプログラムを作成していて、そのUIデザインのための原則と具体的なベストプラクティスを探しているなら、このガイドはあなたのためです。 あなたがプロの「CLI UIデザイナー」なら、それは素晴らしいです。私たちはあなたから学びたいです。 40年間のCLIデザインの慣習に反するような、明白なミスを避けたいなら、このガイドはあなたのためです。 プログラムの良いデザインと役立つヘルプで人々を喜ばせたいなら、このガイドは間違いなくあなたのためです。 GUIプログラムを作成しているなら、このガイドはあなたのためではありません。それでも読むことにした場合、GUIのアンチパターンについて学ぶことができるかもしれません。 Minecraftの没入型フルスクリーンCLIポートを設計しているなら、このガイドはあなたのためではありません。（しかし、それを見るのが待ちきれません！） 哲学 これらは、私たちが良いCLIデザインの基本原則と考えるものです。 人間中心のデザイン 伝統的に、UNIXコマンドは、主に他のプログラムによって使用されることを前提に書かれていました。それらは、グラフィカルアプリケーションよりもプログラミング言語の関数と共通点が多くありました。今日、多くのCLIプログラムは主に（あるいは排他的に）人間によって使用されていますが、そのインタラクションデザインの多くは、過去の遺産を引き継いでいます。この遺産を捨てる時が来ました。コマンドが主に人間によって使用されるのであれば、それはまず人間向けに設計されるべきです。 機能する単純な部品の組み合わせ オリジナルのUNIX哲学の核となる教義は、クリーンなインターフェースを持つ小さくて単純なプログラムを組み合わせてより大きなシステムを構築できるという考え方です。それらのプログラムにますます多くの機能を追加するのではなく、必要に応じて再構成できるモジュール式のプログラムを作成します。 昔は、パイプとシェルスクリプトがプログラムを一緒に構成するプロセスで重要な役割を果たしました。汎用的なインタプリタ言語の台頭により、その役割は縮小したかもしれませんが、決して消滅したわけではありません。 さらに、CI/CD、オーケストレーション、構成管理の形での大規模な自動化が盛んになりました。プログラムをコンポーズ可能にすることは、これまで以上に重要です。 幸いなことに、この目的のために設計されたUNIX環境の長年の確立された慣習は、今日でも私たちを助けてくれます。 標準入力/出力/エラー、シグナル、終了コードなどのメカニズムにより、異なるプログラムがうまく連携します。プレーンな行ベースのテキストは、コマンド間で簡単にパイプできます。JSONは、はるかに最近の発明であり、必要な場合に構造を提供し、コマンドラインツールをWebとより簡単に統合できるようにします。 あなたが構築しているソフトウェアが何であれ、人々はあなたが予期しなかった方法でそれを使用することを絶対に確信できます。あなたのソフトウェアはより大きなシステムの一部になります。あなたの唯一の選択肢は、それがうまく振る舞う一部になるかどうかです。 最も重要なのは、コンポーズ可能性のために設計することが、人間中心のデザインと対立する必要はないということです。このドキュメントの多くのアドバイスは、両方を達成する方法についてです。 プログラム間の一貫性 ターミナルの慣習は私たちの指にハードワイヤードされています。コマンドラインの構文、フラグ、環境変数などを学ぶことで、初期費用を支払いましたが、それは長期的な効率に報います...プログラムが一貫している限り。