読者です 読者をやめる 読者になる 読者になる

Go言語って何ででこんなに偏屈なんだろう に反応してみる

これに対して各項目の個人的に感じるメリットデメリットや意見などを書こうと思います。

pineplanter.moo.jp

反論や間違っている箇所の指摘やコメントなどあればこのブログに直接コメントするか yukkuri_sinai に乗っている連絡先まで。XMPPTwitterがオススメです。

null じゃなくて nil

メリット

短いので打ちやすい

デメリット

初学者が他の言語と混同して書き間違いやすい

ただ、これはGoでの nil だけに留まらず色々な言語の色々な項目にも当てはまるので一概にデメリットとはできないかと思います。

引用させていただくとだいたい以下と同感です。

こういうのは以下のデメリット欄では特になしと記載します。

なんで、 func int f() じゃなく、 func f() int なのか

これはちょっと考えましたが確かに言われてみると、という気もしました。

メリット

戻り値の型をぱっと見ただけで判断できる。

Goでは複数の戻り値を返すことができるので

func (int, string) hoge()

だとまず hoge を見てから string そして int と見ていく必要があります。逆に func から見ても同じです。

それに比べて

func hoge() (int, string)

となっていると string を見て int を見て「ああ、この関数は stringint を返すんだな」とすぐ把握できます。

と、ここまで書きましたが、半分こじつけです。どっかを見れば真の理由を探せると思いますがちょっと探しただけでは発見できませんでした。申し訳ないです…。

追記

デメリット

特になし

var hoge int は不可解

varって「暗黙的に型指定」で使うものだけど

とありますが、これは違うのでは…。

また、これを

int hoge

あるいは

hoge int

としてしまうと

func hoge() int

という関数の宣言を行う構文との折り合いが付かなくなってしまいます。

更に、Goでは var を使う機会は殆ど無い(体感?だいたいは := で事足りる)ので、明示的に変数を宣言しているぞという意図をプログラマに示す意味でも意義がある構文だと思います。

これはメリットデメリットを省略させていただきます。

ゼロ除算

「非IT企業に勤める中年サラリーマン」さん はまだ panic を知らないのでしょうか?

包括して例外の仕組みを作るべきという意見はありえると思いますが…。

ただ、私の場合は致命的なランタイムエラーのみ panic を出して残りはいわゆる err に任せる形式を気に入っています。

無視できるところは無視しても良いよという仕組みのほうが素直だと思うからです。

この項目ではデメリットだけ書こうと思います。

デメリット

知らないと死ぬ。

頭文字が大文字になるとパブリックになる

メリット

ぱっと見ただけで public なのか private なのかわかる。

これはけっこう大きいと思っていて、もし仮に

private hoge string

という宣言だった場合に、どこかで hoge が呼ばれていた場合に hogepublic なのか private なのかを把握するには宣言されている部分を参照しにいかなければいけません。

もちろん、IDEやエディタでなんとかすることも可能かもしれませんが…。

デメリット

識別子のフォーマットで挙動が変わるのが好きではない人にとっては気に入らない。

終わりに

こんなところでしょうか。

色々な意見があると思いますので一概に他の人を否定するわけではありませんが、とりあえず自身の感じたことは書けたと思います。

以上よろしくお願いします。

終わり