[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[WitchTech 00732] Re: 文字列を数値に変換するには?



エル%高岡@鯆です。

2001/02/15 04:35 頃に
  「[WitchTech 00730] Re: 文字列を数値に変換するには?」ということで

Kenichiro Ueda さん
>> ループであろうが、sprintf であろうが、それは strcat よりも確実
>> に可読性を落とすと思っています。
> 単に「変なループ」を引き合いに出すのはおかしいということです。
> 変なループならループが変なのであって、他の処理がおかしいので
> はないでしょう。

とりあえずあきらかに可読性が悪くなる例をあげたかっただけなんですが、
問題になるのは ループの内容がオカシイ ことではなくて ループという
手段を選択した ということです。

同様に、問題になるのは sprintf という関数を選択した ということです。

>> 「文字列の終端に別の文字列を繋ぐ」手法は沢山あるんでしょうけど、
>> 最も可読性が良い、つまりコードが目的を明に示しているのは strcat
>> だと思っています。
> あたながそう考えるのはいいとして、他人に押し付けるようなこと
> はしないようにお願いします。

引用されてない部分を含めて私の思っている範囲であって、うえけんさん
の主張される「sprintf のほうがstrcat よりも可読性が高い」という意見
に対しての反対意見です。

> 私は「使いもしないでよけて通るのはどうか?」と主張しているだけで、

私には、#707 の
> 理由は、文字列編集を strcpy と strcat を連発してやると読みに
> くいし処理も遅いからです。 

という文章からは、そのような主張は読み取れませんでしたし、それに
対して #728 で可読性が劣るという考えを行う上での視点もあきらかに
してみた、というだけです。

どっちがより優位であるとか、どちらが良い選択である、ということは
まったく関係のないことです。この文面での要点はただ

sprintf を利用するほうが可読性が悪い (低い)

というだけです。「可読性が高いコード」と、「実行速度が高い」や
「バイナリサイズが小さい」「バグの発生原因になりにくい」などの
優位性や、それを選択するかどうかといった使う使わないという問題
は完全に切り離して考えています。

> バグはソースの
> 行数に比例して増えるのですから、できるだけ短いほうが、究極的
> にはプログラムなど書かないで目的を達成できるのがベストです。

ここは一般的な話としてかかれているのでしょうか?

バグが増える要因はアルゴリズムの複雑化や目的意識が不透明になる
コードや、コメントの少なさだと私は考えています。

優秀なアルゴリズムを発見して3行で記述できる複雑なステートメン
トよりも、誰が見ても一目瞭然で何をやっているかがわかる30行の
ステートメントのほうがバグが発生する確立ははるかに少ないと考え
ています。

もちろん、単調なコードの繰り返しによる人間のミスの誘発も充分大
きな要因だと思っています(先ほどの私のメールのような)

前述のソースの行数に対して増えるとう一般形の特殊系としての例が

> strcatを連発して20行かけた処理を、sprintf で1行にできるの
> なら、バグの入る確率が1/20になるわけです。バグはソースの
> 行数に比例して増えるのですから、できるだけ短いほうが、究極的
> にはプログラムなど書かないで目的を達成できるのがベストです。

ということでしたら、それは充分に納得がいきます。

しかし、それは前述しましたが、「バグが出にくいコード」であって
「可読性が高いコード」とはまた別ではないかと考えます。

sprintf を利用することで、少ない行数でバグが出にくいコードを書
くことができたということが、可読性の高いコードになったという話
になるということにはどうしても納得できません。

そのコードから「単に後ろに文字列をつなぎたいだけだったんだ」と
理解するにはどうしても strcat よりも時間がかかることだと思いま
す。

--
// El (K.Takaoka) ! saepro@din.or.jp 
// PGP : 7F61 E57E 972B 595D 14CD  EFA6 C055 7B61 13D4 F367


ML Archives