プログラミング言語Rustでのチームでのソースコードの統一感について（チームでのコードスタイルのばらつきを抑え、コードの品質を担保し、あとでコードが読めなくなってしまった場合の、技術的負債と化すことを防ぐ）

Slackにて
ありがとう御座います。
https://rust-jp.slack.com/archives/C8FLSR5F1/p1581424953112100
勉強の為に転載（シェア）しました。

石塚　正浩  9:42 PM
以前は、Golangが一番チームでの開発性と統一感を出すのに優れていると思いましたが、Rustはチームでの開発時の統一感など、はいかがでしょうか？出しやすいでしょうか？

ペンネーム  9:49 PM
ディレクトリ配置のデフォルトが決まっている (ソースは src , 出力先は target, ソースのエントリポイントは src/lib.rs と src/main.rs ) 点
rustfmtが公式で配布されていて、デフォルト設定が広く採用されている点
clippyが公式で配布されている点
API guidelinesなどのドキュメントも存在する点
などの点でみれば、比較的コードスタイルのばらつきは抑えやすいのではないかと思います。

石塚　正浩  11:00 PM
ペンネーム
御回答ありがとうございます。
更に付け加えますと、ソースコードは、誰が書いても良い意味で同じ様なソースコードになりやすく、良い意味で非個性で、個性豊かではないソースコードの書き方になりやすいですか？

ペンネーム  11:08 PM
それはかなり答えづらいですが、少なくともPerlやRubyのように「ほとんど構文が違うだけ」の多数の表記を導入することはほぼないですね。
11:11
たとえばRubyだと ["foo", "bar"] とも %w[foo bar] とも %W|foo bar| とも書けますし、 puts("foo") とも puts('foo') とも puts "foo" とも書けますが、ここまで多様になることはないです。 (とはいえやはり全くないわけではなく、たとえばRustでの文字列リテラルには通常の文字列リテラルとraw文字列リテラルの2つの記法があり、 "foo" と r#"foo"# は同じ意味になります)
11:13
しかしたとえば、データ構造を扱うときは大まかには手続き的に記述する方法と関数型プログラミング的に記述する方法がありますし、モジュールの切り方やカプセル化の方法にも多少の流儀の差はあったりします。
11:14
こういう個別的な例は出せますが、総合的に見たときに客観的に「統一感」を論じるのは簡単ではないなと思います。

ペンネーム  11:20 PM
またRustでは(コンパイラに同梱されるという意味での)標準ライブラリを小さく保ち、「事実上の標準」にあたる多数のライブラリ(公式に近い形でメンテされているものもあれば、そうでないものもある)を使うことを前提にするという方針があります。すでに事実上の標準が確立されているもの(rand, regex, log, serde, chrono, crossbeamなど)も多数ある一方、まだライブラリが乱立しているジャンルもあります。たとえば非同期エコシステムではtokioとasync_stdが2大勢力となっていて、これらの間を跨ぐのは容易ではないためどうなるかが注目されています。エラーコンテキストもerror-chain, failure, fehler, snafu, anyhowなど乱立状態からまだ抜け出せていません。(エラーコンテキストについてはgolangでもpkg/errors, go-errors/errorsなど似たような状態かと思います)

石塚　正浩  11:25 PM
追加回答ありがとうございます。
そう言う意味では、ソースコードの書き方のバリエーションと言うか種類は、概ね少ない様ですね。
もしPythonやGoもご存知でしたら、PythonやGolangとRustを比較すると、チームで開発した時に会議や打ち合わせの回数が少なくても、統一感を比較的出しやすいと言うか、チーム全体のバラツキが少なくなりそうな感じがRustには、ありますでしょうか？
例えば、中には個性豊かにソースコードを書いてしまう人がいたり、流派が独特な感じがひどくて、全体レビューの結果、ソースコードを書き直しで出戻りが発生したりする可能性は、低そうですが、どんなイメージでしょうか？書き方に種類が、あるのは、多少仕方ないかとは、思います。

ペンネーム  11:31 PM
「個性豊か」の度合い次第すぎるので難しいですが…… たとえば関数名や変数名のケーシングには標準があり、関数名をcamelCaseにしたり定数をlower_snake_caseにしたりするとコンパイラが警告を出します (例→ https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4d1d54de1e07b62a06f66a89de822994 )。こういったコンパイラのデフォルトの警告をちゃんと見る人であれば、ある程度の正気度は保証できる気はします。
11:33
また、clippyというリントツールが公式で配布されており、こちらには「偽陽性のあるリント」や「Rustコミュニティーとして必ずしも推奨するわけではないが、プロジェクトごとに必要であれば有効化できるリント」も含めてコンパイラ本体にはないリントが多数用意されています。 (リントの一覧がここで見られます: https://rust-lang.github.io/rust-clippy/ )
11:36
コンパイラの警告にしても、clippyのリントにしても、設定をある程度調整できます。設定はRust側のトップレベルのファイル (lib.rs / main.rs) や clippy.toml 内でできるので、設定を書いておけばそのまま全てのプログラマの開発環境に反映されます。なので、必要であればこれらの設定によって「個性豊か」度合いを調整できる余地もあると思います。

ペンネーム  11:43 PM
ところで、「統一感」の話をいまはしていますが、実際のところは「コードの品質を担保する」ことや、「あとでコードが読めなくなってしまい、技術的負債と化すことを防ぐ」といったことを達成するための道具として「統一感」を求めていると思いますが、どうでしょうか？

石塚　正浩  11:45 PM
追加回答ありがとう御座います。
なるほど素晴らしい！
リントなる物は、初めて知りました。明日 Google検索して見ようと思います。
個性豊かの度合いを調整出来る余地があるのですね。
統一感についての定義は、その様な感じになります。

  11:47 PM
その意味でいうと、Rustはプログラマがよくないコードを書いてしまわないようにできるだけ保護すること (よく「footgunを阻止する」と喩えられています) や、品質にかかわらずソースコードの動作の追跡性を損なわないようにすることを重要視している言語なので、その点は考慮に値すると思います。

石塚　正浩  11:51 PM
追加回答ありがとう御座います。
なるほど、Rustは、統一感について、良く考慮された言語だと思いました。
自分でも、これから、早く使いこなしてWEBサイトなどを開発していきたいですし、人にも自信を持って勧めていきたいと思います。
夜分まで回答して頂きましてありがとう御座いました。