概念を説明したり、アイデアを伝えたり、資金を調達したり、詳細を問いただしたり、提案書を用意したりするには、そして評価を上げてもらうための議論をする際であっても、文章を作成しなければならない。また、オープンソースプロジェクトの参加者らは、世界各地に散らばっている。彼らとしっかりした意思疎通を図りたいのであれば、理解しやすい明確なメッセージを書かなければならない。
つまり、プロフェッショナルとして仕事をしたい、あるいは重要な何かを成し遂げたいというのであれば、プログラミング言語だけでなく、人間が意思疎通に使う国語の能力が必要となるわけだ。
＃5：ソースコードのフォーマットが統一されていない
既に気付いている方もいるかもしれないが、ここでのテーマはソースコードを理解しやすくするというものだ。ソースコードのメンテナンスは、膨大な時間を必要とする、コストのかかる作業だ。また率直に言って、面白い作業でもない。何週間もかけて古いソースコードと格闘し、自ら（または元々のソースコードの執筆者）がやろうとしていたことを再発見するよりも、新機能を追加するために生産的な時間を費やせる方がうれしいはずだ。
筆者も、過去に自らが開発したソースコードだけでなく、他人のソースコードでもそのことを実感した経験がある。筆者はサイドプロジェクトとして、遺棄されていたWordPressのオープンソースプラグインを引き受けてきている。ちなみに、筆者は誰よりも多くのプラグインを引き受けてきているはずだ（この件については「WordCamp 2016」で4月17日に語っている）。こういった各プラグインは元々、他の人が開発したものであり、動作させ続けるためには見知らぬソースコードに目を通す必要があった。
幸いなことに、これらプラグインの開発者たちは素晴らしいプログラミング技芸の持ち主だった。そうでなければ、プロジェクトを引き受けようとは思わなかっただろう。とは言うものの、軌道に乗るまでが大変だった。ソースコードのフォーマットが統一されていない場合、どれだけ理解が妨げられるのか、想像できるだろうか？
筆者は、ソースコードの構造、すなわちソースコードのレイアウトを明確にするというテーマの動画を公開している。視聴していただければ、筆者の言わんとすることは分かってもらえるはずだ。
オンライン上で何らかの記事を読む場合を想像してほしい。きちんとフォーマットされ、段落間の行間が広くとられ、統一がとれている記事もある一方で、すべてが巨大なデータの塊として配置され、読まれることを拒否している記事もあるだろう。
あらゆるプログラマー（また、あらゆるプロジェクト）は、何らかのプログラミングスタイルを有している。そのスタイルに整合性があれば、どのようなものであるのかは、さして重要ではない。ソースコードのフォーマットを指針にすれば活用できるはずだ。
例えば、筆者はソースコードのセクション間に複数の空行を配置しないようにしている。このため、空行が何行も連続している場合、何かまずい点が存在しており、その部分にバグがあるかもしれないということをすぐさま察知できる。
ソースコードを読み進める際には、組織レベルでコーディングスタイルが確立されているかどうかを確認してほしい。そして場合によっては、すべてのプログラマーが活用できる、明確でメンテナンス性を醸成できるようなコーディングスタイルの定義を検討してほしい。
