アカウント名:
パスワード:
while (TRUE) { c = getchar(); if (EOF == c) { break; } ....}
// いやまあ、美しくないのはわかっているけど、将来の自分の可読性のためにもこう書く。//// そういえば、比較のときに定数を左辺に持ってくるテクニックは、さすがに死んだか。
> そういえば、比較のときに定数を左辺に持ってくるテクニックは、さすがに死んだか。
未だによく見ますよ。古のコードのメンテナンスだけではなく、新規分にも。
コーディング規約に明記しようとしたヒトを必死で止めたこともありました。「比較演算子の左辺に定数」「ハンガリアン記法」「カッコ前後の改行、空白」は、コーディング規約の体裁を整える(項目数を水増しする)ためによく使われますね。
すみません。どこまでが冗談かわからないので無粋なのを承知で。当方が担当しているプログラミングの講義では、 while ((c = getchar()) != EOF) { ... }みたいな書き方はCや類似言語のイディオムとして定着しているので、代入と条件判定をわざわざバラして書くとむしろ意図がつかみにくくなるかも知れないと教えています。まあ、スタイルの問題はさほど重要ではないので、こう書かないと×にする等のダメ指導はしませんが。
# 個人的には、こんなイディオムみたいなものができるプログラミング言語は設計が# 良くないのではと考えていますが。
私はアリだと思いますよ。実際に解らない人間が多くなる表記ってのはメンテ上の問題増えるってのは確かですから。
今じゃどうせ最適化はコンパイラがやってくれますし。
綺麗で動かん物よりも、少々汚くても動く方がマシ。プロジェクト途上で来た新人が解らんからって、そこでいきなり教育手順を入れられる訳でも無いし。
>少々汚くても動く方がマシ。
ところがぎっちょん、「汚い」ってのは動かなくなってもどこが悪いのか切り分けにくいんだな。つまり今はいいが将来に負債を残してる状態ね。(MartinFowlerふうにいえば技術的負債)そしてその(時限)爆弾がいつ炸裂するかは俺らには読めない。
>そこでいきなり教育手順を入れられる訳でも無い
ペアプロでもやったら?
コレじたいは、「具体的な知識こそないが技術的下地は有る」人間なら数分で説明が終わるだろうし、そうでなくても、そこにあるパズルを「パズルだからスルーしとけ」と頭ごなしに言うよりは、「このパズルはこう解くのさ」と最初に
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
アホな保守スタッフのために・・・ (スコア:1)
なんていう配慮をしなくてよくなる未来。
Re: (スコア:0)
return *p = getchar();
}
while(_getchar(&c) != EOF)
ってやりなよ。
Re:アホな保守スタッフのために・・・ (スコア:2)
while (TRUE) {
c = getchar();
if (EOF == c) {
break;
}
....
}
// いやまあ、美しくないのはわかっているけど、将来の自分の可読性のためにもこう書く。
//// そういえば、比較のときに定数を左辺に持ってくるテクニックは、さすがに死んだか。
Re:アホな保守スタッフのために・・・ (スコア:1)
> そういえば、比較のときに定数を左辺に持ってくるテクニックは、さすがに死んだか。
未だによく見ますよ。
古のコードのメンテナンスだけではなく、新規分にも。
コーディング規約に明記しようとしたヒトを必死で止めたこともありました。
「比較演算子の左辺に定数」「ハンガリアン記法」「カッコ前後の改行、空白」
は、コーディング規約の体裁を整える(項目数を水増しする)ためによく使われますね。
Re: (スコア:0)
すみません。どこまでが冗談かわからないので無粋なのを承知で。当方が担当している
プログラミングの講義では、
while ((c = getchar()) != EOF) { ... }
みたいな書き方はCや類似言語のイディオムとして定着しているので、代入と条件判定を
わざわざバラして書くとむしろ意図がつかみにくくなるかも知れないと教えています。
まあ、スタイルの問題はさほど重要ではないので、こう書かないと×にする等のダメ指導
はしませんが。
# 個人的には、こんなイディオムみたいなものができるプログラミング言語は設計が
# 良くないのではと考えていますが。
Re: (スコア:0)
私はアリだと思いますよ。
実際に解らない人間が多くなる表記ってのはメンテ上の問題増えるってのは確かですから。
今じゃどうせ最適化はコンパイラがやってくれますし。
綺麗で動かん物よりも、少々汚くても動く方がマシ。
プロジェクト途上で来た新人が解らんからって、そこでいきなり教育手順を入れられる訳でも無いし。
Re: (スコア:0)
>少々汚くても動く方がマシ。
ところがぎっちょん、「汚い」ってのは
動かなくなってもどこが悪いのか切り分けにくいんだな。
つまり今はいいが将来に負債を残してる状態ね。(MartinFowlerふうにいえば技術的負債)
そしてその(時限)爆弾がいつ炸裂するかは俺らには読めない。
>そこでいきなり教育手順を入れられる訳でも無い
ペアプロでもやったら?
コレじたいは、「具体的な知識こそないが技術的下地は有る」人間なら数分で説明が終わるだろうし、
そうでなくても、
そこにあるパズルを「パズルだからスルーしとけ」と頭ごなしに言うよりは、
「このパズルはこう解くのさ」と最初に