今回も 演算子 の基本的なところについて見てきた中で気になった 三項演算子 を眺めていきます。前回はその「よくない」とされる主張を見つけて読み進めたところですけれど、今回はその続きから「よい」とされる主張についても見れたらいいなと思っています。よろしくお願いしますね。
——————————————————————————————————— 熊谷さんのやさしい Swift 勉強会 #320
00:00 Start 00:10 今回の展望 01:23 三項演算子とは 02:16 そのうちの、条件演算子 03:01 ところで Compare and Swap 07:51 条件演算子のどこが良くないと感じるか 09:26 記号が衝突しがち 10:10 言語間における文法上の解釈の違い 12:57 そもそも演算子は難しいかもしれない 14:41 条件演算子の入れ子表現 15:56 構造化していけば見やすくなりそう 20:44 数学の公式みたいにも見えたりする？ 22:02 いろいろな書き方を比べてみる 29:01 else if は、条件に一貫性を持たせにくいのが気になる 30:25 結局は状況次第で変わってきそう 31:00 次回の展望 ———————————————————————————————————
Transcription & Summarize : 熊谷さんのやさしい Swift 勉強会 #320
さて、今日は参考演算子について見ていきたいと思います。この演算子は何かと議論を呼ぶもので、使うかどうかで悩む人も多いようです。前回もこの話題に触れ、特に物議を醸すブログを参考にしていましたが、まだ話し切れていない部分があります。
参考演算子とは、ある条件式が真であれば左側の値を、偽であれば右側の値を選択することができる演算子です。多くの人が「参考演算子」と聞いてこの演算子を思い浮かべるでしょうが、実際には「条件演算子」と呼ぶ方が通俗的かもしれません。参考演算子以外に似たようなものがあるのか、考えるところでもありますが、主にこれが代表的な演算子です。
また、話題に出た「コンペアアンドスワップ」についても触れておきます。これは関数であって演算子ではありませんが、CPUの特別な命令で、同期処理やリソース管理に利用されるものです。あるメモリの値を指定された値と比較し、同じであればメモリの値を更新するという操作を行います。この操作はアトミック操作と呼ばれ、データレースを防ぐ仕組みの一つです。
「ダブルコンペアアンドスワップ」についても少し触れておくと、これは二カ所のメモリを同時に扱う命令ですが、万能ではないとしばしば言われます。実際、複雑な操作はバグを生みやすく、これを取り巻く誤解があるかもしれません。正確な実装には注意を要しますが、このような操作はやはり現実的な限界があると理解するのが良いでしょう。
そんなところで、今回も少し深く考察してみました。便利そうに見える機能でも、細かい点に意識を向けるのは大事ですね。 とりあえずこんなところで。参考演算子というのは、if文のように書くことができます。そして、if文で書くと冗長になることがあるので、参考演算子を使った方が良いと多くの人が信じているようですが、私はそうは思わないことがあります。複雑なif文は読みづらいことがありますが、これは基本的にどの言語でも同じです。if文の中にやたらとifを入れすぎると読みづらくなりますよね。こうした場合は、ブロックが多すぎる部分を関数に分けて切り出して使用することができると思います。どちらにしても、わかりにくさを感じることがあれば、状況に応じて使い分けるのが良いでしょう。
続いて、続記号がぶつかることについてです。前回も少し触れましたが、「?」のような演算子が入ると、どの「?」がどの役割を持つのかわかりにくくなることがあります。このようなことは確かに混乱を招くことがありますね。また、スペースがないこともわかりにくさの原因かもしれません。Swiftでは空白が必要ですが、適切に空白を挟むことで読みやすくなるでしょう。
文法上の解釈も言語によって異なることがあり、これは非常に大きな問題です。Swiftを書いているときに、他の言語の知識を優先してしまうと、誤解を生む可能性があります。また、Swiftでの代入演算は比較的わかりやすいので、条件の中のどこで発動するのかが理解しやすいです。参考演算子の優先度は比較的低く、代入演算子や演算子を理解する際に、丸かっこで囲まないとわかりにくくなることがあります。例が書かれていませんが、こういった問題に対処するために丸かっこを使うという話でした。 今回のテーマは、演算子の優先順位や記号の違いに関する話です。プログラミング言語によっては、x == aのような条件式の解釈が異なることがあり、それが混乱を招くことがあります。他の言語や演算子でも似たようなことがあり、例えばPerl言語では、AまたはBとA or Bのような記述方法があり、演算子の優先順位が異なります。このような違いがあると、A or B or Cのような式でどちらが優先されるのかが問題になったりします。
これに関連して、JavaScriptのような言語では、等号の数で意味が変わることがあります。このような演算子に関する悩みは、記号を正しく理解していないと使いづらいですが、知っていると便利です。
条件式に関しては、構造化プログラミングの観点から見ると、構造が整っている方が頭の整理がしやすく、理解しやすいというメリットがあります。過去には構造化プログラミングが一般的でなかった頃もあり、そこから移行することで頭の中の整理が進み、コードが簡潔に書けるようになりました。
具体的な例でいえば、条件が複雑な場合、式をシンプルにするために意味のある名前をつけてブロック化すると良いです。例えば、A1やC1のような条件式や処理をブロックにして、それに対する名前を付けておくと、その条件ならこの処理をする、といった具合に理解しやすくなります。そして、それをプログラムの中でしっかりと表現することで、コードを読みやすくすることができます。
具体的に説明するために、int型の変数を使った例や、条件式を使った例をコードで記述しましたが、基本的に複雑な条件を整理するためには構造を意識して書くことが重要です。どの記述法が最もわかりやすいかは、実際にコードを書いて試行錯誤することで見えてくると思います。 Swift言語では、判定条件による様々な処理と、その記述方法について考えてみましょう。例えば、if文を使って条件分岐を行う際に、変数や関数に意味のある名前を付けることで可読性を高めることができます。名前を付けることで、そのコードが何をしようとしているのかが明確になり、理解がしやすくなります。
また、コードが長くなったり複雑になったりした場合は、適切に関数に分割して整理することも重要です。そして、条件に応じて2つの値を切り替える場合には、三項演算子（条件演算子）を利用することができます。三項演算子は、簡潔に条件処理を記述する方法として有用です。例えば result = condition ? valueIfTrue : valueIfFalse のように書くことで、条件に応じた値を手短に設定することができます。
Swift 5.9からは、returnの省略が可能になり、if文も一行で書けるようになりました。ただし、長いコードブロックになった場合には、読み手がその意味を理解するのに負担がかかることがあります。コードを書く際には、自分自身がその書き方に慣れているかどうかに関わらず、他の人が読んで理解しやすいように心掛けることが大切です。
場合によっては、一行での記述が便利であっても、それを使いすぎると可読性が低下し、他の開発者がコードを読み解く際に混乱を招く可能性があります。そのため、単純に短く書けるからといって、その書き方が常に最適であるとは限りません。適切なバランスを見つけ、状況に応じて最適な書き方を選んでいくようにしましょう。 プログラミングでは、ときどき1行にまとめてコードを書きたいと思うことがありますね。Swiftでは、1ステートメントの場合、returnを省略することができる特別なルールがあります。ただ、どう書くかは好みによる部分もあるため、万人にわかりやすく書くのが無難です。誤解を避けたいときは、オーソドックスな書き方が良いでしょう。
また、if文とswitch文がありますが、個人的にはswitch文の方が好みです。if文よりもswitch文の方が読みやすいと感じる場合もあります。例えば、条件が少し複雑な場合、switch文を使うことでわかりやすく表現できることがあります。特に、isEmptyがtrueかどうかで分岐させるときに、switch文を使うと構造がしっかりしていて安心感があります。
一方で、参考演算子も使えますが、if文に比べ慣れていない場合、一瞬戸惑うこともあります。自分の中での好みや、周囲の人にとっての読みやすさを考えて、どう書くかを決めるのも一つの手です。また、if...else ifの構文をあまり好まないこともあります。関連のない条件を並べたときに、対等に扱うのが個人的にはあまり好きでないためです。この点では、switch文の方が軸がぶれずに使いやすいこともあります。
最終的には、状況に応じて使用する文法を選ぶことが重要です。参考演算子かif文か、あるいはswitch文かについても、正解はありません。プログラムの読みやすさや保守性を考えて、その時々に最適な選択をすることが大切です。
このように、プログラミングの書き方や文法については、個々人の好みやチームの方針によっても異なることがありますし、特段の正解はないこともありますが、自分のスタイルを大切にしつつ他の意見も柔軟に取り入れていきたいですね。これで本日の内容は以上です。お疲れ様でした。ありがとうございました。