https://youtu.be/AssDGyKTvBw
今回は The Basics の コメント について、前回に話しきれなかったもうひとつの C 言語と異なるところについて見ていきます。その後は後は、Swift では脇役になった セミコロン について眺めていく感じになりそうです。どうぞよろしくお願いしますね。
——————————————————————————— 熊谷さんのやさしい Swift 勉強会 #109
00:00 開始 01:30 複数行コメントの入れ子 05:09 ツールによるコメントのサポート 06:52 ドキュメントコメントの補完 07:46 複数行コメントの入れ子が上手くいかない例 08:56 コメントの補完の癖 09:28 複数行コメントの出番は少ない？ 10:11 シンタックスハイライトの恩恵 12:28 複数行コメントは必要？ 13:55 標準ライブラリーでの複数行コメント 15:00 単一行コメントと複数行コメントの混在 15:30 複数行コメントの利点 16:04 C 言語のコメントについて 18:32 複数行コメントを見直してみる？ 20:29 Doxygen のコメント書式 21:48 セミコロン 22:12 セミコロンの役割 22:57 行末にセミコロンの要らない言語 24:51 Swift における評価式の末尾 26:30 継続行と判断される場面 32:17 複数ステートメントを単一行に書く構文 34:16 複数ステートメントであることには変わりない 35:21 次回の展望 ———————————————————————————
Transcription & Summarize : 熊谷さんのやさしい Swift 勉強会 #109
はい、じゃあ今日は前回の続きとして、コメントについてお話ししていきます。さて、どうしましょうかね。コメントってシンプルな機能で、話し尽くしたと言えば話し尽くした部分もあるし、結構議論の絶えないところでもありますよね。ですから、そのあたりの話を雑談として気軽に進めるのも意外と有意義だったりすると思います。
なお、Swiftのコメントの特徴についても、この勉強会として紹介しておきたいところです。前回は最後にC言語のコメントと非常に似ているが、実際には違いもあるという話をしましたね。今回はその違いについてもう少し深掘りしてみましょう。
次のスライドに行きますね。なかなか面白い機能があります。知っている人は知ってますが、使っている人がどれくらいいるのかはちょっと分かりません。しかし、Swiftでは複数行のコメントを入れ子にすることができるんです。これは「/* */」で書くコメントです。
たとえば、次のように書けます。
/*
ここがコメントです。
/*
ここもコメントです。
*/
ここもコメントです。
*/
これを見たとき、私は衝撃的だと感じました。複数のコメントを本当に素直に入れ子にできるのです。入れ子にできると、たとえば次のような状況が簡単に処理できます。
/*
// 1行目から5行目までコメントアウト
// ...
*/
/*
// 2行目から6行目までコメントアウト
// ...
*/
昔のC言語だと、こういった場面で入れ子を使えませんでしたので、かなり苦労しました。このような機能があると、コードの一部を大きくコメントアウトしたいときに非常に便利です。
ただ、現実的には複数行のコメントを使う場面は少ないかもしれませんね。1行コメントで十分なことが多いです。昔は修正内容を残すためにコメントに過去のコードを入れておくことがありましたが、現在ではGitなどのバージョン管理システムがあるので、その必要性も減ってきています。
ツールの発達で、たとえば「コマンドスラッシュ」のような機能があり、一括で複数行を簡単にコメントアウトできるので、ますます複数行コメントの必要性が減りました。
// コマンドスラッシュで簡単にコメントアウト
print("Hello, World!") // this line will be commented out
// ... more code
こういった機能を知っておくと、たまに役立つことがあるかもしれません。ただし、APIの説明など特定の場面ではまだ活用の余地がありますので、頭の片隅に置いておくと良いでしょう。
以上、今日はSwiftのコメントの使い方についてでした。次回も引き続き興味深いトピックを取り上げていきますので、どうぞお楽しみに！ とりあえずコードを書いた後、ここにコメントを追加することをよくやっていた記憶があります。当時はVisual Studioを使用していましたが、今はどうでしょうか。ドキュメントコメントについてですが、ドキュメントコメントでは適切に保管されることが多いですよね。だいたいAPIの説明をする際にはドキュメントコメントを書くので、これで済むことが多いです。
また、他にもオプションコマンドスラッシュ（///）を使用して自動的にドキュメントコメントを生成する機能もあります。これを使うと、単一行のコメント（//）のように扱われ、複数行コメントを書く機会は少なくなることが多いですよね。
頂いたコメントをドキュメントコメントとして書いてみます。途中でコメントを閉じる仕組みが入ってしまうことがありますが、その場合は手動で消す必要があります。複数行コメントを使用しない場合、コメントの閉じ忘れが発生することもあるようです。時々アスタリスク（*）を書くことがありますよね。コメントを書き始めたつもりがコメントを開始してしまったという煩わしさはあります。自動で閉じコメントが挿入されることがあり、便利ではありますが時々煩わしいこともありますね。
また、単一行コメントは支援されることが多く、複数行コメントの存在感が薄れているように感じます。高度な入れ子機能があるのに、あまり使われない状況が続いているようです。積極的に使っている人もいるでしょうが、自分は昔よく使っていた記憶があります。そして現在はシンタックスハイライトが標準となっているため、コメントの閉じ忘れに気付きやすくなりました。
複数行コメントが入れ子にできなかった頃は、シンタックスハイライトもなく、コメントがどこまで有効なのか目で見て判断することが難しかった経験があります。そのため、単一行コメントが主流となり、ツールもそれをサポートする機能を提供するようになりました。
現在では、複数行コメントを使わなくても済む環境が整っています。入れ子をサポートする複数行コメント機能も、言語仕様から省いても良かったかもしれませんね。しかし、複数行コメントがないと困ることはあるでしょうか。多分、すべてが何とかなる気がします。
もし複数行コメントをなくすとしても、Fix-it機能で一括修正するなどの方法もありますね。ただ、好みの問題もあるかもしれません。「絶対に複数行コメントじゃないとダメだ！」という人もいるかもしれませんね。その一方で、複数行コメントがSwiftでパワーアップされていることを知った人は、積極的に使うようになるかもしれません。
標準ライブラリやSwiftのソースコードを見ても、複数行コメントはあまり見かけない気がします。これも思い込みかもしれませんが、実際には存在しているかもしれませんね。たとえば、メタルのコードでは複数行コメントが好んで使われているようです。 なるほど、どうしてメタルにたどり着いたのかは分かりませんが、標準ライブラリの複数行コメントは /* ... */ ですよね。そうですね。使われているところもあるみたいですね。メタルはAppleのものですから、Apple内でも派閥があるのでしょうか。ちょっと興味深いです。
コメントの混在についても少し興味があります。// はどうですか？あ、ないんですね。統一されているんですね。まあ、混在するのは別に問題ないとは思いますけどね。確かに私も昔はドキュメントコメントを書くときに /* ... */ を使っていたような気がします。この先頭に // があると少し煩わしいというのも分かります。最近はすっかり忘れていましたが、複数行コメントの利点はとてもスッキリしているという点ですね。だから、それを使っていくのもありかもしれません。複数行コメントが入れ子にできる仕様は、便利に使えるのかもしれませんね。
そうなんですか、C言語では単一行コメントは比較的最近の仕様なんですか。私はC言語を始めたのが1999年から2000年頃なので、もう当たり前に使っていましたけど。でも、C言語のようなレガシーな言語では単一行コメントで決着がついた方が都合が良さそうに思いますけど、そうじゃないんですね。興味深いです。入れ子コメントを考慮していない場合、/* があったら */ が出てくるまでコメントとして扱えばいいというのも納得です。改行文字の違いによる混乱もありますしね。
昔々のお話では、長い文章を書くときにエディターが折り返さないとかいろいろ問題があって、/* の方が使いやすかったということもあったかもしれませんね。確かに、環境も今とは違いましたからね。C++から // が標準化されたかもしれませんね。私はC++を2000年手前頃から触り始めたので、標準化が意識された言語だったんですね。それ以前のC言語はまだローカルルールが一般的でしたから、C99から少し変わったのかもしれません。
とりあえず、複数行コメントはそんな感じで良いですかね。今も使える仕様を見直すのも面白いかもしれません。たまたま出てきたメタルのコメントが綺麗ですね。意識的に複数行コメントを使ってみようかな。使わない機能もあえて使ってみると良さが分かることもありますしね。
ツールがサポートしている機能は便利ですよね。例えば、コマンドスラッシュとかオプションコマンドスラッシュとか。手でコメントを付けるよりもツールに頼ったほうが良いですね。ドキュメントコメントの書き方を忘れてしまったりもしますからね。
ドキュメントコメントについては、色が変わらないとダメなので、ちょっと忘れちゃったな。また後で確認してみます。
Swiftには入れ子コメントの機能があります。この機能を使えば、コメント内に別のコメントを含めることが可能です。
では、次のお話に移りましょうか。今度はセミコロンの話です。これもC言語由来の機能ですね。その前に、アットマークの話です。これはドキュメントコメントのつもりで話していましたが、別のドキュメント方式の可能性がありますね。色が変わっているので、ドキュメントコメントかもしれませんね。これは、Doxygenの構文なんでしょうかね。そうみたいです。@method などの記述でしたかね。 ```swift
メタルが使っているやつね。@methodなんてSwiftのドキュメントコメントでは書かないですもんね。そっかそっか、そっちを睨んでた。じゃあ、またちょっと違うんだ。もしかしてXcodeで作ってないのかなとか、ちょっと思ったりしたり。メタルの人ね。
あーでも、そうね、こっちね、きっとそうだ、そうだ。なので、それも一応Xcodeがシンタックスハイライト的に認識してくれてるっていう感じなのかもしれないですね。
さて、話をセミコロンに戻そう。Swiftのセミコロンはちょっと特殊な、ちょっと言いすぎたね。C言語からそのまんまの雰囲気を引き継いで存在していて、Swiftではセミコロンいらなくなったってのがとても有名ですけど、なくてもいいっていうものになってる。さらにセミコロンの意味がC言語とかまではステートメントの行末っていう意味でしたけど、Swiftではちょっと改良されてというか、手が入れられて、ステートメントの末尾って言ったら同じだね。行末ではなくて、ステートメントのセパレータとしてね、セミコロンというものが存在するように変わった。行末ではなくてセパレータって感じですかね。そう捉えるとまあわかりやすいのかな。
他の多くの言語とは異なり、ステートメント末尾にセミコロンは必要ない。なんか最近の言語ってセミコロンいらなくなってきてますね。なんとなくね、Google Apps Scriptか、あれなんかセミコロン書かなくてもよくなかったですかね。JavaScriptっぽい言語なんですけどね。そうやってパーサーが強力になったら、なんかセミコロンがいらなくなってくるんですよね。まあ、処理性能のせいで頑張るんでしょうけどね。
そうなんだ、Dartはセミコロン書くんだ。面白いですね。C言語とかは、気なタイミングで改良を入れられる代わりに、セミコロンを行末として使ってるっていうね。それが単なる見えてくる側面かもしれないですけど、一応そういったところがあるんですけど、言語によっては逆にね、気なところで改良できない代わりにセミコロンみたいなのがいらないみたいな言語も確かなんかあった気がする。パッと思い出せないですけど、要は改行文字すなわちステートメントの末尾って捉えてる言語ね。
Pythonとかそうなんだ。Python全く触ったことなくてわかんないんですけど、Pythonはセミコロンとかあと何かっこもないんですよ。あーそっかそっか、なんか噂でそういえば聞いたことがあるな。インデントを活用するとかでしたっけ。そうそう、インデントであれになるので。なるほどね、そっかそっか、そういった発想もありますね。
BASIC言語、昔のBASIC言語なんかは確か任意のところに改行入れられなかった気がするな。そうそうやってね、言語によっていろいろ特色があって、何をねステートメントの末尾とするかみたいなね、そういったところがあるんですよ。
で、C言語はセミコロンを取り、Swiftは改行を取ったんだ。あーでもそれも言い過ぎだね。文脈によってちゃんと解釈するんですよね。そこがね、とてもよくできてるなーという感じのするところで。
ちょっと余談紹介しよう。例えば関数があって、これがまあ何にも戻り値を返さないInt関数にしましょうかっていうのがあったとするじゃない。で、それでreturn 10とか返すわけですよ。この時に、まぁとりあえず実行して。ここかな？すると、まあ10返りますけど、ここに改行入れて今警告出るのかな？どうだったかな？あ、出ますよね。あ、でもちょっと警告が出る。昔は出なかったんですよ。returnの後のね、4行目がreturnのイスとしてね、変われてますから注意してくださいねっていうね、警告が今出るんですけど。これ要はね、時々まあ戻り値があるときはあんまりやらないと思うんですけど。どういう例えするといいのかな、戻り値がなかったときね。なんかいろいろとコードが書かれていて、ちょっとデバッグしたいなっていう場合にね、どっか途中にreturnを挿入するみたいなことがあったりしますよね。あ、ちょうどいいな、このVoidがいいですね。うん。
例えば関数なんかがあって、これが戻り値を返さないとするじゃないですか。で、ここで当然のように何か処理をしますよね。それでこのsomethingをどっかで使っていたとき、例えばそうだな、なんかをやっていて、何かをやっていて、なんかsomethingを実行していて、何かをやっていて、みたいなコードがあったときに、セミコロンがあったときはよかったんですよ。文末がね、はっきりしてるんで。こう例えばなってたとするでしょ。それでなんかsomethingの動作がおかしいな、これを実行するとなんか妙なことになるなっていうときに、その前に例えば8行目まではちゃんと動いてるのかなっていうのを確認したくてreturnを入れるみたいな。ここで1回ちょっと抜けて試してみよう、みたいなふうにしたときに、セミコロンがあったときにはもう何の問題もなく9行目で抜けてくれるんですよ。
``` ただ、Swiftのように前後の文脈を考慮して文末を判断する言語では、こうなったときにサムシングは戻り値がVoidでしょう。そうすると、returnに対してVoidが求められるわけですが、この9行目と10行目が果たして1ステートメントなのか2ステートメントなのかという問題が出てきます。これ、どっちだと思いますか？Swiftだと…私も分からないのですが、どっちなんでしょうかね。これ動きそうですよね。ちょっとやってみましょうか。これでprintでxが出るかどうか、出ますよね。動いちゃうんですよ、こういう問題があって。
行末を判断するのって、昔はCPUとかのパフォーマンスがまだ弱かったころは行末をちゃんと明確に書いてあげないと、コンピューターとしては辛かった時代があったんですよね。今はパフォーマンスが良くなったおかげで、構文解析が頑張ってくれるようになりましたが、それでも時折こういう問題が起こることがあります。
最初はこれが警告されていなかったんですが、予期しない動きがあったのでしょう。それで、こういった警告が出るようになったのだと思います。「ここやばいことがあるよ」と教えてくれるようになったんですね。ここにもう一つ解除を入れるとどうなのでしょう。ただ、変わらないですよね、きっと。
結構怖いですね、こうなると。ここにセミコロンを入れても、この警告が取れるわけではないですね。警告を取り除くにはreturnをこちらに書くのが良いですね。これなら誤解もなくなります。「おお、なるほど。」コメントいただいた方法もいいですね、こうやって明示的にVoidを返してあげる方法も良いですね。
まあ、9行目のreturnを書くのって、その時のタイミングで書いているだけなので、検証したいことを検証して、それで直してあげればいいわけですね。「なるほどね。」とにかく、このreturnを書いたときにこの警告が出たら注意が必要です。思いがけない動きをすることが多いので。
こういう状況になるのなら、こうしたほうが良いですね。こうしてあげると、意図が明確に伝わります。セミコロンがないせいで時々解釈エラーが起こることがありますが、return以外でセミコロンがないために問題が起こったケースって何かありますかね？自分は他に思い浮かばないですね。Voidを引数に取る構文ってreturnぐらいでしょうね、多分。
まあ、そんなに頻繁にはないですが、クリティカルなことがあるので注意が必要です。それはそれで置いておいて、Swiftのセミコロンというのは、1ステートメントを区切るためのもので、別のステートメントを一行で書ける形で便利です。一行にまとめたいコードが出てきたときには思い出すと便利かもしれません。
こう書いて「何をやっているんだ？」と分からなくなる人もいるかもしれませんが、Swiftが初めての言語でない限り、問題なく読めると思います。ただ、このセミコロンには注意が必要で、複数ステートメントをまとめて書いているだけで、1ステートメントに変換する構文ではないということです。
例えば関数定義したときに、1ステートメントであればそのreturnを省略できるという約束事があります。この約束に基づいてセミコロンでまとめたからといって、1ステートメントにはならないわけです。例えば、printのあとにIntを返すようなコードを書く場合、ここにセミコロンがあるとreturnを省略できなくなるので注意が必要です。
これが不便だなと思ったこともありましたが、そんなことはありませんでした。とにかく、そういった際に省略できなくなるので注意が必要です。こうやって省略できなくなるんで注意というほどでもないですが、知っておいたら良いでしょう。
というわけで、時間になりましたので今回はここで終わりにしたいと思います。次回からはインテジャー（整数）の話をしていきますので、また興味があればよろしくお願いします。お疲れ様でした。ありがとうございました。