摩訶不思議なコードを書くプログラマ
■ このスレッドは過去ログ倉庫に格納されています
時間が無いとか、既存のクソコードの拡張で、やむを得ずクソコードを書くのではなく、わざわざめんどくさい書き方をするプログラマ
もちろん、パフォーマンス上の利点などがあるわけではない 実際のコードそのままではないが、大枠だけ抜き出すとこう
function xory(x, y, flag) {
var a = [x, y];
return a[flag];
} こんな単純な処理ならインライン処理でいいだろ
...
100 シキ RES=A
110 モシ FLAG=0 ナラバ160ニイケ
120 モシ FLAG=1 ナラバ150ニイケ
130 カケ 1,エラーデス
140 オワリ
150 シキ RES=B
160 ...
... >>5
これでヤバさが伝わらないのはお前がアホだからだよ xかyの2値のうちのflagの位置にある値を返すって処理だよ
処理の内容がflagって表現でぼかされちゃうな、
これを関数化するメリットってなにがあるんだ? 値の選択をifでやると複数行使うし、一行の中で三項演算子を複数使うと読みにくくなるから、全くナンセンスな書き方ではないと思うよ たいていのコードはビルド時に最適化されちゃうから
気にすんなって最近思うようになった
会社のレビューでもどっちが高速かと不毛な争いはしなくなったし
ひたすら読みやすいコードが良いって言う感じかなぁ 4と「flag ? a : b;」 が等価だと思ってるとしたら、プログラミングやめた方がいいよ >>19
うん、違うね
flag ? b : a;
だね なんかもう自分が認めたくないから追認を求る痛い女みたいになっとるね 駄目だこいつ
コピペプログラミングしかしてこなかったんだろうな 中学生ギークとかがイキっちゃって恥をかくパターン
チームで書くようになると背景や文化やトラブル耐性等のトレードオフを考慮するようになって、一意の正解なんて存在しなくなる チームの文化とか以前に、あなたは
if文(三項演算子)の動きが理解できていません まあ、trueが1であるかは処理系によって違うからなぁ 位置に値がない場合、三つ目の値(undefind)が返るからとか?
でも言語によってはバッファオーバーランになるぞ let person = null;
let name1 = person ? person.name : "Jane Doe";
let name2 = function(cond, a, b) { return cond ? a : b; }(person, person.name, "Jane Doe"); how do u think about "objects vs lambda (lexical closures)"? >>4
これはまったくナンセンスな関数というわけではない
ネストを増やさない利点があるし、場合によっては可読性も上がる
同じ処理が複数ヶ所にあるなら俺はレビューを通す そうなの?
関数呼ぶ時にはflagは決まってるから、わざわざ処理化するのは無駄な気もしますけど、 プログラミング完全に理解したと思ってる脱初心者くらいだとナンセンスなコードに見えてしまうかも 例えば処理速度みたいな観点で見た場合、ネストの深さと関数の呼び出しってどっちの方がコストが大きいんだ?
また可読性って観点で見た場合、関数を呼ぶ前にすでに得たい値が明確に決まってるのに、あえて関数でロジックを迂遠にするってどうなんだ? 速度はコンパイラの最適化次第だから擬似コードでああだこうだ言ってもしょうがない
4の関数と三項演算子でロジック的に違いそうなのは遅延評価がどれだけ効くかだけど、これも言語によって違うからなんともいえない
三項演算子が短絡評価にならない言語もあるし、関数呼び出し時に引数が評価されるかはもっと言語次第
で4だけど、仮にこの処理に相当するコードを[a,b](flag)と書ける言語だったとして、それを書き直させてxory(a,b,flag)にすることはありうるだろう
a,b,flagのどれが事前に評価されててどれを引数上で評価するのかとかは設計の問題だからなんとも言えないだろう
だから他人に4がクソコードかどうかなんてのは判断できないの
4がなんかJavascriptっぽいからJavascriptを前提に議論してほしいの!a,b,flagは必ず事前に評価されててここでは参照するだけなの!ってんならそもそもプログラマに向いてないよ >>39
自分がプログラマに向いていないことを長々と説明ご苦労さま 自分の書き方こそが正義!
そう思っていたことが私にもありました このスレは「俺ルールに反してる書き方」スレに変わりました コードレビューは規約に沿っているかどうかだけ判断すればよい
コードの読みやすさは偉い人の感想や声が大きい人の気分で決めていいもんじゃない
読みやすさなどという不確定で曖昧で根拠のないものは生産性の障害でしかない 三項演算子という言葉はIMEで変換すらできない
最大手の言語メーカーであるマイクロソフト製品ですらそうだ
それだけ存在感がないという事である
一方で三項演算子の歴史は古く、その批判の歴史もながい
それにもかかわらず新しい言語が出来るたびにほぼ必ずといっていいほど三項演算子は含まれているし
古い言語から三項演算子が取り除かれたというニュースを聞いたこともない
普段意識はしていないし、使ったことはないけれど
それを使っている人がいれば批判したくなる
それが三項演算子の現在の立ち位置だ
逆に普段から使っている人にとっては三項演算子は「普及していないが便利な機能」だ
数年前のラムダ式みたいなものだろう(数十年前だと主張する人もいるかもしれない)
あまり多くの人に使わない機能は知られてないというだけで不便なものである
言われのないバッシングを受けたり説明したり、コードレビューで議論しなくてはならないからだ
三項演算子を使わないほうがいい理由があるのだとすれば
それは三項演算子の機能や見た目、エレガントさなどではなく
その知名度や支持率の無さゆえであると言えるかもしれない >>42
正義というのは常に自分勝手なものである
アンパンマンは暴力でものごとを解決する
プリキュアは常に集団で暴行をする
悪人であっても懲らしめた後は許すという方針だった月光仮面は視聴率42%でも打ち切りになる
正義と暴力は同一のものなのだ
コードをどう書くかというのは保守性や学術的な議論ではなく
社内の力関係で決まってしまうということだ >>4のコードがコーディング規約によっては有りなんて考えをする人がいるのだから、日本の技術レベルが低いのは当たり前だわな >>2の正しさが証明されてるじゃん
ダメなプログラマは技術以前にそもそも現実世界の見方が歪んでいるから理屈で説明しても納得できないのだよ 三項演算子回避の方法として外観だけ観て言ってるだけだから >>48
コーディング規約はいわば会社の方針である
実際は他のやり方が正しいからといって会社に逆らってしまっては本末転倒ではないか? >>52
名無しでid非表示なんだから、恥ずかしくても知的障害起こす必要はないんだよ、 え、引数の事前評価っていうか、この関数呼ぶ時にはすでにxもyもflagもわかってるわけじゃん
この関数って動的に値を作るような動きはしてなくて、与えられた引数を与えられた条件に従って返してるだけで、なんか回りくどいことしてるなーって印象なんですよね、 >>54の理屈だとプロパティじゃなくてメンバ変数に直接アクセスしろって事にならんか?
プロパティじゃなくてアクセサに読み替えてもらってもいいけどさ >>55
オブジェクト指向だとしたらそのセオリーに従うけど、これただの関数ですよね、呼び出し元のルーチンがある
で、呼び出し元のルーチンですでにxもyもflagもわかってるわけですよね >>56
if (flag == 0)
{
hoge = x;
}
elseif(flag == 1)
{
hoge = y;
}
else
{
exception;
}
こんなのを該当箇所全部に書くの?三項演算子でワンラインにしてもいいけどさ
>>4だとどっちを選択するかのアルゴリズムが関数内に封じられてるからソースでflagの説明出来てるよ >>57
x,yをまとめるよね、そんでflagじゃなくてenumつかう どれも機械にとっちや似た様なもんだしなあ
人間様が(一集団内で)理解し易いかどうかだけの問題
あんまり拘るのも生産性に欠けるよなぁ
組織内で一様に書く為のコーディング規約から外れてるかどうかだけの問題だよなぁ enumってもう許されたの?三項演算子と同じぐらい嫌われてるもんだと思ってたが >>57
うわ
コードとセマンティクスが区別できずにオレオレ共通化するガイジだ >>4が次の2点について優れている
拡張性が高いところ、そして値のチェックがされているところ
例えばxとyのほかにzが出てきたとしよう
ほぼ全員が同じような修正をするはずだ
(ここのスレ民であれば全削除して書き換えてしまいそうだが・・・)
そして次にflagが0と1以外の値を取った時の挙動だ
(このスレはレベルが高いのでいちいち説明はしないがわざとそういう挙動にしているのだろう)
次に実際にコードを修正してみよう
xoryという関数をxoryorzに変更したのではないか?
ビルドすればエラーが発生するので1つずつチェックが出来る
これは便利だ(もちろん1つずつチェックする必要がなければ関数名そのままでもいいし
テキストエディタのリファクタリング機能を使って一括変更してもいいだろう)
集団でコーディングする場合に他の人がどんな風にふるまうかを考えて作られた素晴らしい関数だと思う
一見すると非効率で無駄なコードに見えるし、サンプル的な洗練されていないものに見える人もいたかもしれない
しかし、実際は全く逆で集団コーディングで様々な人たちに揉まれてきてたどり着いたかなり実戦的なコードなのは間違いないだろう
このコードを書いた人はかなり胃を痛めてこのコードにたどり着いたはずだ >>63-64
>>4のほうが優れてるよな
>>62は実行結果が変わってしまってるので(仕様がわからない現時点では)ダメだと思うよ if文の中でやりたいことは一つとは限らないのに
関数化とかアホでしょ よくわかんねーけど共通化どうこう以前にそんな判定処理を色んな所に書かなきゃいけない実装の時点で間違ってると思うのは俺だけ? 言語によっては条件演算子のtrue false2つの式を計算してから適切な方を返すこともある
例えばGPUを扱う言語なんかはifより条件演算子の方が適切なことが多い、GPUは同じ命令で大量の計算をするから分岐は命令の変更が生じてしまう、命令の変更をせずに両方計算する方が速いってこともある
似たような理由でifの条件評価より配列のインデックス指定で値を取ったほうが速いこともあるかもしれない、ただそんなことまで気にするほど大量の計算がある状況ってかなり珍しい気がする >>4みたいなのが実際出てくるとしたら、
元々xとyを両方使う関数があってそれを再利用してたが、結局片方しか必要無くなったから、引数で使う方を選択する
みたいな状況だろうか
もし、ゼロからこれを書いてきたなら、クビにした方がいいよ >>4は
flagの値の評価を外に任せてる点だけが引っかかるよ コード全文をみないと何とも言えないでしょ
極論だけど、同じような処理が同一ファイルに30箇所以上あって、
しかもこの処理をメソッドチェーンで呼び出した方が意味が通りやすいとかなら
アリだろう >>4に対して直感的に違和感を持つけど、状況限定でなくもないかな >>65
根本的にプログラマの素質の無い奴
混ぜるなキケン たぶん>>65はjavascript触ったことないな >>77
いないと思うだろ?
それがいるから困るんだよ そんなのflag ? y : x以外の書き方してたらはぁ?ってなるわw 摩訶不思議なコードは状況がわからないとなんとも
function isX(flag) {
return flag;
}
みたいなのだったら一見意味なくてもその後何かする予定とかあるし
ダメな人ほど大騒ぎするってこともあるし
実際のコードを見て書いた人に理由を聞かないとなんとも言えないな isで始まる疑問文はyes,noで返せと習わなかったか? flagは普通はbooleanだし言語もわからんし作法なんかいろいろあるわけで
駆け出しとかに限ってこう教わったから!みたいに暴れるやつがいる
必ずしも君ががそうとは言ってない
反論は英語でだけ受け付ける if( isX( flag ) ) { ... }
だよなふつう // ...
for(x in xs) {
// xの情報を、メンバー変数mに代入しながら、mを他のメソッドA, B, C, ...で弄るコード
}
// ...
void A() {
// mを弄るコード
}
void B() {
// mを弄るコード
}
void C() {
// mを弄るコード
}
こういう無駄にスコープを広げたがるやつの心理は本当に理解できない A() {
B()
}
B() {
C()
}
C() {
A()
} // 巨大なfor文の中
foreach (int i in int[] {xxx, yyy, zzz}) {
if (i == xxx) {
// xxxの処理
}
if (i == yyy) {
// yyyの処理
}
if (i == zzz) {
// zzzの処理
}
}
// ...
意図が全く理解できない for(i=0; i<100; i++){
いろいろとi番目の処理
// ある条件だったらカウンターを減らす
if(ある条件だったら){
i = i - 1;
}
}
見事に無限ループしてたよ 謎に見た目だからな
しかもこっちのが一番ショックなんだけどね。 ハガレンは昔のIP使う→遺産食いつぶしてるだけに適用するから、今から「トラック・特殊車両・作業車」は第一車線以外を走行禁止にするとか
かなりマージン取ってるていうから利用するだけだな ■ このスレッドは過去ログ倉庫に格納されています