いろいろ備忘録日記

主に .NET とか Go とか Flutter とか Python絡みのメモを公開しています。

The Zen of Zig (pythonとGoも)

概要

The Zen of Zig

zigのコマンドヘルプみると、zen ってサブコマンドがあったので、出力してみると以下のように出ました。

$ zig zen

 * Communicate intent precisely.
 * Edge cases matter.
 * Favor reading code over writing code.
 * Only one obvious way to do things.
 * Runtime crashes are better than bugs.
 * Compile errors are better than runtime crashes.
 * Incremental improvements.
 * Avoid local maximums.
 * Reduce the amount one must remember.
 * Focus on code rather than style.
 * Resource allocation may fail; resource deallocation must succeed.
 * Memory is a resource.
 * Together we serve the users.

以下のような意味になりますね。(DeepL先生より)

 * 意図を的確に伝える。
 * エッジケースは重要です。
 * コードを書くより、コードを読むことを優先する。
 * 物事を行うための明白な方法は1つだけです。
 * ランタイムクラッシュはバグよりも優れている。
 * コンパイルエラーはランタイムクラッシュよりも優れている。
 * インクリメンタルな改善。
 * ローカルな最大値を避ける。
 * 覚えなければならない量を減らす。
 * スタイルよりもコードに重点を置く。
 * リソースの割り当てに失敗しても、リソースの割り当て解除は成功しなければならない。
 * メモリは資源である。
 * 一緒になってユーザーのために尽くします。

個人的にはとても好感が持てるリストです。いいね。

The Zen of Python

ちなみに、The Zen of XXXXX で有名な Python は以下ですね。

$ python3
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
醜いより美しいほうがいい。
暗示するより明示するほうがいい。
複雑であるよりは平易であるほうがいい。
それでも、込み入っているよりは複雑であるほうがまし。
ネストは浅いほうがいい。
密集しているよりは隙間があるほうがいい。
読みやすいことは善である。
特殊であることはルールを破る理由にならない。
しかし、実用性を求めると純粋さが失われることがある。
エラーは隠すな、無視するな。
ただし、わざと隠されているのなら見逃せ。
曖昧なものに出逢ったら、その意味を適当に推測してはいけない。
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。
ずっとやらないでいるよりは、今やれ。
でも、今"すぐ"にやるよりはやらないほうがマシなことが多い。
コードの内容を説明するのが難しいのなら、それは悪い実装である。
コードの内容を容易に説明できるのなら、おそらくそれはよい実装である。
名前空間は優れたアイデアであるため、積極的に利用すべきである。

legacy.python.org

The Zen of Go

Goは以下。

the-zen-of-go.netlify.app

* Each package fulfils a single purpose
* Handle errors explicitly
* Return early rather than nesting deeply
* Leave concurrency to the caller
* Before you launch a goroutine, know when it will stop
* Avoid package level state
* Simplicity matters
* Write tests to lock in the behaviour of your package’s API
* If you think it’s slow, first prove it with a benchmark
* Moderation is a virtue
* Maintainability counts
* 各パッケージは単一の目的を果たすようにしましょう
* 明示的にエラーを処理しましょう
* 深くネストするのではなく、早期にリターンしましょう
* 並行処理は呼び出し元に任せましょう
* ゴルーチンを起動する前に、いつ停止するかを知っておきましょう
* パッケージレベルの状態を避けましょう
* シンプルであることが重要です
* パッケージの API の挙動を固定するためにテストを書きましょう
* 遅いと思うなら、まずベンチマークで証明しましょう
* 節制は美徳です
* 保守性が重要です

どれも、その言語の根底にある理念が見えていいですね。


過去の記事については、以下のページからご参照下さい。

サンプルコードは、以下の場所で公開しています。