はじめに
Redox OS とは
Rustで書かれたフルスクラッチのマイクロカーネルOS。OSだけでなく、エコシステム（エディタ、ビルドツールもろもろ）、GUIもRustで書くと言うなかなか壮大なプロジェクト。なお、まだドライバが不十分なため主に仮想環境で動く。
https://www.redox-os.org/jp/
https://github.com/redox-os/redoxRedox OS kernelとは
醜くなっていくカーネルをリライトする内部プロジェクト。
https://github.com/redox-os/kernel
README.mdの拙訳
※1.誤訳、指摘等あればコメントでぜひ。あと、一部わからないところや推測した箇所は[hoge]で付記してあります。
※2.20170927にREADME.mdが改変され以下の文言は削除されています。目的を達成したようです。なお、削除される前の原文は20170327に改稿されたバージョンです。
理由(Why?)
[Redox]カーネルは最初に書いた者しかバグを発見・修正することが出来ないほど急激に汚くなっている。幸いなことに、Redoxカーネルは比較的小さいためこのプロジェクトには数ヶ月しかかからないだろう。
目標(What?)
新たなるカーネルは以下の要求において明確でなければならない。
正しさ：何よりも、カーネルは正しくなくてはならない。ハック禁止、小さくてクールなショートカットに見えたとしても、後に容赦ないバックスラッシュ[バックラッシュにかけた洒落?コメントアウトされるということだろうか]をもたらすだろう。正しさと冗長性を保とう。
可読性とドキュメント：コード品質は高く、（全ての！）APIドキュメントと瑣末でない点に関しての注意深いコメントを含む詳細なドキュメントが付随すべきだ。
パフォーマンス：出来るならやろう。
ガイドライン(Guidlines)
腐った家は腐った土台の上に建てられる(A rotten house is built on a rotten foundation.)
自分を騙すのはやめよう。醜いコードに逆戻りなんて嫌だろう。最初から正しい方法でコードを書き、正しい方法で書き終えたときのみ次に移るように確認しよう。
コメント(Comments)
全ての箇所にコメントを書くのをためらってはならない。
文書(Documentations)
すべての公開物はAPIドキュメントも含むべきだ。
デバッグアサーション(Debug Assertions)
デバッグアサーションの乱用はバグを捕捉するのに素晴らしい方法だし、是非ともお勧めしたい。
静的チェック(Static checking)
Rustは素晴しく安全な抽象化機構を作るためにたくさんの型システムが用意されている。機会があればいつでもそれを使うべきだ。
非安全[な状態]は回避されるべきだ。もし幾つかの例外的な状況でそれが引き起こされるなら、アサーションを挿入せよ。カーネルも例外ではない。セキュリティ脆弱性よりカーネルパニックの方がマシだ。
もし到達し得ない状態がある（もしくはあるべきだ）が、[その状態が]不安定で、UB[Undefined Behavior (未定義動作)]につながるような場合、関数のスタートにアサーションを置け。
落ち着いて(Be gentle)
できるだけ早くたくさんコードを書こうとしてはならない。時間を取って注意深く。
コミット(Commits)
わかりやすいコミットをしよう。わかりやすいコミットを自分に強いるひとつの方法として、 [git に]-m フラグを渡さないというものがある。そうするとエディタがポップアップするので、長いコミットメッセージを書くのに便利だろう。
所感
カーネルコーディングならではのガイドラインだが、最初から良いコードを書こうと強く意識するのはどのレイヤーのコーディングでも重要だと思った
アサーションをガンガン挿入するのは特にテストの書きようがないレガシーコードのリファクタリングに応用できる。
まだ実用段階にないカーネルをリライティングするところに意識の高さが伺える（というか今しか出来ないのか）。
実際、システムコールのソースは素人目にも何をしているのか追えるくらいに平易。（ https://github.com/redox-os/kernel/blob/master/src/syscall/fs.rs ）
訳についてご教授下さった方に感謝します。