アカウント名:
パスワード:
修正前のコードにマジックナンバー的な値がずっと存在していたのが少し残念だね。
screen_priv->fake_interval = 16667;
コメントに書いてある通りで60Hz のインターバル(=interval)，つまり 1/60秒 = 16667 μ秒のことですよ
そういうのはマクロにしておくんだよ1/60秒が33334μ秒になった時にコードの修正が楽になる
これとか#define NUM_10000とかネタレスしてる人とマジレスが混在して混沌としてる
いや、1s/60 の結果なのは分かった上で書いたのだけど。コメントには
Otherwise, pretend that the screen runs at 60Hz
と書いてあるけど、16667 については明確には書いてない。だから「マジックナンバー的な値」と書いた。あんだーすたん？
それは「明確に書いている」と受け取るなぁ。俺は
あなたには前提知識がありマジックナンバーではないのかもしれないが、一般的にはマジックナンバーでしかない、という視点はコード開発ではとても重要ですよ。
プログラミングを「製造」と言って三項演算子を一律禁止するコーディング規則を作りそうなやつだな。1から10まで説明してたらコードの9割がコメントになるわ。
いちいちコメント書かなくても良いようにマクロや定数使えって話だろ？
1から10までの説明は要らないけど、コードから意図が伝わるように書かれていなかったことが問題でしょ。コンパイルする際に最適化されることを期待して、こんな風に書いていればコメント要らないし。
悪い例: screen_priv->fake_interval = 16667良い例: screen_priv->fake_interval = 1 * 1000 * 1000 / 60 // 60Hz [usec]
実務でプログラミングに関わってたら常識のハズなんですが､､やっぱりオープンソースとか「趣味で」やってるとこうなっちゃうんでしょうねぇ
少なくともマジックナンバーを使わずに下みたいにヘッダでdefineしろってのは仕事なら最初に言われるはず#define NUM_1 1#define NUM_2 2...#define NUM_10000 10000
＃ define NUM_100 10って書いてるの見つけて二度見した経験があるのでAC
#define NUM_10000までしかなかったら16667を表すのに足りないじゃん! やっぱりスーツは馬鹿だな
マクロや定数にしたからって16667が何を意味するのか説明するコメントが要らなくなるわけじゃないでしょ。そして一箇所でしか使われてないならマクロや定数にしたところで位置を移動するだけで大した意味はない。
あれ、おかしいな。#4086698にコメントしたつもりでした。どうしてここにぶら下がってるんだろう
むしろ、NUM_1000とかは酷いローカルルールなんだから読みづらいことこの上ない。直観的には全く分からないんだから、そんなコードを他人と共有するのはやめてくれ。
これは最悪のローカルルール。うん、某大手系列でやってる所あるよね。痴呆の極み。
ネタとマジが混ざりすぎて…
コメントの代わりにマクロ名や定数名使えってことだよ。そして一箇所でしか使われていなかったとしても、他で同じ数値を使いたくなったときのためにマクロや定数にすべき。16666なのか16667なのかで判断に迷うこともなくなる。
> それは「明確に書いている」と受け取るなぁ。俺は
オープンソースで「俺はわかる」と言われても。他人が読む前提が無いのかなぁ困った人だ。
「Otherwise, pretend that the screen runs at 60Hz」のコメント付きで16667と書かれてりゃわかる人は十分いるだろうし、それじゃわからない人がいるというならそう思った人が修正すりゃいいじゃん。オープンソースなんだし
スラドの猿たちの90%以上はマウント合戦に夢中で「修正前のコードに」と書かれていることに気づかない
それでわからない人はコードを弄らないで欲しいわ。
俺なら// Magicってコメントにする。
俺なら// [usec]だな
コメント書くまでもなく最初からC言語だろ！
修正後でもコメントのないマジックナンバー(1000000)は残ってんぞ。> screen_priv->fake_interval = 1000000 / fake_fps;
つーか、直値とかよりも場当たり的に糞みたいな大域変数を追加してる方がひでーわ。
hackって語源的にはそういうもんだからね
どんな書き方をするかはともかく初期値(省略値)は固定値でどこかに記述する必要があるだろ。
そのことよりも、パッと見で、修正後の screen_priv->fake_interval が 60 Hz 時に 16667 でなくて 16666 を示すことが気になりました。修正前後で 60 Hz 時の挙動が変わらないことを祈ります。
大体、何故INTEGERなん？DOUBLEの方が良くね？（門外漢的感想
Apple「温度の値が華氏で飛び飛びになるくらいで大したことありませんよ」
ハードウェアを動かすための精度が必要とされるクロック回路のPLL分周比の設定などでは無いので、16666でも16000でも大した変わりは無いでしょう（用途を考えれば体感的に誤差を感じない程度でOK）
ここでの問題は2つあり、(1) 単位が不明であること(2) 値の設定意図が不明であること
(1)については、時間長を表すユーザ定義型を作れば型検査の恩恵も受けられるようになり、例えばusec値をmsec値に代入するといったミスをコンパイル時検出できる。ただしCだと直接的な方法はない(structでそれっぽいことはできるが…)ので、次善の策としてコメントで単位をつける方法か。
(2)についてはdiffを見れば分かるとおりコメントで十分に親切な補足があり、「interval」と「60Hz」の意味が取れれば問題なく理解可能。ただこれは程度問題であるので、どれだけ詳しく書いたとしても、教条的に全部コメントに書かないと不満な外野が文句を言ってくる。実務上は、そういった声は適当なところで切り捨てることになる。
一つ上のレイヤに移ると、「60Hzをこの場でハードコードすべきか」という問題が出てくる。この判断は存外に難しい。
マクロ化(名前付き定数化)する方法は安易に選ばれがちで、確かに可読性は上がるものの、識別子の文字数(安全範囲は32文字くらい?)でしか情報を伝えられない。それで足りなければコメントで補足する方法になるが、今度はコメントとコードで情報が二元化して経時で乖離する危険性が出てくる。
本件はフォールバック設定の話で、この値をこのソースファイル外部で使う状況は想定しづらい。したがって、コメント付きでハードコードする判断は適切であったと考えられる。
もしかして、gotoを使ったら少し残念になったりします？
goto は見通しがよい部分や狭い範囲で使うならいいんじゃない？整理されていないコードに使う阿呆もいるけど、そういうのは戦力外。
gotoを書いたときには見通しが良かったのでは
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
指定可能か否かは置いといて (スコア:0)
修正前のコードにマジックナンバー的な値がずっと存在していたのが少し残念だね。
Re:指定可能か否かは置いといて (スコア:2)
コメントに書いてある通りで
60Hz のインターバル(=interval)，つまり 1/60秒 = 16667 μ秒のことですよ
Re: (スコア:0)
そういうのはマクロにしておくんだよ
1/60秒が33334μ秒になった時にコードの修正が楽になる
Re: (スコア:0)
これとか#define NUM_10000とかネタレスしてる人とマジレスが混在して混沌としてる
Re: (スコア:0)
いや、1s/60 の結果なのは分かった上で書いたのだけど。コメントには
と書いてあるけど、16667 については明確には書いてない。
だから「マジックナンバー的な値」と書いた。あんだーすたん？
Re: (スコア:0)
それは「明確に書いている」と受け取るなぁ。俺は
Re: (スコア:0)
あなたには前提知識がありマジックナンバーではないのかもしれないが、一般的にはマジックナンバーでしかない、という視点はコード開発ではとても重要ですよ。
Re: (スコア:0)
プログラミングを「製造」と言って三項演算子を一律禁止するコーディング規則を作りそうなやつだな。
1から10まで説明してたらコードの9割がコメントになるわ。
Re: (スコア:0)
いちいちコメント書かなくても良いようにマクロや定数使えって話だろ？
Re: (スコア:0)
1から10までの説明は要らないけど、コードから意図が伝わるように書かれていなかったことが問題でしょ。
コンパイルする際に最適化されることを期待して、こんな風に書いていればコメント要らないし。
Re: (スコア:0)
実務でプログラミングに関わってたら常識のハズなんですが､､
やっぱりオープンソースとか「趣味で」やってるとこうなっちゃうんでしょうねぇ
少なくともマジックナンバーを使わずに下みたいにヘッダでdefineしろってのは仕事なら最初に言われるはず
#define NUM_1 1
#define NUM_2 2
...
#define NUM_10000 10000
＃ define NUM_100 10って書いてるの見つけて二度見した経験があるのでAC
Re: (スコア:0)
#define NUM_10000までしかなかったら16667を表すのに足りないじゃん! やっぱりスーツは馬鹿だな
Re: (スコア:0)
マクロや定数にしたからって16667が何を意味するのか説明するコメントが要らなくなるわけじゃないでしょ。
そして一箇所でしか使われてないならマクロや定数にしたところで位置を移動するだけで大した意味はない。
Re: (スコア:0)
あれ、おかしいな。#4086698にコメントしたつもりでした。
どうしてここにぶら下がってるんだろう
Re:指定可能か否かは置いといて (スコア:1)
むしろ、NUM_1000とかは酷いローカルルールなんだから読みづらいことこの上ない。直観的には全く分からないんだから、そんなコードを他人と共有するのはやめてくれ。
Re: (スコア:0)
これは最悪のローカルルール。うん、某大手系列でやってる所あるよね。
痴呆の極み。
Re: (スコア:0)
ネタとマジが混ざりすぎて…
Re: (スコア:0)
コメントの代わりにマクロ名や定数名使えってことだよ。
そして一箇所でしか使われていなかったとしても、
他で同じ数値を使いたくなったときのためにマクロや定数にすべき。
16666なのか16667なのかで判断に迷うこともなくなる。
Re: (スコア:0)
> それは「明確に書いている」と受け取るなぁ。俺は
オープンソースで「俺はわかる」と言われても。他人が読む前提が無いのかなぁ困った人だ。
Re: (スコア:0)
「Otherwise, pretend that the screen runs at 60Hz」のコメント付きで16667と書かれてりゃわかる人は十分いるだろうし、それじゃわからない人がいるというならそう思った人が修正すりゃいいじゃん。オープンソースなんだし
Re: (スコア:0)
スラドの猿たちの90%以上はマウント合戦に夢中で「修正前のコードに」と書かれていることに気づかない
Re: (スコア:0)
それでわからない人はコードを弄らないで欲しいわ。
Re: (スコア:0)
俺なら
// Magic
ってコメントにする。
Re: (スコア:0)
俺なら
// [usec]
だな
Re: (スコア:0)
コメント書くまでもなく最初からC言語だろ！
Re: (スコア:0)
修正後でもコメントのないマジックナンバー(1000000)は残ってんぞ。
> screen_priv->fake_interval = 1000000 / fake_fps;
つーか、直値とかよりも場当たり的に糞みたいな大域変数を追加してる方がひでーわ。
Re: (スコア:0)
hackって語源的にはそういうもんだからね
Re: (スコア:0)
どんな書き方をするかはともかく
初期値(省略値)は固定値でどこかに記述する必要があるだろ。
Re: (スコア:0)
そのことよりも、パッと見で、修正後の screen_priv->fake_interval が 60 Hz 時に 16667 でなくて 16666 を示すことが気になりました。修正前後で 60 Hz 時の挙動が変わらないことを祈ります。
Re: (スコア:0)
大体、何故INTEGERなん？DOUBLEの方が良くね？（門外漢的感想
Re: (スコア:0)
Apple「温度の値が華氏で飛び飛びになるくらいで大したことありませんよ」
Re: (スコア:0)
ハードウェアを動かすための精度が必要とされるクロック回路のPLL分周比の設定などでは無いので、16666でも16000でも大した変わりは無いでしょう
（用途を考えれば体感的に誤差を感じない程度でOK）
Re: (スコア:0)
ここでの問題は2つあり、
(1) 単位が不明であること
(2) 値の設定意図が不明であること
(1)については、時間長を表すユーザ定義型を作れば型検査の恩恵も受けられるようになり、例えばusec値をmsec値に代入するといったミスをコンパイル時検出できる。ただしCだと直接的な方法はない(structでそれっぽいことはできるが…)ので、次善の策としてコメントで単位をつける方法か。
(2)についてはdiffを見れば分かるとおりコメントで十分に親切な補足があり、「interval」と「60Hz」の意味が取れれば問題なく理解可能。ただこれは程度問題であるので、どれだけ詳しく書いたとしても、教条的に全部コメントに書かないと不満な外野が文句を言ってくる。実務上は、そういった声は適当なところで切り捨てることになる。
Re: (スコア:0)
一つ上のレイヤに移ると、「60Hzをこの場でハードコードすべきか」という問題が出てくる。この判断は存外に難しい。
マクロ化(名前付き定数化)する方法は安易に選ばれがちで、確かに可読性は上がるものの、識別子の文字数(安全範囲は32文字くらい?)でしか情報を伝えられない。それで足りなければコメントで補足する方法になるが、今度はコメントとコードで情報が二元化して経時で乖離する危険性が出てくる。
本件はフォールバック設定の話で、この値をこのソースファイル外部で使う状況は想定しづらい。したがって、コメント付きでハードコードする判断は適切であったと考えられる。
Re: (スコア:0)
もしかして、gotoを使ったら少し残念になったりします？
Re: (スコア:0)
goto は見通しがよい部分や狭い範囲で使うならいいんじゃない？
整理されていないコードに使う阿呆もいるけど、そういうのは戦力外。
Re: (スコア:0)
gotoを書いたときには見通しが良かったのでは