「Windows API/図形の描画」の版間の差分
削除された内容 追加された内容
Semi-Brace (トーク | 投稿記録) fix lint error (use script) |
|||
321 行
また、もし関数を使う場合でも、For文で書いた処理を関数に置き換えるのはラクです。なので、関数を作る前に、とりあえず、For文で試しに似たような処理を書くという方法もあります。
for文とif文による代用の方法には、欠点もあります。
まず、if文を使うと、原理的に、もし今後の編集によって条件分岐用の変数に想定外の変数（上記コード例では変数 j ）が代入された場合には、バグの発生原因にもなります。
なのでプログラミングの流儀には、こういう想定外のミスを防止する観点から if 文をなるべく使わないでコードを書くという流儀もあります。
ですが、似たような処理の場合分けのために if 文を使わないでfor文だけで似たようなコードをまとめて処理を書く方式だと、コードが長くなる場合があります。コードが長くなると、今度はその長さにより、バグの発生率が増えます。コードが長ければ長いほど、バグが混入しやすくなるし、仕様変更の際などにも変更の手間が増えたり、仕様変更のための修正箇所が多すぎて変更し忘れのミスをするなど、そういったバグが発生しやすくなります。
かといって、「コードを短くしよう」と思って、いきなり関数ばかり使ってコードを書くと、前の節でも説明したような欠点により、windowsAPIプログラミングでは関数の位置が、呼び出し場所と離れすぎている場合がほとんどなので、それが原因で別のコードの記述ミスをする可能性だって増えてしまいます。また、windowsAPIプログラミングの特殊事情で、関数を呼び出して引数を渡す際に、プログラマーの作成した変数だけを渡すのではなく、さらに各種のAPI用の様々な変数を渡す必要もあったりして、かなり関数を呼び出すことが、（windowsAPIでは）大変です。
こういったAPI的な特殊事情もwindowsAPIプログラミングにはあるので、DOSプロンプトなどのコンソール画面で標準C言語のプログラムを呼び出す場合とは違うのです。よって、必ずしもwindowsAPIのグラフィカルなアプリでは「関数」はプログラマーにとって使いやすいとは、限りません。
ともかく、どんなプログラミング様式も一長一短です。
なので、簡単で短い単純なプログラムだけを書く場合には、似たような処理の繰り返しがあっても、あえて関数もfor文もif文も全く使わずに、逐次的に1行ずつ命令を書いていく場合もあります。
もちろん、この逐次的な方式も、欠点があり、コードがかなり長くなるので、長くなるにつれて記述ミスをしやすくなります。
結局、けっして完璧なプログラミング様式は、ありません。結局、どんなプログラミング様式でコードを書いても、けっしてバグを完全に防ぐことはできないのです。
よって、プログラマーは色々と妥協しながら、テストやデバッグを何度も繰り返して、コードを書くことになります。
== 構造体は無印C言語とやや異なる ==
| |||