09/11/29 03:40:28
いずれも何もそんなに時間かけないと判別できない奴が無能かと
113:仕様書無しさん
09/11/29 03:59:40
>>107
過去に政治的理由でバグごとコピペを強要させられたことがある
範囲選択した状態で挿入キー押すと落ちるってバグだったけど
そんな操作するヤツいないからコピペ先を修正したのバレるほうがまずいって
ところでプログラミングが下手の定義はそもそもなんなんだろう？
実装速度とか不良数とか可読性とか色々あると思うけど
下手の種類によって特徴も変わると思うんだ
114:仕様書無しさん
09/11/29 04:02:34
>>1によれば
プログラミングについて努力したにもかかわらず
それが実らないどころかあさっての方向になってしまう奴の
特徴のことなんだろう。
そんな奴いるかなあ。
そもそも明後日ちゃんは努力らしい努力してないし…
115:仕様書無しさん
09/11/29 04:13:36
>>112
時間かける以前にわかるまでバグ出させるってのが滑稽だよね
こういうヤツはバグ出す可能性が高いって特徴がわかれば
事前に警戒できるから、このスレ見たけど残念な流れになってるね
116:仕様書無しさん
09/11/29 05:19:46
わかるまでバグを出させるんじゃなくて
バグを出す奴が下手なだけなんだが
頭悪い奴が多いな
で、スポーツと同じで形だけ取り繕っても
下手は下手なので判断は無理だな
だから、こういう目に見えずらい実力を測るには
試しに試合させるのが一番だと書いてるんだが
117:仕様書無しさん
09/11/29 05:22:22
つーか、素振りだけで松井か一茂かを見分けようって
無理に決まってるのに
馬鹿かとw
118:仕様書無しさん
09/11/29 05:57:50
ソレは可能だろ
119:仕様書無しさん
09/11/29 09:43:43
>>41
これ、微妙な所だな
車輪の再発明はほぼ確実にバグ入れ込むことになるし時間かかるし
でも再発明は勉強になるのは確かだし
今のところ、仕事ではなるたけレゴブロック組み立てになるようにして
勉強目的では再発明もＯＫ で落ち着いてる自分
120:仕様書無しさん
09/11/29 09:45:32
ああでも再発明している時は勉強でも
「これより安全で高性能のがあるんだよなぁ」と虚しくなるときがあるな・・・
121:仕様書無しさん
09/11/29 11:32:06
>>116
バグ出すやつの特徴をあげるスレで
バグ出すやつの特徴はバグ出すやつなんて言っても意味無いよ
事前に見分けるのはムリなのが当たり前みたいに書いてるけど
そう考える理由を書かないと納得できないよ
試しに試合させるにしてもいきなり公式戦には出さないでしょ
じゃあどういう相手が実力を測る練習試合に相応しいかもわかるとよい
122:仕様書無しさん
09/11/29 12:21:24
>>121
野球の例えで悪いが素振りやバッティング練習で
場外ホームラン連発でも試合じゃからっきし駄目ってのがあるのと同じように
口が達者だったり、サンプルプログラムはバグ出さない人間と同じく書けても
本番でバグだらけのプログラムを書く奴はいるからな。
なので、疑似的なプロジェクトをやらせる位しかないだろうな。
コストに見合うかはシラネw
123:仕様書無しさん
09/11/29 12:28:23
つーか、プログラムの下手な奴の特徴を上っ面だけで判断するのは無理
判断出来るって奴は当然下手な奴を100%つかまないで
プロジェクトを進めてるんだろうな？w
124:仕様書無しさん
09/11/29 12:48:18
>>123
100%である必要はないんじゃないか
ヘタをつかむ確率が下がれば十分
上手いヤツを逃す可能性も出てくるけど
前者と後者の発生する確率のバランスに問題なければいい
あと目的はヘタをつかまないことじゃなくて
ヘタのバグを未然に防ぐこと
さすがにコイツヘタそうだからいりません、とは言えない
コイツヘタそうだから、気をつけてみておこうって持っていきたい
これも100%じゃなくて気をつける対象を決める精度があがればいい
これも無理と思うなら、そう思う理由を書いてくれ
125:仕様書無しさん
09/11/29 13:14:06
>>124
上っ面な事では100%どころか50%の精度も
出ないわけだがw
まあその程度の呪いレベルでいいなら
わざわざいろいろ書くまでもなく
職歴（と必要なら学歴）だけで予想出来るよw
126:仕様書無しさん
09/11/29 17:47:11
難しい部分は人にやらせる
127:仕様書無しさん
09/11/29 18:18:21
>>126
下手糞の方が役職が上の場合はそうなるなw
128:仕様書無しさん
09/11/29 18:21:14
下手なくせに難しい部分をやりたがる奴が多くて困るんだ。
129:sage
09/11/29 22:28:19
新規開発の経験がない連中ほどコーディング時の腕は低い
130:仕様書無しさん
09/11/29 22:31:17
↑名前間違えたのに自分で吹いたｗ
うちの後輩であげるなら、骸骨みたいな顔してる奴とか、(本人が)何かしゃべる毎に笑う奴とか頭からしてあれだな
131:仕様書無しさん
09/11/29 23:49:51
>>129
そうか？w
毎回スクラッチで開発してるのに成長しなくて
毎度毎度バグだらけの奴とか
結構いるぞw
132:仕様書無しさん
09/11/29 23:57:51
>>129
そこは原因じゃなく結果だと思う
腕が低い奴には新規はなかなか任せられない・・・
任せてみると>>131になるからなぁ・・・
133:仕様書無しさん
09/11/30 00:09:29
使用する言語のみの事しか知らない。
134:仕様書無しさん
09/11/30 13:16:47
・仕事以外でコードを書かない
・飲み会の話題が、濃い技術関連のものでない
135:仕様書無しさん
09/11/30 14:09:26
キモヲタの意見乙ｗｗｗｗ
オンオフ切り替えるのが仕事できる人間だよ
136:仕様書無しさん
09/11/30 14:16:05
仕事とプログラミングは違う
137:仕様書無しさん
09/11/30 17:05:00
・コードが見にくい
目が疲れないからって、黒バックに暗い色の文字でコーディングしてる奴がいるんだが、
単純な打ち間違いが多すぎ。
138:仕様書無しさん
09/11/30 18:05:31
特に黒字に緑文字だと最高にＤＱＮの可能性あり
139:仕様書無しさん
09/11/30 21:23:36
データベースを導入すると何か凄い事が出来ると信じている
140:仕様書無しさん
09/11/30 21:50:15
>>138
エエエェェェ～っっ
コボラー育ちなので昔のモニタのデフォってそれですよ。
自分もそれをベースにする方だｗ
141:仕様書無しさん
09/11/30 22:31:59
>>138
あれだよ
俺WinMX昔使ってたんだぜｗｗｗへいへい
っていう奴らがやってるよなｗｗｗｗｗ
俺は違法ソフトを使ってたんだぜ？すごいだろ！的な超ナルシストのやる事ｗｗｗでも顔は残念な奴が多いけど＾＾；
僕ちんもです＞3＜
142:仕様書無しさん
09/11/30 22:34:31
PC初期のころはグリーンディスプレイといって黒地に緑字は
普通だったからなー
143:仕様書無しさん
09/11/30 22:42:28
>>142
汎用機の端末はだいたいそれだったよ。
文字が黄色ってのもあったかな？
余りにも昔の事で忘れた。
144:仕様書無しさん
09/11/30 23:57:48
面倒な懐古厨の可能性あり
ひたすらコボル、Ｃ、フォートランなどをごり押ししてくるだけでなく
Javaなど90年以降の比較的歴史の浅い言語は使ってるだけで馬鹿にする傾向がある
145:仕様書無しさん
09/12/01 01:28:18
昔は、ちょっと年いった人に駄目呼ばわりしたもんだが、勉強すればするほど彼の取った非効率の理由が分かってきて、
俺って未熟だなーって感じたことがあるよ。
わざと自動化させなかった部分が、そこにいる運用メンバーの特性を考えてやってたんだなーって思ったときとか。
すぐに作りたがったり、効率重視な奴ほど未熟だと思う。
設計のできないやつは、どんなに見栄えの綺麗なプログラムを書こうがお粗末。
早さなんて、高校生や中学生のほうが早い。
瑣末な事象もいくつかみられるが、あまり基準の無い話をしてもしょうがなかろ。
書きかたの評価は可読性と保守性のことだとして、他に
・拡張性
・再利用性
・効率性
・信頼性
・完全性
・移植性
・試験性
・可用性
あと、工数などを基準にしてみようよ。
当然、要件やライフサイクルでウェイトが決まるのだろうけど。
あと、専門家なら論文やそれらの書籍を押さえておきたいところだ。
146:仕様書無しさん
09/12/01 02:03:15
>>142
俺が使ってたUNIX端末も黒地に緑だった。
当時はディスプレイの性能が悪くて、白地に黒だと異常に目が疲れたな。
>>135
君、プログラミングが下手そうだな。
147:仕様書無しさん
09/12/01 02:46:44
>>144
javaは駄目だろw
java厨必死だなww
148:仕様書無しさん
09/12/01 02:54:51
>>145
それらは全てどれだけ息の長いシステムかで
全て決まる
必要以上にする必要はそれら全ての項目について
全部必要ない
何故ならその工数の間にも他から新しいアーキテクチャも生まれるし
使いやすい環境も生まれるからだ
全ては時間との兼ね合いでそれがないものは
ただのオナニー
そして恐らく>>145はオナニー
考えてばかりいないで
さっさと作り終わるべきw
149:仕様書無しさん
09/12/01 03:53:22
こんなとこであーやこーや言ってる連中は
人間的に初歩的なミスしてバグってるけどな
俺もか 笑
150:仕様書無しさん
09/12/01 04:04:55
>>149
スレ違いの負け惜しみを吐くのは何故なんだぜ？w
それから人間的にバグってない奴なんか
ほとんどいないし、そんなツマラナイ奴は
たぶん幸せになれんと思うぞw
151:仕様書無しさん
09/12/01 04:07:10
きんもーっ
152:仕様書無しさん
09/12/01 04:19:31
プログラムが下手な奴だけあって
論理もへったくれもなく
グダグダになってきたなw
下手な奴はまあw
そういう事だよ
153:仕様書無しさん
09/12/01 09:09:25
速いと早いを正しく使えるようになってから偉そうなこと言え
154:仕様書無しさん
09/12/01 12:05:38
いちいち語尾に芝生を付けないと気が済まないのも修正してから偉そうなこと言え
155:仕様書無しさん
09/12/01 12:06:06
ここにも早く来てくれないかなぁ、優秀なエンジニアの君！
ほら、君だよ君！ 優秀なエンジニアの君の助言をここでも聞きたいんだぁ！！
188 ：仕様書無しさん：2009/10/22(木) 18:39:55
底辺=業界の標準みたいなのやめてくれるかな
俺は時給契約特定派遣だが3300あるぞ
ソフ開持ってて1000以下なんて死んだ方がいいレベルの無能なんだろ
156:仕様書無しさん
09/12/01 12:12:07
・英語ができない
・名前付けのセンスがない
157:仕様書無しさん
09/12/01 12:38:28
あー変数名・メソッド名のミススペルとプログラムの下手糞さには相関関係があるな
あとこのスレ向きじゃないが、変数名のプリフィックスに「the」を意味無くつけてる奴がいて
何がやりたいのか理解に苦しむソースコードだったなぁ・・・
158:仕様書無しさん
09/12/01 13:14:17
>>154
プログラムを書くのが遅いからって涙目になるのを
止めてから偉そうなこと言え
159:仕様書無しさん
09/12/01 14:22:12
>>157
> 変数名のプリフィックスに「the」
昔のMacはそういう流儀の命名規則が多かったような。
160:仕様書無しさん
09/12/01 14:28:44
theApp
161:仕様書無しさん
09/12/01 15:41:59
>>157
意味無くつけていたのならダメプログラマだが、ローカル変数にtheをプレフィクスとして
つける流儀は存在する。
引数やグローバル変数と見分けをつけやすいように。
ちなみに、関数内で値を変更しない引数にはinを、変更して返す引数にはoutをつけていたような。
162:仕様書無しさん
09/12/01 17:30:30
theAppは普通に使ってるな
163:仕様書無しさん
09/12/01 18:13:21
>関数内で値を変更しない
できれば言語でサポートしていて欲しいものだ。
(C/C++ の const 等)
164:仕様書無しさん
09/12/01 22:39:09
>>144
COBOL・C・VB.NET・Java・Perlその他少々を実務でやって来たが一言で言える事・・・
出来る人は何やっても出来る。
・・・自分は当てはまりませんが。
165:うゆ ◆e6.oHu1j.o
09/12/02 02:34:02
下手にも色々いるさ
書くのが遅いとか、ソースが酷いとか、完成させれないとか、
その程度は許すんだけど、
効率悪いことを平然と手作業でやってて、こっちが教えても理解せず、また手作業でやりはじめるなに考えてるかわからなくてしかもそれでいて口数も少なく、言うべきこといってこない奴は見捨てる
166:仕様書無しさん
09/12/02 04:30:31
「ら」抜き言葉を使うとか
167:仕様書無しさん
09/12/02 04:42:40
ネット上でだけ好戦的
まともな成果物なし実務経験すらなしで
自分は他の人よりできると信じ込んでいる
168:仕様書無しさん
09/12/02 05:33:37
まあいろいろとグダグダになってきたから定義からやり直すと
下手な人＝上手い人以外
とするか
下手な人＝普通の人未満
とするかで
大分違ってくるわな
169:うゆ ◆e6.oHu1j.o
09/12/02 22:20:47
効率悪いことを平然と手作業で行う
これに尽きる
170:仕様書無しさん
09/12/02 22:22:23
作ったマクロを整理できない
171:仕様書無しさん
09/12/02 22:48:48
整理にばかり気を取られて肝心の修正が遅れる。
・・・自分の事ですorz
172:仕様書無しさん
09/12/02 23:51:18
2chで糞レス連投
これが効率いいことなのか
アホコテさん
173:うゆ ◆e6.oHu1j.o
09/12/03 01:38:03
良レスだから問題ないと思うけど
どのくらいでFOXの堪忍袋が切れるのか試してるのもある
174:仕様書無しさん
09/12/03 01:56:17
ならもっと派手にスクリプト組んでばんばん投下しないとダメじゃろ
お得意のRubyの出番ですよ
175:仕様書無しさん
09/12/03 12:42:48
スクリプト組むぐらいしか能のない馬鹿Rubyが活躍するチャンスだな
176:仕様書無しさん
09/12/03 12:52:54
プログラミングが下手なやつって俺のこと？
大学時代C++で挫折して卒業後はシステム部門で運用監視系に入ろうと思ったら
バリバリの開発系（基幹システム内製）で1年くらいでやめてしまったよ。
もう、あんなとこ行きたくない・・・
キーボードすら触れなくなって、マジ辛かった。
深夜まで開発作業に没頭なんて嫌だ・・・。
みんな忙しくて誰も助けてくれなかった。
今は運用監視系ですけどね。
あのキツイ教訓のおかげで、無理や我慢はしなくなってしまった。
177:仕様書無しさん
09/12/03 17:28:59
運用監視ってただサーバーをぼーーーっと眺めてるの？
178:うゆ ◆e6.oHu1j.o
09/12/03 17:34:22
言語習得の段階で挫折したならやめろよっ
世の中にはな、
C++が初めから読める人間もいるんだ
179:仕様書無しさん
09/12/03 19:30:22
LISP如きで頭痛に苦しむアホも居るけどね
180:仕様書無しさん
09/12/03 20:24:22
C++読める奴が羨ましいわ
ちょっと複雑なテンプレートが使われてるともう何がなにやら
181:仕様書無しさん
09/12/03 21:23:41
ソースの読解力は場数で決まる
182:仕様書無しさん
09/12/03 21:32:19
きれいなもん見ないと
183:仕様書無しさん
09/12/03 23:06:38
>>181
だな
ぶっちゃけ読解力は汚いソースもたくさんみないと上がらない
スクラッチ開発しかしない奴とかは
総じて読解力が低い
184:仕様書無しさん
09/12/04 01:11:37
>183
そんなに俺を責めないでくれ・・・
185:仕様書無しさん
09/12/04 12:32:53
C++スクラッチか・・・
趣味も業務もC++はまともに書いたこと無いからな
186:仕様書無しさん
09/12/04 12:37:04
そんなにたくさん機能なくてもソフトは作れるからな
テンプレートとかイラネ
187:仕様書無しさん
09/12/04 14:24:46
>>186
C++のテンプレートなら、プログラムが下手な奴でも
マクロとしては使えるんで
使うといいよ
マクロすら使わずコピペしまくりなら
まあ残業頑張れ位しか言う事はないがw
188:仕様書無しさん
09/12/04 14:54:21
たまたま別プロジェクトのC++のテンプレートを作った人のコード見た時に
面白そうだから説明受けて、聞いた時は非常に便利そうだなとは思えたんだ
聞いた後に読んでみたんだけど、
でもループすらテンプレート化されてたんで
経験の無い俺には意味不明だった
189:仕様書無しさん
09/12/04 23:16:32
>>187
初心者がテンプレ使うのはやめてくれ！
190:仕様書無しさん
09/12/05 01:14:31
>>189
マクロ代わりに使われたテンプレートのソースも読めない奴は
マクロでも読めないから無問題
まあテンプレートを極めたソースは
必ず最適化を狙って書いてあるから読解は
多少困難になるけどな
つーか、本来そのための機能でもあるし
191:仕様書無しさん
09/12/05 01:38:57
テンプレートを
・仕組みを理解した上で使う → 素質あり
・仕組みを十分理解せず使う → 馬鹿
・使わない → 並
192:仕様書無しさん
09/12/05 02:04:18
>>191
テンプレートなんてここ数年間だけでも
機能が拡張され続けてるんだが
にわか丸出しだな
193:仕様書無しさん
09/12/05 02:15:57
テンプレートとは関係ないが、プログラムの下手な奴は
すぐに自分で把握出来ない量や質のプログラムを書いてバグの海に沈む
ってのはある
プログラムが下手な奴は
まず書かない努力から始めよう
194:仕様書無しさん
09/12/05 02:31:25
いや、仕事で書かずに、個人的な勉強のときにコード書きまくるのが正解。
あ、失敬。個人的な勉強なんてしないから下手なんだな。
195:仕様書無しさん
09/12/05 02:39:14
>>194
知識の仕入れ先はともかく試し書きくらいは
仕事中でもちょくちょくするわ、ボケ
つーか、家に必ず環境がある事が前提の仕事しかした事がない雑魚に
言われたないわww
196:仕様書無しさん
09/12/05 02:54:30
>>195
誰もお前のことなんか言ってないんだが。
まあ、自分が下手だって自覚してる分、お前はまだ見込みあるよ。
> つーか、家に必ず環境がある事が前提の仕事しかした事がない雑魚に
> 言われたないわww
プログラミングの上手い下手は、職場と全く同じ環境を揃えなくても、
ある程度は改善できるだろ。例え組み込み系だったとしても。
お前の仕事は何よ？
197:仕様書無しさん
09/12/05 02:58:30
個人的な勉強の時間を仕事の時間の中で取れるかどうかだな
プライベートの時間まで仕事のこと考えろってのはありえんわ
屑は仕事の空いた時間にゲームの攻略サイトとか見てる場合が多いわ
198:仕様書無しさん
09/12/05 03:03:50
>>196
アンカーをしてなくても俺しか関係のある
書き込みをしてねーだろ
お前に言われるまでもなく
お前よりプログラムは書けるよ
わけのわからない言い訳を書かない分なw
つーか、組み込み系？
お前のない知識の想像力で書いたのがそれだけなんだろうが
底が浅いのがばれるから止めとけよw
199:仕様書無しさん
09/12/05 03:08:08
>>198
いや、ほんとにお前誰だよ。
んで、仕事は？
IBMのiSeries上でRPGでしこしこ書いているとか？
200:仕様書無しさん
09/12/05 03:13:05
>>199
罠張るみたいな書き込みする奴だね、オマエ
お前が勝手に自己紹介を始めろよ
場合によっては書き込み方を変えてやるよw
201:仕様書無しさん
09/12/05 03:16:53
>>200
変な奴に絡まれたからもう寝る。
202:仕様書無しさん
09/12/05 03:29:48
人に聞いた質問を聞き返してやったら
逃げ出したでござるw
203:仕様書無しさん
09/12/05 08:36:13
会社ではゴリゴリcobol、
家では趣味としてC++で小物作り。
まわりにC++できる人いないから
情報源はネットと本だけ。
完全に独学だから仕事としてなら
使い物にならないだろうな・・・
例えばaが0のときの書き方は
!aって書くよりa==0って書いた方がいいよね？
204:仕様書無しさん
09/12/05 09:36:05
>>203
その選択肢、
signed a; a==0 or 0 == a 以外に何があるっていうんだ。
てか、プログラミングに独学以外ってあるのか？
純粋に仕事で覚えるのは独学に付け加える程度の知識だと思う。
逆に言えば、独学でウンコみたいな知識をつけていない限り、
仕事では独学してる人のほうが使えることが多い気がする。
ウンコみたいな知識ってのは、
コード書いてるそばから無用な速度や最適化のこと
考えはじめるとかね。
205:仕様書無しさん
09/12/05 11:57:30
>>204
独学only馬鹿の独演会とかいらないよ？
しかも自分は速度がきわめて重要な処理は書いた事がありません
って自白してるし
ただ>>203のコードは今どきなら
最適化がされて同じコードを吐くから
気にする事はないけどな
206:仕様書無しさん
09/12/05 12:11:56
ネットや本だけって、十分すぎるだろう。大抵の仕事はネットや本で片付く
問題はその内容だが
207:仕様書無しさん
09/12/05 14:49:15
>>205
速度が重要な処理は書いた事は… とりあえずはあると思う。
（文字のマッピング変換処理）
俺が言っているのは、たとえば
VB6でSelectステートメントが遅いから使うなとか、そういう類の。
そのステートメントが100万回呼ばれていて、
明らかにSelectステートメントのせいでシステムが遅いっていうなら、
Selectステートメントを使わないように直すに値するが、
そうじゃない限りは可読性のために使用を控えるべきじゃないっていう
ごくごく当たり前のこと。
ちなみに独学onlyバカってのはどういうことを言っているんだ？
208:仕様書無しさん
09/12/05 14:51:54
if (!strcmp(a, b))
209:仕様書無しさん
09/12/05 16:52:21
チェック系の処理でbooleanのt/f使わず
Stringで"OK"とか"NG"とか返してた。
210:仕様書無しさん
09/12/05 20:11:51
if (!!!a)
211:仕様書無しさん
09/12/05 23:09:19
>>209
困ったことに、それを == 演算子で比較しても、意図通りに動ちまうんだよな。
212:仕様書無しさん
09/12/06 00:02:21
if ("\0==0\" == "!=!"!!!\\0\0")
{
printf("私は変態だ。\n");
}
else
{
printf("変態は他にいるはずだ。\n");
}
213:仕様書無しさん
09/12/06 00:25:32
>>211
連中が、
new String("OK")やら
#intern()後じゃない外部からの入力文字列との比較で
上手くいかないことは 絶対知らないだろうなあ。
booleanじゃなくて、本来enumやint定数でやるべき種別定数を
Stringリテラルでやって、返り値を#equalsで比較してたのを
大手大規模PJの共通ライブラリで見たことがある。
なんていうか… 誰も突っ込まなかったのかよ…てｵﾓﾀ。
214:仕様書無しさん
09/12/06 00:33:50
取り敢えず文字列のハードコーディングは止めてほしいな。
215:仕様書無しさん
09/12/06 00:40:10
プログラミングが好きな奴は業務などの作る対象には興味がなくて、
まともに動かないプログラムを作ってきたり、
勝手に仕様を変えたりするやつがたまにいるんだが、
そのあたりは大丈夫か？
勝手に通信のインターフェース変えてきて「バカか？」ってやつもいた。
216:仕様書無しさん
09/12/06 00:51:09
いや、そいつは単純にバカなんだと思うよ。
217:うゆ ◆e6.oHu1j.o
09/12/06 01:21:17
いんじゃねｗ
218:仕様書無しさん
09/12/06 02:09:18
通信のインターフェース（ｷﾘｯ
219:仕様書無しさん
09/12/06 02:22:49
215 ：仕様書無しさん：2009/12/06(日) 00:40:10
プログラミングが好きな奴は業務などの作る対象には興味がなくて、
まともに動かないプログラムを作ってきたり、
勝手に仕様を変えたりするやつがたまにいるんだが、
そのあたりは大丈夫か？
勝手に通信のインターフェース変えてきて「バカか？」ってやつもいた。
220:仕様書無しさん
09/12/06 03:41:47
>>215
そいつは本当に「プログラミングが好きな奴」なのかね。
レスみた限りでは、「プログラミングできる俺を見てくれ的ナルシスト厨」の印象を受ける。
まあ、おまいさんがスキルの差を見せてやれば、おとなしくなるんじゃないかな。
221:仕様書無しさん
09/12/06 04:06:51
スキルの差なんてあるわけないおｗｗｗｗｗｗｗｗ
222:仕様書無しさん
09/12/06 12:43:59
■プログラマー暦3年以上で以下のうち１つでも当てはまれば危険
・コンパイルエラーとランタイムエラーの違いがわからない
・static(Shared)の意味が分からない。全部staticにする
・クラス、インスタンスが何かを知らない
・publicとprivateの違いが分からない。全部publicにする
・空文字とnull(Nothing)の違いが分からない
・嘘コメント、嘘変数名を多用
223:仕様書無しさん
09/12/06 13:06:30
>>222
さすがにそんな奴いないだろ。
と思う俺は恵まれた環境にいるのだろうか。
224:仕様書無しさん
09/12/06 13:09:30
> ・クラス、インスタンスが何かを知らない
クラスオブジェクト,インスタンスオブジェクト だろw
225:仕様書無しさん
09/12/06 13:14:52
そんなエサに釣られないクマー
226:仕様書無しさん
09/12/06 13:17:38
オブジェクトほど実体の無い言葉はないな
227:仕様書無しさん
09/12/06 13:32:08
クラスインスタンスはクラスインスタンスオブジェクトですか？
228:仕様書無しさん
09/12/06 13:46:34
> クラスインスタンス
ってオブジェクトは無いよw
229:仕様書無しさん
09/12/06 13:54:07
>>222
趣味でやってた頃はN88BASICが殆どだったから
知らなかった
オブジェクトの概念がある言語やったらすぐ理解できたけど。
230:仕様書無しさん
09/12/06 15:00:24
> null(Nothing)
え
231:仕様書無しさん
09/12/06 17:21:44
クラスはクラスクラスのインスタンスです
232:仕様書無しさん
09/12/06 18:43:06
オブジェクト、クラス、インスタンスは、
Windows API の名前でさえ誤用されているところがあるぐらいだから、
そんなに突っ込まんでもええやろ。
233:仕様書無しさん
09/12/06 18:44:11
C言語だとオブジェクトの定義って変数の値のことだっけ？
234:仕様書無しさん
09/12/06 18:46:04
オブジェクトの定義なんて存在しない。
235:仕様書無しさん
09/12/06 19:14:53
名付け方がおかしい。
処理を開始するメソッドにPlayとか勘弁してほしい。
綴り間違いも。
CacheがCashになってたり。
236:仕様書無しさん
09/12/06 20:17:51
>>235
こういう名前付けのセンスは色々なライブラリを見て、その命名規則の
エッセンスを吸収しないと身につかない気がする。Play以外のよい言葉が
思いつかなかったんだろう。
237:仕様書無しさん
09/12/06 20:50:17
var000, var001, ... , var999, var000a, var000b, ...
こういったレベルの高い命名規則もあるようですね。
238:仕様書無しさん
09/12/06 20:53:25
>>234
言い方が悪かったかな。
今K&Rの後ろの方の説明みたら
きちんとオブジェクトについて書いてあったよ。
オブジェクトというのは、
メモリ中のある場所にある値（＝変数）のことだね。
俺はJavaから入ったから、クラスもないのに何でオブジェクト？
ってC学びたての頃は思ったものさ。
239:仕様書無しさん
09/12/06 20:53:27
難読化技術？
240:仕様書無しさん
09/12/06 20:57:53
>var000, var001, ... , var999, var000a, var000b, ...
>
>こういったレベルの高い命名規則もあるようですね。
レベルが高すぎて泣けるｗ
どの変数をどこで使用してるか全て把握できてるなら神レベルだわ。
241:仕様書無しさん
09/12/06 21:33:36
>>240
場合によるな一覧表とか作ってくれてて
紙で３ページぐらいになってる開発に参加したことあるけど
３ヶ月もすれば番号みただけで内容言えるようになるぜ！
・・・そんな必要ねぇんだけどさｗ
242:仕様書無しさん
09/12/06 22:04:48
プログラマなら
var000～varFFFまで作れよ
243:仕様書無しさん
09/12/06 22:47:32
>>237
昔のFORTRAN、BASIC、アセンブラのように、ローカル変数が使えないような言語の場合は、それなりの合理性がある。
特に、大規模なプロジェクトで。
１，２ケタ目がプロジェクトやチームを表し、サブルーチンのネストレベルに応じて桁を変えたりとか。
２文字とか６文字といった短い変数名しか許されないところでそれをやるので、
もとの意味が想像できないような略号から命名するよりも、表から探しやすい名前のほうがやりやすい場合もある。
244:仕様書無しさん
09/12/06 23:14:17
リファレンスを読まない、調べない
func(int)の引数に平気でStringぶっこんでたり
245:仕様書無しさん
09/12/06 23:17:47
>>237
真の恐ろしさは「999」以降の命名規則の謎具合だな
>>242
プログラマなら3桁8進だろｊｋ
246:仕様書無しさん
09/12/06 23:20:14
>>238
今回の場合は間違っちゃいないが、そこはせめてJISあたりを挙げるといいよ
247:仕様書無しさん
09/12/11 16:36:07
今更だけど。
>>46
>バグがいかにも出そうなコーディングしてても集中力がすごくてバグを押さえこむ人もいる
これって、歳喰って衰えると破綻するよね。
248:仕様書無しさん
09/12/14 09:52:08
>>242
不必要な数の変数を作る方が駄目でしょ
249:仕様書無しさん
09/12/14 20:33:32
>>247 の意見は>>46の言ってる奴が年とともに成長/洗練されないことを
前提にしてるよね。
250:仕様書無しさん
09/12/14 23:09:05
>>247
結構経験がもの言って歳食ってもなんとかなるみたい
普段はまあまあプログラミングに興味もってる若手がこの手のソースの解析に音を上げて
この手のソース書いたのと同世代のベテランにバトンタッチしたら、すらすら読んでた
職場内の技術力の統一は大切だと思った
251:仕様書無しさん
09/12/15 00:07:47
低い方に統一されなければいいんだけど…
252:仕様書無しさん
09/12/15 16:56:42
>>249
処理が書き方で簡単に見えるなんて
まだ低レベルの奴が考える事なんだよ
253:仕様書無しさん
09/12/16 03:02:58
コーディングの常識・非常識が、時代の移り変わりとかでまるっきり逆転する事があるからねー。
「NULLと書くか0と書くか」や「マクロの是非」とか。
254:仕様書無しさん
09/12/16 15:49:15
まぁ、今も昔も「他人が読むよ」ってことを意識しないプログラムを書く人が下手ってことでいいだろうさ。
コーディング技術はあっても、未来永劫書いた人がメンテするわけではない。故に付帯する資料や設計書、コメントが
重要になってくるわけで、プログラムそのものよりもそういったことがおろそかな人のプログラムは総じて落第点を。
255:仕様書無しさん
09/12/16 16:12:49
未来永劫誰かに読まれるわけでもないがな
256:仕様書無しさん
09/12/17 17:20:58
最終的に動けばいいや程度の要求だから
257:仕様書無しさん
09/12/17 22:33:47
逆に考えてみ、他人に見られる事を意識したプログラミングをして来なかったから未だに誰にも読まれないプロクラムを書いていると。
頑張っていい仕事してください
258:仕様書無しさん
09/12/17 22:50:47
最初に見たのがひどかったからとか
259:仕様書無しさん
09/12/17 23:01:11
どっちにしても、あとで作り直さなきゃいけないけど、
きれいで使えないものを作るやつよりも、
汚いけど使えるものを作るやつのほうが役に立つ。
260:仕様書無しさん
09/12/17 23:29:56
きれいで使えないって何？
261:仕様書無しさん
09/12/17 23:30:32
ジャイアン
262:仕様書無しさん
09/12/17 23:40:23
俺の場合、本当にきれいなものを作りたいなら、プロトタイピング方式しかない。
しかも、最初に作ったプロトタイプをぶっ壊すタイプの。
作っては怖しを２，３ループ繰り返せば、それなりにキレイにできる。
でもそんな手間隙かけてられない
263:259
09/12/17 23:41:05
>>260
ソースはきれいだけど完成しない人って意味のつもりだったんだけど、
それじゃ作ってないね。
264:仕様書無しさん
09/12/17 23:44:49
某OSやブラウザなんて何度ループしてもキレイじゃないじゃないか
265:仕様書無しさん
09/12/18 00:02:58
>>263
完成してなくても許されてんの？
リリースとかどうすんだろ。
266:仕様書無しさん
09/12/18 00:06:41
完成されたプログラムなんて無い
267:259
09/12/18 00:11:07
>>265
だから役に立たないんじゃん。
268:仕様書無しさん
09/12/18 00:12:54
>>267
なら辞めさせれば？
269:仕様書無しさん
09/12/18 00:14:42
>>264
ぶっ壊せばきれいになるかもしれない
。
270:仕様書無しさん
09/12/18 00:15:08
新人のうちならいいけど
それならそれで最後まで作らせてやるわ
271:仕様書無しさん
09/12/18 00:22:43
できあがった時が納期か
最高の環境だね
272:仕様書無しさん
09/12/18 11:18:47
そして、よくわかんないで、その場しのぎの修正をしていくんですね
273:仕様書無しさん
09/12/18 12:27:34
で、うっかり
URLﾘﾝｸ(www.itmedia.co.jp)
なんてことをやらかしてしまうと。
274:仕様書無しさん
09/12/19 09:34:41
>>272
こない未来を勝手に予想して
見えない大きな敵と戦ってる奴をドンキホーテと呼ぶ
275:仕様書無しさん
09/12/19 15:00:24
未来がわかるんですか？
276:仕様書無しさん
09/12/20 09:50:46
>>275
それは>>272にいってやれｗ
277:仕様書無しさん
09/12/20 15:22:41
プログラマーが悩まなくていい仕様書やシステム（環境）を作れってことだな。
278:仕様書無しさん
09/12/21 10:31:02
ソースコードを日本語に書き下したレベルのものを仕様書にすれば
プログラマは全然悩まなくてよくなるお
279:仕様書無しさん
09/12/21 10:34:08
UMLのクラス図で書いとけば、コードまで落とせるから
そのうちPGは減るかもねｗ
280:仕様書無しさん
09/12/21 16:20:09
UMLを作る分の工数が増えるから人が増えるんじゃね？
281:仕様書無しさん
09/12/21 18:20:28
実装方法とか知らん奴の書いたUML使えるの？
282:仕様書無しさん
09/12/21 19:50:43
そのUMLの仕組みで目的の機能を達成できることを確認する手段が無ければ
ただの絵空事でしかない。
283:仕様書無しさん
09/12/22 22:49:51
駄目だｗｗｗｗｗｗｗｗ
今日もプログラム完成しなかったｗｗｗｗ納期が過ぎているのにｗｗｗｗ上司の残念そうな顔拝めちゃったｗｗｗｗ
284:仕様書無しさん
09/12/25 21:17:54
ひぎぃｗｗｗｗｗクリスマスパワーでも間に合わなかったｗｗｗｗｗ
どうしようｗｗｗｗ上司が失望してたぴょんｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
285:uy ◆e6.oHu1j.o
09/12/28 00:58:52
そんな事よりカラオケいこうぜ
286:仕様書無しさん
09/12/29 10:53:30
ふぅむ、このレスの中から有益なことを抜き出すのは大変そうだなぁ...
287:仕様書無しさん
09/12/29 12:12:37
んな暇あったら他のコトしたら？
288:仕様書無しさん
09/12/29 23:55:27
参考にできるgeekが周りにいない
289:仕様書無しさん
09/12/30 18:10:23
>>288
じゃオプソのソースでも嫁
290:仕様書無しさん
10/01/14 22:19:37
４テーブルを更新する処理がまったくチンプンカンプンになってしまったｗ
お前らって４テーブル更新とかちょちょいのちょい？
291:仕様書無しさん
10/01/14 22:32:50
PGって専門学校以下が多いん？
292:仕様書無しさん
10/01/14 22:44:50
学歴で才能を測るのは、新入社員のときだけですよ
293:仕様書無しさん
10/01/15 00:21:37
大卒だろうが専門学校卒だろうが、底辺は似たようなもん。
トップを比較すると、大卒>>専門学校卒だな。
294:仕様書無しさん
10/01/16 20:48:10
はー？ ３流大か１流大かで違うだろ ３流イラネーなｗ
295:259
10/01/16 23:28:28
>>294
この世界では、違わんかも知れん。
使えん一流のほうが、無茶な処遇ができなくて処分が難しい。
296:仕様書無しさん
10/02/18 23:52:27
どんな学歴の持ち主だろうが、使えないヤツは使えない。
変なプライドだけいっちょまえでたちが悪い。
297:仕様書無しさん
10/02/19 23:11:26
雑草魂のバカも結構たちが悪い
298:uy ◆e6.oHu1j.o
10/03/06 22:53:33
ほんと、プログラミングの世界で学歴をごそう大事に持って離さない奴って
それ以外に何も無いんだろうなって思う
ROでいうと、
高学歴は、古い紫色の箱（購入費用250k）で、
低学歴は、古く青い箱（購入費用40ｋ）みたいなもんだな。
結局、その箱開くまで（入社して仕事させるまで）、中身はわからない
確率的には紫箱のほうが中身が良いだけ
299:仕様書無しさん
10/03/06 23:11:37
天才プログラマには数学の素養が必要。
高学歴は天才に化ける可能性があるが、低学歴は土方どまり。
300:仕様書無しさん
10/03/07 03:53:13
高卒DQNは大変だな
「ごそう」ってなんだよ
日本語もわからんのか
301:仕様書無しさん
10/03/07 04:02:18
後生？
302:259
10/03/07 07:51:11
経営者は人を動かす才能が肝だが、プログラマは人智がおよぶ問題の回答を正確に早く作るのが仕事。
303:仕様書無しさん
10/03/07 07:54:24
きれいで使えないって、センスがないってことじゃ
304:仕様書無しさん
10/03/07 08:36:18
>>300
麻生だから後生なのか……
それは思いつかなかったｗ
305:仕様書無しさん
10/03/07 11:07:41
>>299
大半、高校の数学＋αでどうにかなるよ。
線形代数かなんかは適当に自分で勉強すりゃOK。
306:仕様書無しさん
10/03/07 13:23:20
>>305
ここで言う数学は、数学的論理思考のことだろ
307:仕様書無しさん
10/03/07 14:16:43
数式が使えないと行き詰まるよ。
308:仕様書無しさん
10/03/07 14:27:35
>>307
ジャンルによるんじゃん？知り合いで社交性だけが売りで
プログラミングてんでダメなヤツがいたけど、結構出世してるよ。
あ。プログラマとして行き詰まるのと、社会人として行き詰るのは違うか。
仕事でやる場合、技術的に行き詰るほど高度な要求が来ることってあまりない気がする。
309:仕様書無しさん
10/03/07 14:47:46
>>308
そりゃ、プログラミングだけできるやつが出世する見込みは０だ。
310:仕様書無しさん
10/03/07 16:37:39
「エンジニア→マネージャ」しかキャリアパスがなければそうだな。
日本じゃだいたいそうだろうが。
熟練プログラマも、マネージメントなんぞやりたくないだろう。
311:仕様書無しさん
10/03/07 22:32:04
>>306
公理的集合論とか不完全性定理でもやればいいのか？
312:仕様書無しさん
10/03/07 23:00:29
>>311
良いプログラマは数学を学ぶ、方が良いと思う
URLﾘﾝｸ(www.mars.dti.ne.jp)
313:仕様書無しさん
10/03/07 23:03:31
>>311
TOPCODERに参加すれば、数学的センスの必要性を思い知るよ
314:仕様書無しさん
10/05/27 17:46:10
URLﾘﾝｸ(jigokuno.img.jugem.jp)
315:仕様書無しさん
10/05/27 18:03:22
プログラマでいる間は幸せだよ。
お客さんでも、上流工程の連中でも、下流工程の連中でも、
仕事でコミュニケーションとる相手は大抵システムと関係あるから
ある程度の意思疎通ができるし、話せば話しただけの価値と楽しみがある。
マネージャになると、カネの数字にしか興味ない経営者とか、
仕事を依頼しても絶対に「はい」という返事をしない総務とか、
現場の状況を見もしないのにプロジェクト運営にケチつける品質管理とか、
そういう連中とのコミュニケーションを軸足にして仕事をしなければならない。
唯一の楽しみが、技術屋の部下連中と技術面の話をする時だ。
正直、技術屋の中からマネージャに昇格させるというのは、
悪しき習慣だと思う。
316:仕様書無しさん
10/05/27 18:34:28
長い
317:仕様書無しさん
10/05/27 19:44:32
まとまった文章を読む力のない馬鹿にロクなコードは書けない。
318:仕様書無しさん
10/05/27 22:46:36
プログラムの上手には2通りあると思うわ
１．論理に美しさを求める人
２．ハッカー的な人
前者は整然とした綺麗なコードを書く
後者は見た目は汚いようでいて最小のコードで仕事をする
数学者とコンピュータ好きの違いか
319:仕様書無しさん
10/05/28 09:55:17
美しく、かつ最小のコードで。
320:仕様書無しさん
10/05/28 11:51:11
まともなテストケースを書くことが重要。
321:仕様書無しさん
10/05/31 08:52:22
メインテナビリティが一番
322:仕様書無しさん
10/05/31 10:11:34
結局俺最強っていいたいだけ
323: ◆rT33C51l9k
10/06/08 19:05:10
>>319
こいつは何もわかって無い馬鹿
現在のゴミみたいなプログラミング言語では
どれを使ってもそれはできない事になっている
ソースは俺
324:仕様書無しさん
10/06/08 19:06:31
実践して理解していないのに専門用語を並べる人
325:仕様書無しさん
10/06/08 19:07:12
人に指示する際、妙な感じで威圧感出してくるタイプの奴
326:仕様書無しさん
10/06/09 00:32:15
下手な奴って自分でもプログラマ向いてないの分かってるよな？何で辞めないんだろう。
327:仕様書無しさん
10/06/09 00:42:52
新卒で騙された人らは結構いるかと思う。
特に地方の人らが東京に憧れて、PGの求人に応募しちゃった系じゃないかな？
そういう奴いっぱいみてきた。
328:仕様書無しさん
10/06/09 00:45:13
ニートやるよりマシ。ただそれだけでしょ。
生きていく(カネ稼ぐ)ためには、ヘタだとか向いてないとか二の次になるんですよ。
それなりに稼げるのならば、リスクをおかしてまで辞める理由などない。
そういうひとは、プログラマに限らずあらゆる仕事が向いてないんだから。
329:仕様書無しさん
10/06/09 00:49:22
プログラマが底辺の受け皿になったのが痛いな。
330:仕様書無しさん
10/06/09 00:51:08
一人一人に何万円もする開発環境をあてがわないといけないようなスタッフを底辺と呼ぶのか
331:仕様書無しさん
10/06/09 00:54:25
アホが書いたソースは何年も後任を苦しめるな。もう新規作成以外ではプログラマなんてやりたくねえ。
332:仕様書無しさん
10/06/09 00:54:59
大体リースだよ。
すぐに入れ替わるからそんなにコストかからんだろう。
333:仕様書無しさん
10/06/09 00:57:48
会社に1名しかいない社内エンジニアの後任とかまじでこええ。。。
334:仕様書無しさん
10/06/09 09:12:10
俺はそうだったが何か？
前任者が異次元世界の住人になってしまったとかで、代わりの人を求めてあっちこっちに声を掛けていて、
俺は前んとこをやめたくてあっちこっちに求人はないかと声を掛けていて
それが合致したのが20年前。
335:仕様書無しさん
10/06/09 12:05:52
de?
336: ◆6kL2kv.qdA
10/06/09 17:13:27
>>331
ゴミみたいな奴だな････
最近のクソゴミPGは「 元のソースが酷いから読めない 」っていう言い訳が流行中らしいな･･･
便利な言い訳だな････
自分の技術力のなさが第一の原因なのにすべてを前の奴のせいにできる･･･
ゴミみたいな奴だな
337:仕様書無しさん
10/06/09 17:21:29
まともなテストケースがあれば、中身を読む必要なんかあまりなんだけどね。
338:仕様書無しさん
10/06/09 17:39:20
>>331
新規作成でも回避できない場合もある。
ただ、時間をくれてリファクタリングさせてくれる会社だと尚良い。
339:仕様書無しさん
10/06/09 18:14:25
自動テストがエラーを報告するようになったとき、
テストケースを修正するべきなのか、コードを修正するべきなのか
わからんから、結局中身を見ることに。
340:仕様書無しさん
10/06/09 18:24:57
>>339
それはいったい何を作りたいんだ。
341:仕様書無しさん
10/06/09 21:22:02
天狗の仕業ってなにそれ？
マイクロソフトの連中は、バグだらけのコード普通に沢山書くぞ
ていうか、あいつら仕事してんの？
342:仕様書無しさん
10/06/09 21:27:20
ノートン360は絶対買わないと思ってたんだけど
ヨドバシの店員がかなり速くなりましたよ。と自信持って言うから
買ってしまったんだけど、酷い重すぎるね。ずっとバックグラウンドで何かしてるよ。
これ訴えられないかねえ？
てかムリグリスレにあわせるとsymantec社も酷いコード臭い
343:仕様書無しさん
10/06/09 21:27:32
本社にはちょっとはマトモなのいるんだろうけど
MSKKにはゴミみたい社員しかいないと思うよ
344:仕様書無しさん
10/06/09 21:29:15
どっちにしろMSの書いたソースはストールマン並にきたねぇよ
345:仕様書無しさん
10/06/09 22:46:11
新規案件しかやらないから他人のゴミソースは読まないな。
たまにVB6から.NETへのリプレイスなんかで
過去のゴミソースを読んで仕様を把握しろとか言われるが、
糞すぎて俺様の時間を使うのはナンセンスだと言ってそこらの外注にやらせるよ。
>>336
糞な仕事しかしてないんだなぁ。
まぁせいぜい他人のゴミソース読むスキル上げてろよ。
346:仕様書無しさん
10/06/09 22:48:18
>>345
俺は自信もって言える！
ゴミソースのリファクタリングだけは速くて上手い。
6割近くがこんな仕事ばっか。。。
347:仕様書無しさん
10/06/09 22:49:49
>>345
新規なんて誰でもできる。お前みたいなアホPGにでもな。
他人のソースを読んで意図を理解し、新たに書き直すのでは難易度が違う。
お前のような雑魚には無理だ。
348:仕様書無しさん
10/06/09 22:51:39
はは、新規にゴミソース作るのは誰でも出来るわな。
お前らレベル低そうだなぁ。
349:仕様書無しさん
10/06/09 22:52:19
難易度が違うｗ
それ、ただの雑用だからｗ
350:仕様書無しさん
10/06/09 22:53:40
>>350
くそぅ。仕事がなくなってから言い訳すんじぇねーぞぅ
351:仕様書無しさん
10/06/09 22:56:13
仕事が無くなる前にプログラマはやめる。
システム開発のプログラマなんて高卒でも出来るから、
どんなに質のいい物作っても大して評価されん。
352:仕様書無しさん
10/06/09 22:58:44
351はどんな風の人かなんとなく想像できた。
たまにいる偉そうな奴だな
353:仕様書無しさん
10/06/09 23:00:38
リアルではそう思われないように気を付けるよ
354: ◆6kL2kv.qdA
10/06/10 00:00:23
>>345
ゴミみたいな奴だな････
355:仕様書無しさん
10/06/10 00:08:39
>>345の作ったゴミ
↓
リプレース
↓
>>345「こんなゴミ改修できね」
↓
外注がエクセレントに改修
↓
以下ループ
356:仕様書無しさん
10/06/10 00:22:24
視野が狭いし自分の世界を否定されるとムキになる。
底辺PG丸出しでワロタ。
357:仕様書無しさん
10/06/10 00:39:42
>>345は本当に出来るタイプなのかもしれないけれど、
大半が、社内では一番優秀だと思われているだけの井の中蛙タイプじゃないかな
新規で作ったシステムはどうしても否定できる部分があるもんなんだよ。
3回程度作り直す時間があるような案件ならそこそこの出来でいけるかもしれないけれど。
358:仕様書無しさん
10/06/10 00:51:09
>>351
んなこたない。
高卒じゃgoogle入社は難しいだろ？
359:仕様書無しさん
10/06/10 00:54:42
100％とは言わないが、MSやGoogleのPGはそこらの企業のシステムなんて作らないだろ。
逆に日本のIT土方は、殆どが企業システム作ってる。
MSやGoogleにいるような天才PGが作った物を利用してね。
日本のPGはまさに土方でアホでも出来る。
360:仕様書無しさん
10/06/10 00:57:59
MSに入って.NETの設計したい。.NETの設計者天才すぎるから思考回路盗みたいぜ。まぁ無理だけど。
361:仕様書無しさん
10/06/10 01:03:50
誤解されないように言うが、俺は能力の高いPGは評価するし尊敬している。
システム開発のPGでも、化け物みたいに出来る人ってたまにいるからな。
だがしかし、それがあまり評価されないという現実があるから悲しんでるんだよ。
362:仕様書無しさん
10/06/10 01:11:16
糞企業のためにPGやるなんて馬鹿だからやめとけ
何処行っても扱い同じだぜ特にMSKKとかなMSKK
363:仕様書無しさん
10/06/10 05:22:42
>345
それ屑ニートだから
仕事なんてしてないから
未経験だから
364:仕様書無しさん
10/06/10 08:06:53
>>359
>日本のPGはまさに土方でアホでも出来る。
これはわかるわ
たしかにＭＳのツールとか作るなら天才ＰＧ必要かもしれないけど
それを使う側に天才はいらんわ
ホント、俺等がやってる仕事って誰でもいいよね
365: ◆6kL2kv.qdA
10/06/10 11:31:18
そうやって天才天才あがめてるところが･･･ ｯﾌﾟwwww
もし、リアルでもそうやって
「天才」とかいうワードをもろにだして会話してんなら引くわ
366:仕様書無しさん
10/06/10 12:17:12
自分のこと棚に上げるのはやめようや
367:仕様書無しさん
10/06/10 12:36:03
鬱病って
まともな会話が出来ないらしいけどまさにそうだな
>>365-366
で会話が続いてるようで続いてないし
368:仕様書無しさん
10/06/10 18:12:51
過去に、俺はほかのヤツより優れてると言いまくってたコテだろ、それ。
369:仕様書無しさん
10/06/10 19:24:56
>>365
お前、全くまともに反論出来てないな。相当頭悪いとみた。
よくもまぁコテなんてやれるもんだ。いつも内容の無い糞レスだけだろう。
370: ◆6kL2kv.qdA
10/06/10 20:17:31
天才･･･
とかいっちゃってる奴って 自分の頭が悪いだけなのであって････
早く気づけよカス
371:仕様書無しさん
10/06/10 20:20:01
>>370
この流れではちょっとできる奴を便宜上そう表現してるだけ
そこにこだわってるのはお前さんだけなんだが・・・
372:仕様書無しさん
10/06/10 20:24:23
よくいるよな、どうでもいい所に異常に拘る雑魚PG。
373: ◆6kL2kv.qdA
10/06/10 20:47:07
あの程度で天才とか言われてる奴を見ると
じゃあおれはなんなんだろう？ って思い始めるからやめろ
374:仕様書無しさん
10/06/10 21:01:51
正直さ、
あのサービスを一人で作った天才PGとか
本書いて偉そうになってる人とかいるけどさ
実際の所はもっと凄い奴いっぱいいるよな？
運とか売り込みが上手だったとか人より努力をしたとかそういう差なだけだよな本当は。
マイペースでやる多くを求めない才能あるPGってのも実際いるよな。
375: ◆GtN0Plfghk
10/06/10 22:49:27
有名になる事や、多くの人に見てもらうことに魅力を感じるような、「ひと握り」の人間の中で、
優秀だった奴が、天才と呼ばれてるだけ
実際のところ、戦争でも起こって、
優秀なPG以外は全員前線に送られるくらいの修羅場にならないと
本当に優秀な奴の大半は世にでてこない
自分の力は、自分の生活を楽にすることにしか使わないで、一生を終えるパターンが最も多い
そういう隠れた優秀な奴からすると、
世の中でちやほやされてる「天才（笑）」みたいな奴って、そいつの瞳には晒し者にしか見えてない･･
けれど、「この程度で天才とか･･･ｯﾌﾟwww」 とか、思ってるだけじゃないといけないんだよな
口にしちゃうと嫉妬にしか見られないから
本当の天才のジレンマはあると思う
けどそういう奴って、少し話せばすぐに分かる
あ、こいつ真理まで辿り着いてるな、
真理まで、あと少しだな って
376:仕様書無しさん
10/06/10 23:12:34
自称天才の中二病らしい文章だわ
377:仕様書無しさん
10/06/10 23:22:02
ここまでの天才コンプレックスも珍しいな。
見ているこっちが恥ずかしくなるレベル。
378:仕様書無しさん
10/06/10 23:28:53
天才っていうかでも人間だから頭脳の差って結構あるよな
好きなだけでプログラミングやってるやつとか
好きなくせにたいして上達しないし
379:仕様書無しさん
10/06/10 23:35:53
プログラミングを追究した者達は途中必ず一度気づくと思う。
俺なんか違うわ。と
380:仕様書無しさん
10/06/10 23:45:12
余程のバカじゃなければ2、3年で向き不向きは悟るだろ。
プログラム能力ってほんと人によって差が激しいからね。
381:仕様書無しさん
10/06/11 00:22:41
>>380
向き不向きの違うわじゃなくてさ、追究すべきじゃないって結論に至ったといいたいんだよ。
結局正解なんてないんだよ。
382:仕様書無しさん
10/06/11 01:54:29
勝手な解釈、個人的独断で話すと、
納期の厳しい状態の案件に対しての対応法として私が結論として至ったのは
とりあえず動くだろうコードを関数思考で書く。要求は満たす。
それをパッケージ化しつつ、MVC分離やセキュリティ対策を踏まえ再度作り直す。
作り直してからもう一度見直し、SQL文は外部ファイルに纏める（利用されているSQL文をコードから探しこむのがめんどいので）
コードに対するセキュリティに関してはまだまだ完璧な状況ではないので、これも別ファイルで汚染文字を簡単に追記するだけで対応できるようにしておく。
最初に処理されるコードを単純化するようにする。
1つのオブジェクトは100行程度の簡単なつくりにする。
結論スパゲッティになって理解不能になっていくのがわかる多重継承などはしないようにする。
みんな楽しようとしすぎでさ、オブジェクト内で他のオブジェクトとの依存しすぎで、作った人間しかわからなくなっていく。
作った人間も忘れてしまってひっちゃかめっちゃかになってしまう。
383: ◆fMBIUkSmfQ
10/06/12 15:17:43
>>381
真理まであと少しだな
技術の無い奴は、生きる為に技術を欲するけど、
すでに十分な技術を得た人間は、技術を求める理由はそこで無くなる
「技術を求める」 から
「何を作るか？」 に変わって、
「自分は何をして生きたいか？」 に変わって
場合によってはプログラミングから完全に離れる
384:仕様書無しさん
10/06/12 15:24:55
結局、今自分が何を作りたいかなんて自分でさえあまりよくわかってない
385:仕様書無しさん
10/06/12 15:38:33
真理とか中二病だなあ
386:仕様書無しさん
10/06/12 15:45:23
>>383
技術を生きるための手段だと考えるならそうだが、技術自体が生きる目的の場合もある。
スーツとgeekの違いかな。
仕事以外では一切コード書かない奴と、仕事外でのプロウラミングこそreal workだと考える奴とでは
話がかみ合わないのも当然。
387:仕様書無しさん
10/06/12 15:59:02
若いころは将来ばかり見てるけど最近は過去しか見なくなったな
388: ◆RZEwn1AX62
10/06/12 18:21:57
迷いがあるときは 一歩たりと前へは進めない
389: ◆tYNt4nKbgw
10/06/12 18:35:51
>>386
「自分は何をして生きたいか？」 という自分への問いに対し、出す答えは人それぞれ
今までそのことについて一切考えずにプログラミングに現実逃避していた人間は、
>>381のように、ここへきて初めてそれにぶつかって、これからについて考え、
そして人は歩き始める。
390:仕様書無しさん
10/06/12 18:42:12
>>389
会社作って、溜め込んだアイデアを若いPGにやらせまくりたい。
俺は偉そうに営業とかいいつつ会社の金で飲み歩いたりしたい。
391:仕様書無しさん
10/06/12 18:50:46
てか、まともな脳ミソ持ってればプログラミングなんて2～3年で飽きる。
どうアプローチすればいいかもう分かるし。あとはひたすら作業員だからね。
そうなれない奴はアホだから。
392:仕様書無しさん
10/06/12 18:52:26
俺はＣ＋＋がなんの生産性もない糞言語だと気がついたのが５年目だ
長かったな
393:仕様書無しさん
10/06/12 19:04:14
>>391
どうやれば楽しんでもらえるのかかんがえながら作るのはおもしろいよ。
残念なのは、全部一人でやるには量がおおすぎるということだな。
他の人に分けてあげないと仕方ない。
394:仕様書無しさん
10/06/12 21:28:37
2年目のやつに仕様書渡してコード書かせたら、変数名が全部AとかAAとかわかりにくすぎた。
今の若者はコーディング規約知らんのかボケが！
395:仕様書無しさん
10/06/12 21:31:53
そんなレベルの低い問題は教育すればいいだけだろ。
新人をまともに教育出来て無い職場を問題視しろ無能。
396: ◆IO8bwLPiQ6
10/06/12 21:33:43
>>391
結構真理に近いところにいるな
397:仕様書無しさん
10/06/12 22:19:07
真理とか中二病だなあ
398:仕様書無しさん
10/06/12 22:25:30
そういえばハガレン終わっちゃったね。
399:仕様書無しさん
10/06/13 00:31:40
身近な人間からピックアップ
特徴
・つねに口をくちゃくちゃ言わせていている
・缶コーヒーをずるずるとでかい音を出してすする
・ペットボトルから口を離すときに「っちゅ、ぷは～～」
ってな感じに音を鳴らした上に、擬音語を口にする
・昼休みに突っ伏して寝ているみたいだが、休み明けに「っあ～～」とか漫画的擬音語を口にする
・やたらとキーボードをたたく音と、マウスのクリック音が大きい
そいつのPCの操作を頼まれて触ると何かしめっていてねちゃねちゃする
400:仕様書無しさん
10/06/13 00:40:54
何でもプログラミングで解決しようとする
401:仕様書無しさん
10/06/13 14:51:02
>>399
では俺もピックアップ
ようするに技術的なことあまり関係なくて嫌な人間の仕草をあげればいいんだな？
特徴
・椅子の上であぐらをかく
・椅子の上に正座をする
・コーヒーのカップをドンっと音をたてて下におく
・靴を脱いで仕事する
・キーボードの音がうるさい
・ENTERキーの音が耳に障る
・音楽聞きながらの作業中に鼻歌がうるさい
・環境をカスタマイズしているのをさも当然のことに言って周りに自慢する
402:仕様書無しさん
10/06/13 21:31:57
論理演算を理解していない奴が書くコードは意味不明
対偶っていつ勉強するんだっけ？
403:仕様書無しさん
10/06/13 21:34:15
タイピングが速くもないのに自前の高級キーボードを持ち込み自慢する
404:仕様書無しさん
10/06/13 22:58:24
>>402
高校でやったような記憶があるなー。
405:仕様書無しさん
10/06/13 23:23:39
ようするに厨二じゃね？
406: ◆GOLEh7jXr.
10/06/13 23:42:50
論理演算を理解していないとか、
どうしてそうやってさｗｗｗｗｗｗｗ
たったの数分で教えられる or 覚えさせられる知識程度で他人をみくだすかねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
バカすぎる･･･
407:仕様書無しさん
10/06/13 23:46:37
コードをきれいに書こうという気がない奴はプログラミング自体下手だとおもう
括弧の位置とかインデント量、演算子前後のスペースの有無とか、
変数・関数の名前の付け方とか場所によってばらばらな奴は下手、
コーディング規約を確認すらしていない時点でNGであるが
あと名前にローマ字日本語使う奴
408:仕様書無しさん
10/06/13 23:47:13
ここは自己紹介スレじゃないよ
409:仕様書無しさん
10/06/13 23:55:58
>>406
その程度の知識ならばなぜ今まで覚えてこなかったんだ？ってなるだろ。
410:仕様書無しさん
10/06/14 00:05:29
新人君がまだプログラミング始めたばっかりで～～ならちょっと教えればすむことだが
長年ソフト開発に携わっているはずの人間がそうだと、もうお手上げ
411:仕様書無しさん
10/06/14 00:17:05
論理演算なんて新人時代に基本情報でも取らせれば完璧だろ。
お前らろくな教育してないくせに低レベルな問題でグダグダ言ってんなよ。
零細ITの土方PGばかりかここは。
412:仕様書無しさん
10/06/14 00:33:35
ここは自己紹介スレじゃないよ
413:仕様書無しさん
10/06/14 01:22:24
論理演算はいくら馬鹿で学歴なくたって、必ず通る通過点じゃん。
それ位はならってなくてもPGやってりゃ普通に調べる羽目になるだろ。
まあそれより「オタク」求むって言う求人って危険？
414:仕様書無しさん
10/06/14 01:26:25
>>413
オタクと言っても意味は人それぞれだからな。
俺の経験からすると、曖昧なイメージを語る求人はあんまりおすすめできないな……。
415:仕様書無しさん
10/06/14 01:33:25
ローマ字が書けない。
416:仕様書無しさん
10/06/14 01:36:12
>>413
>論理演算はいくら馬鹿で学歴なくたって、必ず通る通過点じゃん。
通らなくてもプログラミングできないわけじゃない。
だから>>406みたいに勘違いするやつも出てくる。
417:仕様書無しさん
10/06/14 01:41:16
>>414
レスサンクス
兵隊求むって感じがするんだよね。
でも自社開発案件らしいので良さそうな気がするんだけど
○○大大大好きな○○オタク募集！って言うのがちょっと気になった。
もう10社以上応募してお祈りされてる中、面談まで漕ぎ着けた会社なんだけど
妥協すべきなのか？昔だったら普通にお断りしてるんだが。
418:仕様書無しさん
10/06/14 01:45:28
>>416
まあそだね、厳密に言えばプログラミングできないわけじゃないね。
でもプログラミングにおいて演算子は使う頻度高いし、
俺めっちゃ低学歴で素数わからない系だったけど
論理演算はエンジニアになってすぐ自分で調べた
419:仕様書無しさん
10/06/14 01:45:44
> ○○大大大好きな○○オタク募集！
って書いてあるんだから、○○が好きじゃないんならお断りした方がいいかと。
好きならあとは条件面の交渉だけだな。
420:仕様書無しさん
10/06/14 01:50:19
>>419
そうだね好きだしいいかな。条件面で判断する事にするよありがとう。
気になったのは兵隊として一時的に雇われる結果になると怖いなと。
PLやPMへの展開は期待できないのかなあって。
421:仕様書無しさん
10/06/14 02:25:58
>>420
キャリアとしては大して意味のない一兵卒としての仕事でも、
何もしてないよりは遙かにマシだしな。
422: ◆HoaeMW/Ya2
10/06/14 04:47:38
>>416
お前がまず勘違いしてる。（笑）
論理演算使ったプログラム（笑）の（笑）サンプル（笑）貼り付けてみろよ（笑）
どんだけ車輪の（笑）再発明が（笑）好きなんだ（笑）
笑わせんなよ？（笑）
423:仕様書無しさん
10/06/14 04:58:47
>>422
だから知らなくてもプログラミングはできるって言ってるだろｗ
文句は>>413に言ってくれ。
424:仕様書無しさん
10/06/14 05:45:18
>>423
何も文句言われる内容書いてはいないんだけど、
論理演算できなくたって充分プログラミングはできるよ。
ただ、知ってればと言うか知っていた方がいいのは間違いない。
他のスレで書いたけど逆に素数なんて知らなくても良いと思う。
結局実際仕事で使う大体のプログラミング（WEBだらけなので）は、MVC分離の理解、
TCP/IPの技術だったり、OOPの知識だったり。
後は勢いと努力。DeNAの川崎なんてまじ低脳なのに大金手に入れたから天才とか言われてるし。
425:仕様書無しさん
10/06/14 06:05:28
>>424
>>423は>>422に対する煽りだから弾よけにされて気に障ったんならすまんかった。
426:仕様書無しさん
10/06/14 07:37:42
>>425
こちらこそすまんかった。
なんか実績ガンガン残してるのに、正社員に手柄持ってかれまくってる
現実が最近見えてきて腹たってた部分があった。
フリー偽装で食ってたせいなのか正社員の書類選考落ちばかり続いていらだっていた。
427:仕様書無しさん
10/06/14 08:07:58
一度フリーに落ちたら正社員には這い上がれない
428:仕様書無しさん
10/06/14 09:28:22
偽装の正社員（特定労働者派遣？）っぽいとこはガンガンスカウト来るけどな。
429:仕様書無しさん
10/06/14 21:54:53
論理演算を何となくしか理解していないやつってのは以外といる
だから条件を整理できなくて、ものすごく長ったらしいif文とか書くんだけど
自分でもよく分からなくなってしまう。
↓こんなif文とかもたまに見かける
if( hoge ) {
/* 何もしない */
} else {
....
}
430:仕様書無しさん
10/06/14 22:09:50
>>429
条件が成立する場合の考慮漏れではなく、
考慮の結果、条件が成立する場合は何もしなくてよい
ってことを示したいときに、そういう書き方をすることはよくある。
431:仕様書無しさん
10/06/14 22:16:42
何もしないってコメント書いてあるなら別にいいだろ。
論理演算を理解していない奴の例にそれを出してる時点でアホ決定。
432:仕様書無しさん
10/06/14 22:40:51
つーか俺含めてPG全員アホだろ
433:仕様書無しさん
10/06/14 22:44:06
PG以外も全員アホだろ
434:仕様書無しさん
10/06/14 22:45:54
基本アホな集まりですから
435:仕様書無しさん
10/06/14 22:46:29
すべての集団の９割がアホだ
436:仕様書無しさん
10/06/14 22:47:34
アホちゃいまんねんパーでんねん
437:仕様書無しさん
10/06/14 22:57:29
さ ぁ 盛 り 上 が っ て ま い り ま し た
438:仕様書無しさん
10/06/14 23:22:01
理系に対して劣等感をもつ奴が多いな
439:仕様書無しさん
10/06/14 23:24:01
金勘定しか出来ないからでしょ
440:仕様書無しさん
10/06/14 23:44:18
>>429
それならまだいい方。
何もしない部分にとりあえずなんか処理書いちゃう奴もいるんだからマジで。
if( hoge ) {
/* 2008.0908 バグ修正の為削除 */
} else {
....
}
441:仕様書無しさん
10/06/15 00:14:03
とある一連の関数名でhoge_init/hoge_start/hoge_pause/hoge_stop
ってのがあったんだが、よくよく処理を読んでみると
hoge_start →リソース初期化
hoge_init →処理開始
hoge_pause →で処理終了
hoge_stop →でリソース後始末
ってのがあったのだが、これを書いた人間は何が欠落しているんだろうか
442:仕様書無しさん
10/06/15 00:22:06
まともにソースレビュー受けた事無いんだろ。だから命名が適当なんだよ。
一度ガッツリと教えればその程度の問題はすぐに解決する。
しかしお前らの文句ってほんと低レベルだなぁ。
443:仕様書無しさん
10/06/15 00:29:51
と言いつつもその程度は教えなくても上手い事やれよという気持ちは分かる。
444:仕様書無しさん
10/06/15 00:51:48
>>440
実はいらなかったとか、バグ修正のため別の場所で処理するなんていうのはよくあるだろ。
445:仕様書無しさん
10/06/15 01:03:58
ネストのネストのネストの.......
って言うコードは真面目に読むのめんどくさいし
もうちょい書き方変えて欲しいもんだね。
446:仕様書無しさん
10/06/15 01:39:33
富士山インデントはやめてください
447:仕様書無しさん
10/06/15 01:55:38
うちの会社ではそういう深いネストを「越すに越されぬ田原坂」と・・・
448:仕様書無しさん
10/06/15 13:50:44
429も440も何がいけないんだかさっぱり。
あえてそのように書く必要は全然無いけど、書いてあって何か問題あるのかな
449:仕様書無しさん
10/06/15 15:00:11
>>448
単純にな
if ( 1 == 2 ) {
}else{
実際にやりたい処理
}
if ( 1 != 2 ) {
実際にやりたい処理
}
もっともっと言うと
unless( 1 == 2 ){
実際にやりたい処理
}
って事だから条件の書き方位考えろって事
きちんと理解していればelse書く意味がない不毛、無意味、アホって繋がる
450:仕様書無しさん
10/06/15 15:04:50
もっともっと細かい事言うとだな
コンパイラ又はインタプリタが条件を2回処理する事になるんだ。
負荷が極端に高い場合こんな書き方をすれば処理速度がやや落ちるわけだ。
ただ、今は鯖性能がいいから問題はないっちゃないけれどって話に繋がってくると
結論どーでもいい。
451:仕様書無しさん
10/06/15 15:06:47
>コンパイラ又はインタプリタが条件を2回処理する事になるんだ。
>負荷が極端に高い場合こんな書き方をすれば処理速度がやや落ちるわけだ。
452:仕様書無しさん
10/06/15 17:04:05
>>450
> コンパイラ又はインタプリタが条件を2回処理する事になるんだ。
> 負荷が極端に高い場合こんな書き方をすれば処理速度がやや落ちるわけだ。
だいぶ前から、そんな腐ったバイナリ吐くコンパイラは見たことない。
どのコンパイラつかってんのか言ってみなよw
453:仕様書無しさん
10/06/15 22:23:06
２回評価する意味がわからん。どんなにしょぼいコンパイラでも一回で済むと思うんだが。。
454:仕様書無しさん
10/06/15 22:34:07
まあ、必然性のあるコーディングならいいんだが
普通にNotとった方がわかりやすいだろうって条件を
わざわざ難しく書くとかはやめてほしい
455:仕様書無しさん
10/06/15 22:34:17
一つのifでも複雑な条件式を書けばアセンブリ言語レベルでは何十命令にもなるんだから、
評価の回数なんて気にする意味なし。
456:仕様書無しさん
10/06/15 22:41:11
評価の回数とか細かいことはコンパイラの最適化に任せればいいんだよ
ロジックレベルでおかしな事やってない限りうまくやってくれる
コード上ではわかりやすさ、保守のしやすさを最優先
昔、数千行に及ぶ関数とかがあって
ほぼすべての変数がグローバルにあって
ループ変数が複数の関数を渡り歩きながら増減するとかいう
とんでもないコードを保守する事があったなぁ・・
457:仕様書無しさん
10/06/15 23:19:16
それCOBOLERが書いたコードだろ
458:仕様書無しさん
10/06/15 23:23:28
>>429
俺も何もしないアピールは結構使う
別にわからないわけじゃないよｗ
459:仕様書無しさん
10/06/15 23:55:40
>>457
おそらくそうだな。あ、これはCね。
しかも、大本のコードにバグがたくさんあって
複数の人が直そうと手を入れて何とかしようとしたが
途中で挫折した感じのコメント付きつぎはぎ修正がいっぱいあったりと
とっても歴史を感じさせてくれるコードだった。
460:仕様書無しさん
10/06/16 00:50:02
どうでもいいレベルの内容でグダグダ言いすぎ。使えないプログラマの特徴が良く出てるスレだな。
461:仕様書無しさん
10/06/16 00:54:39
おまえもな
462:仕様書無しさん
10/06/16 05:20:39
>>453
たぶん、「1個余分にジャンプ命令を吐くことになる」と言いたかったのでは・・・
20年前ぐらいのMS-Cは、空のthen句の最後でelse句をスキップするためにjmpしてた。
ここ10年ぐらい、そんなショボいコンパイラ見たことないけどな。
463:仕様書無しさん
10/06/16 05:29:09
unlessとか鯖とか言ってるから、Perlの話だと思うんだけどなぁ
464:仕様書無しさん
10/06/16 08:26:47
Perlのインタプリタはそんなアホじゃない。というか、JITコンパイラに近い実装。
465:仕様書無しさん
10/06/17 05:25:29
Perlの話だとすると、ますます二度評価の意味がわからんな。
466:仕様書無しさん
10/06/17 05:28:41
読んだ人の脳みそ(インタプリタ)での評価回数のことだろ
としか思えない
467:仕様書無しさん
10/06/17 05:58:02
二度も評価する処理系があったら、条件式に副作用があった時に恐しいことになるぞ・・・
468:仕様書無しさん
10/06/17 05:59:21
わかった。
if ( expression ) {
} else {
do(something);
}
これを、
if ( expression ) {
} elif ( True ) {
do(something);
}
に「最適化」する処理系があるに違いない。
誰かさんの脳内に。
469:仕様書無しさん
10/06/18 14:54:54
エンターキー強打
マウスで机をカンカン叩く
470: ◆naAw11FwqU
10/06/19 03:49:28
>>441
それはゲームプログラミングの命名規則
つうかちゃんと設計されてるゲームのソース見たことある奴ならすぐそのくらいわかるのに
自分の知らない世界だからって欠如とかよくそんなこといえるな
お前の知識が欠如してんだよクズ
471:仕様書無しさん
10/06/19 07:36:10
>>470
俺はゲームプログラマじゃないので知らないが、
その書き込みが真実だとすれば「ゲーム屋ってのは英語知らない馬鹿だらけなんだな」としか思わない
472:仕様書無しさん
10/06/19 08:08:04
まあゲームだったら別に英語を知ってる知らないは関係ないからねぇ
473:仕様書無しさん
10/06/19 08:46:20
英語くらい読めないと使いものになりませんが。
474:仕様書無しさん
10/06/19 09:19:56
今回関わった糞なプログラムの特徴はこんな感じ
・if ほにゃららだったら というのがあっちこっちにある。またifの階層が深い。
・ある動作をするところがあっちこっちにある。
・本人になんでこんなことしてんのと聞いても即答出来ない。どうしてか忘れましたとか普通。基本的に作ったものの構造を自分自身把握してない。
・クラスは使ってるが基本的にオブジェクト同士の関係がスパゲティ。クラス分けの単位がセンスない。
・命名規則とかがぶれぶれ。型ハンガリアンっぽいとこもあればローカルなのに大文字スタートしてるとこもあったり。
・隠すべきところを晒してあっちこっちでいじってるから挙動を把握できてない。
・全般的に残念。センスがない。
とりあえずほぼ全面的にリファクタと称して作り直させていただきました。
あいつに給料を払ってる意味があるのか激しく疑問。
475:仕様書無しさん
10/06/19 10:18:36
>>470
ゲームプログラミングかかわってたが、
>>441が「ゲームプログラミングの命名規則」のようには思えないｗ
あ、initは使ってたか、昔の話だがｗ
476:仕様書無しさん
10/06/19 10:23:07
>>474
「センスがない」とか下手な奴の特徴なのかどうかおいておいて
> ・本人になんでこんなことしてんのと聞いても即答出来ない。
むしろできるならすごい。
俺、3カ月前に作ったプログラムとかもう赤の他人だわ。すぐ忘れるぞ
複雑な式なら計算過程ドキュメントで残したりとか、
何故こうしたかとかコミットログやチケットのログにしっかり書かないとダメだわ
でないと後で見てももう全然わからなくなる
if使うのは別にいいと思うが、階層深いってどのくらいだろ？
477:仕様書無しさん
10/06/19 10:41:59
>>476
それは単にコードを読む力が足りないだけ。
478:仕様書無しさん
10/06/19 10:50:19
>>474
そんなのでも雇わなければならないような糞会社にいるやつが何言ってるんだ。
479:仕様書無しさん
10/06/19 10:57:24
>>476
俺はほとんど覚えてるわ。三カ月前ならコード見なくても言えるくらい。
他人が考えた設計を内容理解してなくて実装したコード
設計しなくて何となく書いたらできちゃったコード
なら無理だけど。
480:仕様書無しさん
10/06/19 13:24:14
急にネットワークに回されることになりました…
皆さらば！
481:仕様書無しさん
10/06/19 17:51:28
こんなifを見たことがある
if( hoge > fuga1 ) {
...
} else if( hoge <= fuga1 && hoge > fuga2 ) {
...
} else if( hoge <= fuga2 && hoge > fuga3 ) {
....
コードレビューで突っ込んだら
こっちの方が分かりやすいからとかなんとか
482:仕様書無しさん
10/06/19 18:01:56
>>481
別によくね？
11～20
21～30
31～40
とかそーゆーのでしょ？
483:仕様書無しさん
10/06/19 18:20:59
uint16_t hoge = 0x12345;
まあ、このぐらいならやってしまうことあるだろう
この点についてコードレビューで突っ込んだときの応答
「しまった、これだと0xffffで処理されてしまうな」
Σ(ﾟДﾟ)・・・気を取り直して
「ってか、ワーニング出るでしょ？ちゃんと、、」
「なんだか分からなかったので見てない」
ΣΣ(ﾟДﾟ)
484:仕様書無しさん
10/06/19 18:24:18
>>481
一瞬で何がしたいのか判断できないコードは嫌いだ。
目茶苦茶下手な奴の特徴だと思う。
485:仕様書無しさん
10/06/19 19:31:53
>>481みたいなのは不等号の向きは小なりで統一すべきだと思うんだが…
その方がパッと見で値の大小関係が理解出来るだろう。
滅茶苦茶に書いてる奴見ると死んでくれと内心思う。
486:仕様書無しさん
10/06/19 19:35:12
はぁ？
487:仕様書無しさん
10/06/19 19:37:05
何がどうはぁ？なのか言ってもらえるとうれしいな
488:仕様書無しさん
10/06/19 19:38:16
>>481
if( hoge > fuga1 ) {
...
} else if( hoge > fuga2 ) {
...
} else if( hoge > fuga3 ) {
....
これでええやん
489:仕様書無しさん
10/06/19 19:41:38
なるほどよく見たらその通り。>>481の意図が読めてなかった。
490:仕様書無しさん
10/06/19 19:51:02
if (a > b) {
...
}
...
if (b >= a) {
...
}
...
if (a >= b) {
...
}
こんなの読みにくくてかなわないがこういう話ではないよな。まさかな。。
491:仕様書無しさん
10/06/19 19:54:58
何となく料理の下手な奴は味見しないっていうのと何か共通点があるような
492:仕様書無しさん
10/06/19 19:57:52
またわけのわからんことを
493:仕様書無しさん
10/06/19 21:24:08
うん。コンパイルも通さずにコミットするのはやめてくれ。
494:仕様書無しさん
10/06/19 21:43:54
>>481
ちなみに、このコードはfugaの部分はマクロになっていたのだが、そのマクロ自体を間違っており、
一個のif文だけなら間違っているとは判別しがたいバグ持ちでしたとさ
495:仕様書無しさん
10/06/19 22:12:20
＞・本人になんでこんなことしてんのと聞いても即答出来ない。どうしてか忘れましたとか普通。基本的に作ったものの構造を自分自身把握してない。
設計に関わったか関わってないかで違うだろ。
設計にも関わった奴は説明できないといかんが、
関わってない奴はしょうがない気もする。
オレなんて昔は先輩が事前に作ってくれたコードを
ペタペタコピペしてただけだぞ。
496:仕様書無しさん
10/06/19 23:17:23
>>488
俺はif文の順番に依存してるelse以外の文が嫌いだから
ちょっと>>481の記述を書く奴の気持ちがわかってしまうんだぜ
497:pure ◆vCtiwSWdZQ
10/06/19 23:31:22
>>496
順番に依存って(笑)
任意のelseifを切り出したときでも、評価式が意図した結果を返すのがいいわけ？
きもちわるｗ
可読性の向上に全く寄与しない、ただただ冗長なコードｗ
498:仕様書無しさん
10/06/19 23:46:28
冗長というより、条件が変わったときに全部書き直すことになりそうなので嫌だな。
どのブロックも実行されないという分かりにくいバグにもつながりそう。
499:仕様書無しさん
10/06/19 23:51:50
>>497
例えばよ
>>488って
if( hoge > fuga1 ) {
...
} else if( hoge > fuga3 ) {
....
} else if( hoge > fuga2 ) {
...
こうなっとおかしくなんじゃん？
else ifが１０００行ぐらい続くソースとかあるわけよ
そんときに条件式の順番に依存してっと上から読んでいかなきゃいけないから面倒なわけよ
それとこんな↓
if( hoge > fuga1 ) {
...
} else if( hoge > fuga3 ) {
....
//2010/04/21 H.Hashimoto cmt:うんこなんでうんこうんこにしておいた
--修正ソース--
} else if( hoge > fuga4 ) {
....
//2010/04/21 end
} else if( hoge > fuga2 ) {
...
みたいな挿入型の修正多くてif文の順番とか多少違っても動くソースを書くように染み付いた
500:仕様書無しさん
10/06/19 23:54:31
うーん低レベル
501:仕様書無しさん
10/06/19 23:55:50
>>500
低レベルだろうがなんだろうが実際ぶち当たったら解決策これっきゃねーだろマジで
順番に依存してっと上からなでないといけないんだぞ
502:仕様書無しさん
10/06/19 23:55:56
>>499
>else ifが１０００行ぐらい続くソースとかあるわけよ
この時点でどうかしてんだろ
503:仕様書無しさん
10/06/20 00:00:13
>>502
仕方ねーじゃん
DBの項目でそれぞれ型が違うとか客の要望聞いてとある条件のときに数字の後に「Ｔ」つけてとか
「Ｇ」つけてとか２０００項目以上の内容のこまごまとした要望をプログラムで延々書いてあるんだから・・・
一括でできない部分ってあるもんだよ
504:仕様書無しさん
10/06/20 00:03:30
>>503
俺はおまいのいうこともわかるぞ
505:仕様書無しさん
10/06/20 00:03:50
ぶっちゃけ動けばどうでも良い、と最近思うようになってきた。
どんなに素晴らしい物作っても評価されないしな…
506:仕様書無しさん
10/06/20 00:08:28
>>503
開腹はしたけど何もせず閉じるしかなかった医者の心境だよな。
507:仕様書無しさん
10/06/20 00:09:38
> どんなに素晴らしい物作っても評価されないしな…
それ辛いよな…
保守性やロジックの美しさなんて客には関係ないから、客から感謝されなくてもまあ仕方ないが、
せめてだれか技術のわかる人に評価してもらいたいよな
508:仕様書無しさん
10/06/20 00:14:05
逆に保守性高すぎてその後他社にシステム持っていかれるくらいなら
多少苦労しても自分のとこでずっと保守した方が金取れるし。
509:仕様書無しさん
10/06/20 00:24:17
条件分岐が延々と続く場合はこんな感じだな。
if(条件1){
処理1
}
if(条件2){
処理2
}
if(条件3){
処理3
}
実行速度が気になるようであれば、処理の最後でreturnするか
終了処理までgotoさせる。
510:仕様書無しさん
10/06/20 00:55:30
正直高負荷サイトでは自然とベストコード書かないと、サーバー１台増やすとかの話になる。
511:仕様書無しさん
10/06/20 01:19:33
>>481
こういう if-else は数直線上で hoge が左から右に進むイメージ。
if (hoge <= fuga3) {
...
} else if (hoge <= fuga2) {
...
} else if (hoge <= fuga1) {
...
} else {
...
}
最初の (hoge <= fuga3) の部分は、たとえ処理が何もなくとも
書いておくのがポイント。何もしないことをコメントで書いておく。
512:仕様書無しさん
10/06/20 01:37:53
>>481
ネーヨと思ったら手元にあった。
当時は条件が不連続になるからって書いたんだっけな。駄目だなあ
513: ◆XSwpGtlyYo
10/06/20 01:38:37
case hoge
when fuga2..fuga1
...
when fuga3..fuga2
...
end if hoge > fuga1
まじお前たちがかわいそうになってくる･･････････････････････････････････････････
514:511
10/06/20 01:40:25
483=481 なのかな？
uint16_t って書いてあるが、それなら < を使えるように fuga1, 2, 3 を定義することを考える。
離散変数 x の範囲による条件分岐を書くなら、左閉半開区間、つまり
[a, b) = { x | a <= x < b }
の形で書き下すのが基本。
この問題のポイントはこの辺までなんじゃないかな。
各条件節に両側の条件を明記するか
(fuga3 < hoge && hoge <= fuga2)
その場合の不等号の向き
(hoge > fuga3 && hoge <= fuga2)
なんてのは、まあどっちでもいい。
このあたりは本人のコードの中で統一されていれば、どっちにしろ「読める」から、
そんなに目くじら立てて気にするほどのことじゃない。
515: ◆XSwpGtlyYo
10/06/20 01:51:06
>>471
>>475
URLﾘﾝｸ(www.google.co.jp)
ぐぐればでてくる
おそらく今までゲームしか作ったこと無い人が
無理して普通のプログラムを書いた結果がそれ
516:511
10/06/20 01:52:25
>>513
そのコードは今まで出てる中で一番駄目。
> when fuga2..fuga1
> ...
> when fuga3..fuga2
こういう書き方をするなら、hoge = fuga2 の境界がどちらに入るのかは
when の順序によらず一意に決まるように読めないと混乱する。
if (fuga2 <= hoge && hoge <= fuga1) {
...
} else if (fuga3 <= hoge && hoge <= fuga2) {
...
}
こんなコード最悪だろ。
もう一点、その言語をよく知らないが、
そういう賢い case-when を使えるんだとしたら最後まで
when fuga1..MAX_INT
とでも書きたい。
区間を扱いながら inf を表現できないんだとしたら、それは片手落ちだ。
517: ◆i2ZQ1YyKNQ
10/06/20 02:20:49
Ruby
Rubyしらないとかｗｗｗｗｗｗｗｗｗ
あうあうｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
コードのセキュリティを高めるなら
when fuga3..fuga2 を
when fuga3...fuga2 だね
そういや
C++使ってた頃は、範囲オブジェクト使えないから
tokushunaIF( x , 200 , 300 ) {
}
とか、マクロ作ったりしてた
範囲IFはあるべきだよ
＆＆ ＜＝ ｜｜ は可読性下げる
518:仕様書無しさん
10/06/20 02:51:38
#define betweenGtLt(x, a, b) (((a) < (x)) && ((x) < (b)))
#define betweenGeLt(x, a, b) (((a) <= (x)) && ((x) < (b)))
#define betweenGtLe(x, a, b) (((a) < (x)) && ((x) <= (b)))
#define betweenGeLe(x, a, b) (((a) <= (x)) && ((x) <= (b)))
キモイ
519:仕様書無しさん
10/06/20 02:54:35
俺様マクロなんてそれこそ可読性下げるわ。
520: ◆z0l.tI98es
10/06/20 03:12:06
５１７はルビイストなんでそのくらいにしてあげてくだちい
521: ◆yL06b9mJTs
10/06/20 04:06:12
>>519
そう思うんだったら>>481これに二度と文句言うなよｋｓ
第一マクロじゃなくて関数にだって出来るのに発想が浅すぎる
オブジェクトだったらメソッドにしたっていいのに
何いってるのかわからないならもう一生>>481こんなコードを描いていれば良いとおもうの
範囲オブジェクトがない言語使ってる時点でコーディング効率下げてるんだから
それの代わりになるものを作れば良いのに
作らないでダラダラと>>481こんなものをかいてても仕方がない･･
522:仕様書無しさん
10/06/20 04:21:45
また論点がくるってきた
流石屑ニート
523:仕様書無しさん
10/06/20 05:52:31
いやあ、まったく範囲オブジェクトのない言語じゃ仕事がはかどらなくて辛いね。
いくら優れたIDEや整備されたドキュメントや膨大なライブラリがあっても、
範囲オブジェクトのないデメリットを覆すには至らないね。
524: ◆yL06b9mJTs
10/06/20 06:11:13
2点
525: ◆NrzNAFPLAQ
10/06/20 06:14:46
4点
526:仕様書無しさん
10/06/20 07:12:16
if( hoge > fuga1 ) return FUGA1;
if( hoge > fuga2 ) return FUGA2;
if( hoge > fuga3 ) return FUGA3;
...
な関数作ってswitchに突っ込む
527:仕様書無しさん
10/06/20 07:37:12
プログラミングが下手な奴ほど、自分のプログラムを批判された時にすぐキレる
528:仕様書無しさん
10/06/20 08:41:03
>>521
>>481の論点はそこじゃない。
範囲オブジェクトだとかマクロの話をするなら>>488をベースにしろって事。
529: ◆NrzNAFPLAQ
10/06/20 08:46:43
俺が論点だから
530: ◆NrzNAFPLAQ
10/06/20 08:49:37
俺も論点だよ
531:仕様書無しさん
10/06/20 12:57:13
発言内容とスレタイを確認して納得した。
532: ◆XSwpGtlyYo
10/06/20 17:11:08
これは#92か。数字トリップ必死すぎるだろ
533: ◆i2ZQ1YyKNQ
10/06/20 17:12:44
これは#94か。数字トリップ必死すぎるだろ
534: ◆NrzNAFPLAQ
10/06/20 17:14:13
姉妹スレ。数字トリップ必死すぎるだろ
ｽﾚﾘﾝｸ(prog板)l50
535:仕様書無しさん
10/06/20 17:18:21
>495
いや、本人がいちから作ったソースです（ ＾ω＾）・・・ついでに開発中のやつです…
536:仕様書無しさん
10/06/20 17:41:44
うちにもいる、自分が作った開発中のコードのレビュー中に
それ何をしようとしてんの？
って聞いても答えられない奴
コード自体もそういう質問が飛ぶ程度のレベルな訳で
537:仕様書無しさん
10/06/20 20:47:20
>>536
多分、自分が何の仕事をしてるかさえわかってないのだろう。
「えっ？○○さんがこうやれって言ったんですけど・・・」
とか言い出したりする。
538: ◆twvOK8mV6U
10/06/20 20:48:07
これは#karenか。数字トリップ必死すぎるだろ
539:仕様書無しさん
10/06/20 21:33:09
>>537
いるいる
540:仕様書無しさん
10/06/21 00:27:15
>537
うちにも共通のAPI使うようにして独自の条件式外してって言ったら、APIつかわず条件式だけ外して例外吐くようにしたやつおったわ。
聞いたらAPIをつかっておらんというので、
「そうしたら動かなくなるの当たり前ですよね？」って言ったら
「いや外せって言われたから外したんですよ」だと。
なんつーか自分がやってることが全体のどういう位置づけで何と絡むとか何一つ考えてないんだよね。
新人ならいざ知らず経験18年とかでそんなことされてもかなわんわ。
541: ◆aAN0AQfNY6
10/06/21 00:32:33
お前らが何を言ってるのか意味不明
そいつは上の立場の人間にいわれて
その通りにソースをかいたわけだろ
社内でちゃんと連絡取り合ってないからそうやってゴミみたいな事おこるんだろうな
542:仕様書無しさん
10/06/21 02:00:01
>>537
実際、あまりにも与えられる情報が少なくて言われたとおりにコーディング
するしかない場合も多いわけだが。
543: ◆VYkHVwSijA
10/06/21 06:55:47
で
「何でこんな風にかいたの？」って質問される＾＾；；；；；；；；；；
544:仕様書無しさん
10/06/21 07:42:26
>>542
それもあるから一概にダメとも言いにくいよね
細かく条件設定してやっと無能認定できるないようだけど
まあ、大抵の場合は指示する側も馬鹿な場合のが多いけどｗ
545:仕様書無しさん
10/06/21 09:08:58
有能な奴だったら言われた指示の中で
「こうするように言われましたが、そうするとこの処理とぶつかってこの場合にエラーに成りますよね？のでここと処理を共通化した方がいいんじゃないですか？」
とか全体をわかった上で同希の処理を実装すべきか提案してくるはず。
546:仕様書無しさん
10/06/21 09:20:21
>>545
そういう会話すら拒否られるシチュもあるからやっぱりなんとも・・・
これだけの材料だと判断できない時点でこの話はもういいや
どうせ後付けばっかり多くなるでしょ？
547:仕様書無しさん
10/06/21 09:52:57
まぁ拒否されるならそりゃしょうがないわな。
そういうバカ上司も沢山いそうだｗ
548:pure ◆vCtiwSWdZQ
10/06/21 12:37:22
>>546
だから「有能な奴だったら」の話だよ。
549:仕様書無しさん
10/06/21 12:40:57
指示する側もされる側もいざ書いてみるまで自分たちが何を作っているのかよくわかってないもんだ。
その中で指示する側は何か不都合があると「それくらいそっちでうまく行くように解釈しろよ（お前は専門家だろが）ボケ」と言い、
指示される側は「何がしたいのかはっきりしろ（こっちは仕様書通りにやってんだよ）クソが」と言い返す。
ああ、悲しいかな悲しいかな
550:仕様書無しさん
10/06/21 12:55:40
>「それくらいそっちでうまく行くように解釈しろよ（お前は専門家だろが）ボケ」
指示する側って、顧客のことだよね？
チーフやリーダーのことじゃないよね？
551:仕様書無しさん
10/06/21 13:53:05
>>548
どんなに有能でも拒否られたら終りだよね？
552:仕様書無しさん
10/06/21 14:03:53
どんなネタでも水掛け論に持っていくことで、焦点をぼかすことは可能だなー
553: ◆VeXmc6uJeo
10/06/21 18:24:33
７０％くらいしか情報与えないで、でも残り３０％は好きにやれっていうんじゃなくて、
エスパーしてやれみたいな。
で、間違ってたらソース書いたそいつのせい。
仕様の３０％については何も言っていないので上は
「俺はそんなこと指示していない」と言い逃れ
次のプロジェクトでは、こんなふざけた事の二の舞にならないよう>>545
しかし>>552
それでもめげずに>>545
最終的には、「いま時間ねーんだよ！！」
とかなんとか、いっちゃって
妙に忙しい素振りを見せながら、何故か半分キレ気味で、去っていく
554:仕様書無しさん
10/06/21 18:43:24
>>553
保留事項はメールにすべて書き出してｃｃつけて
送信しててもなかったことにされるときあるから結局上司に誠意がなければ
ダメなときはなにやってもダメだよね
555:仕様書無しさん
10/06/21 22:16:04
組み込み系でハードの特性をソフトで吸収する必要があったのだが
○と△の計測して、●●だったら××、□□だったら☆☆実装して、
それ以外だったら判断仰いで、と指示を出し、
できたと言うからレビューすると指示と違う実装というか、そもそもコンパイル通るのかレベル
なんでと聞いたら答えられない、
計測した結果はどうだったのか聞いたら、
ほかの作業を優先したので計測していない
・・・じゃあなぜ実装した
って事がありました、こいつの方が俺より給料高いんだよねw
556:仕様書無しさん
10/06/21 22:27:27
まあ、指示を出している方は自分の脳内で完結していて
的確な指示を出しているつもりってのはあるだろうな
557:仕様書無しさん
10/06/21 22:32:49
プログラムの質がどうなのよりも、社会人としてどうなのレベルだな
558:仕様書無しさん
10/06/22 00:02:16
オレ学生だから仕事の事はよくわからんが
プログラミング下手なやつは、外部設計より内部設計を先にするやつじゃないかと思う
というか、外部設計が下手なやつだと思う
559: ◆VeXmc6uJeo
10/06/22 00:13:54
>>558
ここは２ｃｈねるだから学生とか社会人とか関係ない
社会人じゃなくて仕事の事ぜんぜんわかんないけど
>>553こういうレスはかける
560:仕様書無しさん
10/06/22 00:46:57
しかしどこか違和感がある。
本人はそれに気付かない。気付けない。
561:仕様書無しさん
10/06/22 00:52:52
自分の役割が分からないとか
全体的なことを考えられないとか
集団の中で活躍できない人間は下手だと思う
562: ◆kX2JkguNHw
10/06/22 01:48:45
>>560
ではこのスレの中で名無しで俺が書き込んだレスが君にはわかるのだろうか？
563:仕様書無しさん
10/06/22 02:07:06
何が「では」なのかは分からんが
名無しは誰が書いたかではなく何を書いたか、だよ。
コテハンをやめるとはそういうことだ。
564:仕様書無しさん
10/06/22 10:34:26
>>542
そういう場合は
「これこれこういう理由で情報不足のため、
このようにコーディングするしかなかった」
とまともな人なら答えられると思うよ。
本当に自分が何しているか分かってない人は
設計の目的や意図も見抜こうとしないし、疑問も上げないし、
本当に言われたまんま作ってくる。（きっちりバグ付き意味不明コードで）
疑問上げるとしても本当にドメイン外の的外れなことを言ってくる。
問題を指摘すれば責任転嫁。仕事をふれば、
自分がやりたくないと言い出す。リーダ級の人からは
何度も突き上げられるが当人は素知らぬ顔。
何を言っても自分の都合のいいようにねじ曲がるらしい。
相当頑固な頭してる。
で、最後までそのマイペースで業界に残ってたりする。
痛みを感じないって、ある意味最強ｗ
565:仕様書無しさん
10/06/22 10:57:11
情報不足かどうかわかるほど情報が与えられてれば、不足分について質問するだろ。
566:仕様書無しさん
10/06/22 11:22:31
しない奴いるぞ そういうのが問題なんでねえの
567:仕様書無しさん
10/06/22 12:24:48
情報不足かどうかの判断すらしないんだよね
568:仕様書無しさん
10/06/22 13:13:51
>>564
ところがその質問すらかけあってもらえない糞とかマジでいるんだ
569:仕様書無しさん
10/06/22 20:01:50
一方的に客からの指示をメールで伝えるだけで
現場からの質問メールには一切答えないクソマネージャーのために
メンバーの1/3が逃げ出しました。
570:仕様書無しさん
10/06/22 22:09:12
>564
うちのチームにも一人いるんだが座ってる椅子の背中部分ぐらいだったら蹴飛ばしてもいい？(´・ω・｀)
571: ◆st.v6vNiwY
10/06/23 02:25:02
>>563？？
572: ◆s/lQJB6p9w
10/06/23 07:51:17
数字しつこいよ#3434
573: ◆st.v6vNiwY
10/06/23 07:53:05
全角ｗ#３４３４
574: ◆wYUuBm6d7Q
10/06/23 13:03:22
そういう。ゴミでもちょっと調べりゃわかる情報を
なんでここに書こうと思った？
プログラミングの下手な奴の特徴その１だな
575:仕様書無しさん
10/06/23 17:08:10
>>518 下手糞だな
template<class T> bool betweenGtLt(T x, T a, T b) { return a < x && x < b ; }
template<class T> bool betweenGeLt(T x, T a, T b) { return a <= x && x < b ; }
template<class T> bool betweenGtLe(T x, T a, T b) { return a < x && x <= b ; }
template<class T> bool betweenGeLe(T x, T a, T b) { return a <= x && x <= b ; }
576:仕様書無しさん
10/06/23 18:39:36
んでもって between とか名前ながすぎマンドクセ
namespace between {
template<class T> bool GtLt(T x, T a, T b) { return a < x && x < b ; }
template<class T> bool GeLt(T x, T a, T b) { return a <= x && x < b ; }
template<class T> bool GtLe(T x, T a, T b) { return a < x && x <= b ; }
template<class T> bool GeLe(T x, T a, T b) { return a <= x && x <= b ; }
}
577:仕様書無しさん
10/06/23 20:56:38
どっちが下手なんだか
使う言語の機能次第だし
どっちにしてもそんなもん勝手に定義されると迷惑だ
578:仕様書無しさん
10/06/23 22:51:36
そういうの見るたびに
浮動小数点でaとbとxが微妙に同じっぽいような値のときのGeLeの動作って気にならないんだろうか？
とか思うんだけど型って決まってるの？