bash イディオム

付録 bashイディオムスタイルガイド

これは 、第11章の点をコピーしたものだが、解説や例は含まれていない。 examplesディレクトリにMarkdownファイルもあるので、ダウンロードして好きなように調整し、pandoc や他のツールを使って必要に応じてレンダリングしたりインクルードしたりできる。 コードは本のGitHubページから入手できる。

bashイディオムスタイルガイドはポータブルではない

このbashイディオムスタイルガイドはbash専用なので、POSIX、Bourne、Dash、その他のシェルには移植できない。 これらのシェル用に書く必要がある場合は、それらのシェルでサポートされている構文や機能を考慮して、このガイドをテストして調整する必要がある。

Dockerなどのコンテナでは、/bin/sh がbashではなく、/bin/bash も存在しない可能性があるので、特に注意が必要だ！ これは、モノのインターネットや、産業用コントローラなどの制約のある環境に当てはまる。 コンテナにおけるbash」と「Shebang!

読みやすさ

コードの読みやすさは重要だ！ Pythonが言うように、読みやすさはカウントされる。 あなたは一度しか書かないが、あなた（や他の人）はおそらく何度も読み返すだろう。 来年、そのコードを読もうとしている哀れな無知な人のことを考えて、余分な数秒か数分を費やそう。 抽象化（Don't Repeat Yourself）と読みやすさの間にはバランスと緊張がある：

• KISS（Keep It Simple, Stupid!）

• 読みやすさ：「賢い」のではなく、「明確」であること。

• 良い名前付けは重要だ！

• 常にヘッダを使う。

• 可能な限り、-h 、--help 、引数が正しくない場合に有用な何かを発する！

  • エコー行の束よりも、"here "ドキュメント（先頭タブ付き）を使う方が、更新するときの摩擦が少ないし、おそらく後で再ラップする必要があるからだ。

• 設定ファイルをインクルードするには、.cfg （または.conf 、またはあなたの標準が何であれ）で終わるように、source （. の代わりに、見過ごしやすく、検索しにくい）を使用する。

• 可能な限り、すべてのものにISO-8601の日付を使用する。

• 重複を防ぎ、項目の追加や削除を容易にする。例としては、IPアドレス(GNUsort -V を使用)、ホスト名、インストー ルするパッケージ、case 文、変数や配列/リストの内容な どがある。

• 例えば、diff -q の代わりにdiff --quiet を使うなどである。ただし、GNU/Linux 以外のシステムへの移植性に注意すること。

  • オプションが短かったり、わかりにくかったりする場合は、コメントを追加すること。

  • なぜそのオプションを選んだのか、あるいは必要だったのか、また、検討したが何らかの理由で使わなかったオプションについても、文書化することを強く検討する。

  • 良いアイデアのように見えるが、実際には問題を引き起こす可能性のあるオプションは、特に他の場所でよく使用する場合は、必ず文書化すること。

コメント

• 常にヘッダを使う。

• 1年後、新しくチームに加わる人へのコメントを書く。

• 関数をコメントする。

• 何をしたかについてコメントしてはいけない。なぜ何かをしたのか、あるいはしなかったのかについてコメントする。

  • 例外：bash自体が曖昧な場合、何をしたかコメントする。 ...