bash イディオム

第11章 スタイルガイド スタイルガイドを作成する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

本書の包括的なテーマは、一貫したスタイルで慣用的でありながら読みやすいbashコードを書くことであり、そのために必要なツールを提供できたと思う。 スタイルとは、"どのように書くか "を表す別の言い方に過ぎない。 スタイルのガイドラインを発見し、それを書き留め、それを守ることだ。 本書では、スタイルに関する重要な事柄をいくつか取り上げてきたが、その他にも、システムを設計したりコードを書いたりする際に留意すべきガイドラインがいくつかある。 この章を自分のスタイル・ガイドの出発点として使ってもいいし、気に入ったらそのまま採用してもいい。 付録は、「カンニングペーパー」として使うための、論点を除いた同じ内容で、本書のGitHubページからMarkdownまたはHTMLコードを入手できる。

以下のハイレベルな原則に留意すること：

• 何よりも：KISS-シンプルに、愚かに！ 複雑さはセキュリティの敵である、¹しかし、読みやすさと理解の敵でもある。 もちろん、現代のシステムや状況は複雑なので、これ以上悪化させないように努力しよう。

• ブライアン・カーニガンが言った有名な言葉だが、デバッグはコードを書くことの2倍難しいということだ。

• 車輪の再発明をしないようにしよう。 あなたがやろうとしていることは、おそらく以前にも行われてきたことだろうし、そのためのツールやライブラリがあるはずだ。 そのツールがすでにインストールされているなら、それを使えばいい。 どんなに頑張っても、rsync に費やされた労力とテストにはかなわない。 インターネットで適当なコードを発見したら......ちょっと考えてみてほしい。

• 、特殊なケースやオーバーライドが発生する可能性があるため、前もって計画を立てておくこと。 Linux分散パッケージシステムを見習って、デフォルトの/etc/thing/global.cfg 、やみくもに上書きできるようにし、/etc/thing/config.d/ などで上書きできるようにする。ドロップイン・ディレクトリ」を参照のこと。

• リビジョン管理されていなければ、それは存在しない！ (そして遅かれ早かれ、それは失われ、そして本当に存在しなくなる）。

• すべてを文書化する。 (しかし、それについて本を書く必要はない...ああ、待てよ...）1年後、なぜ そのようにしたのか忘れてしまったときにチームに加わる新しい人のために、コード、コメント、ドキュメントを書こう。 何がうまくいかなかったのか、なぜうまくいかなかったのかを文書化し、相互参照すること。 (そう、rm -rf /$undefined_variable 、本当に悪い考えだと判明したのだ！)

• コードとドキュメントをDRYに保つ：同じことを繰り返さない。 コピーを複数持つようになれば、遅かれ早かれ同期が取れなくなることは確実だ。 関数やライブラリを使おう。WET（We Enjoy Typing）にはなるな。

"Pythonの禅 "はほとんどbashにも当てはまる。 python -c "import this" を試してみるか、Pythonのドキュメントを見てみよう。

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

このbashイディオムスタイルガイドはbash専用なので、POSIX、Bourne、Dash、その他のシェルには移植できない。 ...