1仕様書無しさん2014/06/15(日) 00:27:33.89
と言ってる人の技術力も高い。
反対にそんなソースコードを見ても、
何の感想も持たない人の技術力は低い。
ソースコードを見せてどんなことを言うかで
採用試験を行ったほうがいいのではないか？
コードのいい点、悪い点、コードの意図を
読み取れるかどうか、どう直せばいいか。
コードを書かせるよりも短い時間で判断できるとと思う。
2仕様書無しさん2014/06/15(日) 05:49:08.50
ただし、こだわり過ぎのやつは採用しない
3仕様書無しさん2014/06/15(日) 07:45:01.20
保守しやすいコードを見せるわけ
面接者がそれを見て、分かりやすいですねー、と言っているようではだめで
それが優れていると判断できるかだ
そんなのはこないがね。
4仕様書無しさん2014/06/15(日) 07:58:52.37
おまえらにはわからんだろうから教えておくが、
他人が見る、という意識で書かれたコードと
しゃかりきになって書いたコードとはレベルが違う
そこには壁があるよ
5仕様書無しさん2014/06/15(日) 08:02:48.47
・・・・・・・・・・・・・・・・たったそれだけ？
6仕様書無しさん2014/06/15(日) 08:10:53.83
>>1
汚いコードでも、それがいいとされて使われてるプロジェクトもあるわけで、
軽々しく指摘はできないわな。 7仕様書無しさん2014/06/15(日) 09:30:28.40
8仕様書無しさん2014/06/15(日) 10:30:12.73
>>1
たぶん、おれの妄想だと思うけど、
ソースを見ると、その人の技能だけではなく、
性格、人生観、苦悩、希望や絶望など
いろんなものが見えるような気がする。 9仕様書無しさん2014/06/15(日) 11:28:44.84
10仕様書無しさん2014/06/15(日) 12:27:48.33
>>6
それならそれでいいよ。
その会社に入ったら死ぬことになるだろ？
ちなみに俺が良いコードだと思うものは、
外部にみせても恥ずかしくない物
オープンソースなどでも書かれているであろうコードだ。 11仕様書無しさん2014/06/15(日) 12:31:12.48
>>4
> 他人が見る、という意識で書かれたコードと
普通、レビューする人や、次修正する人が見るわけで、
他人が見ないというのは、個人のオープンソースではないプロジェクトぐらいだろ？
仕事なら常に他人が見ることを考えて作れよ。
コード書いてる人はわかっていて書いてるはずだから汚いコードでもわかるだろうけど、
レビューする人は、意味不明なコードだと、それを理解するのにどれだけ時間がかかると
思うんだ？ プログラムなんてコードを読む時間のほうがかかるというのに。 12仕様書無しさん2014/06/15(日) 13:38:02.09
それができない奴がエクセル用マクロ書いた結果真っ黒ソフトから離れられないんだろ
13仕様書無しさん2014/06/15(日) 14:00:52.58
それ以前にオレオレでコーディング規約も何もなしに0から書ける環境でお前らは
仕事してるの？ある程度以上KYな環境で書くのが大半だと思うのだが。 それでも
ダメな奴はダメっていうのは分かるのは多いけど、その逆は中々ないと思うが。
14仕様書無しさん2014/06/15(日) 14:11:54.62
コンピュータ書籍のへ行ったら
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
が一番読まれているものと紹介されていた、
ＪＡＶＡとかというやつじゃないね
15仕様書無しさん2014/06/15(日) 14:35:27.86
業務でプログラミングがすきな人見たことない
ゲーム会社とかにはいるのかな
16仕様書無しさん2014/06/15(日) 15:06:23.60
>>13
俺はコーディング規約は効果が薄いものだと思ってる。
あってもいいけどなくても別に困らない。
それよりも重要なのは、明らかに間違っているコードを無くすこと。
無くすと言っても、そのコードは規約通りじゃないからダメですって
いうんじゃない。
間違っているコードを間違っていると、実例を持って比較して
証明して、そして理解させることまでやらないとだめ。
それができてれば、コーディング規約はどうでもいいよ。 17仕様書無しさん2014/06/15(日) 15:13:24.08
>>13
昔はコーディング規約決めておけば、変数名や関数名がある程度きまってくるから
「あの関数どんな名前だったっけ」って悩まなくてすむ利点があったけど、
最近は補完が効く環境が殆どだから各自好きなように書けばいいやと思ってる。 18仕様書無しさん2014/06/15(日) 15:54:35.40
凄いコードは書けないがシンプルには書いてる短い程良いルール
19仕様書無しさん2014/06/15(日) 21:00:59.48
コーディング規約は、低スキル除けの為に有る。
レビュー時に自分のコード中の変数の意味すら説明出来ないのが時々居るからな。
20仕様書無しさん2014/06/15(日) 21:05:35.08
静的コード解析ツールが無いような言語で開発してるのが多いのかな。
21仕様書無しさん2014/06/15(日) 23:24:44.35
>>10
2chでコーディングスタイルでもめたら、主観じゃなくてちゃんと実績を出してる人の
採用してるスタイルを基準に良しあしを考えようってことで、ソースが誰でもみれて
世界的な実績をだしてる有名オープンソースを挙げて、こういう書き方がされてるって
言うんだけど、自分の職場のソースくらいしか見たことない連中はカルチャーショック
うけるみたいで絶対認めないな。
オープンソースは汚いとか、それは上級者向けの書き方だとかなんとか言って。
有名オープンソースのコードを書いてる人たちは、絶対お前らよりコードの質に対して
センシティブで、自分の会社でしか通用しないガラパゴス技術しかしらんお前らが
文句言うなって感じだけど。 22仕様書無しさん2014/06/16(月) 00:01:00.62
>>21
じゃあ最近何かと話題を提供してくれたOpenSSLのソースはどうなの？ 23仕様書無しさん2014/06/16(月) 00:08:45.19
コメントで結構わかる
24仕様書無しさん2014/06/16(月) 02:49:13.20
汚いダメだまで言えても、
具体的に何がダメなのかを、
説得力を持たせて説明出来る人って少ないよな。
それを反面教師にして、ダメだと感じた時、
具体的に何がダメでどうすれば良くなるかを、
頭の中で文章化するようにしてるわ。
俺が教える立場になったら、もっと上手くやる。
25仕様書無しさん2014/06/16(月) 02:54:36.26
>>24
でもぱっと言えないだけで、実際汚いでしょ？
技術の高い人ってのは慣れてしまっていてさ、
こういう時は、こう書けば綺麗だってのが
体に染み付いてるわけ。
だから変な書き方は最初からせずに、正しい書き方をする。
その頭のなかでぱっと思いつた正しい書き方と
違っていたら、汚いダメだになるんだよ。
で、理由をちゃんと説明したら、自分で作るのと
同じことになってしまうからねぇ。 26仕様書無しさん2014/06/16(月) 03:02:14.61
>>25
経験から身体に染み付いてはいるけど、
それがどういう理屈かまで考えてないから
説明出来ないだけだよ。 27仕様書無しさん2014/06/16(月) 09:24:23.37
Linuxのカーネルのソースなんてものすごく汚いけど
28仕様書無しさん2014/06/16(月) 09:53:17.84
>自分の職場のソースくらいしか見たことない連中はカルチャーショック
うけるみたいで絶対認めないな。オープンソースは汚いとか、それは上級者向けの書き方だとかなんとか言って。
保守ということを考えていないのと考えているとの違いはわかるかな
ネットや書籍ドライバーについてくるサンプルコードを参考にしちゃいけない
シンプルが一番、ソースを保守しなければならないという思想があるなら、そこに重点をおく
29仕様書無しさん2014/06/16(月) 10:05:30.50
そもそもソースがきれいとか保守性が高いなんて
客観的な指標ではなく、どこまでいっても主観的なものなのだから
意識あわせしないとまとまるわけがない
30仕様書無しさん2014/06/16(月) 14:18:50.23
ソースをキレイに書いても誰も褒めてくれないんだから適当に書くに決まってるだろ
手柄を保守するヤツに持って行かれるなんてバカバカしくてやってられない
31仕様書無しさん2014/06/16(月) 15:55:50.20
>>30
そのレベルの職場から脱出できるように頑張れ。 32仕様書無しさん2014/06/16(月) 20:03:01.20
VB.NET研修でN-BASICな論理演算使ってやったわw
講師が理解できないだろうなw
33仕様書無しさん2014/06/16(月) 23:21:46.25
技術の高低や有る無しだけじゃなくて、人となりがわかるのがよいよね
34仕様書無しさん2014/06/17(火) 09:09:04.89
昔OSSのカーネルのコミッタで綺麗なソースに定評がある人を雇ったら、
本当に単にソースを綺麗にする(インデントとか名前規約とか)ことしか出来なくて、
いつまで経っても成果物が出てこなかった、という話を思い出しましたよ
35仕様書無しさん2014/06/17(火) 09:12:51.21
NDAの縛りがある業界だと生産時間の大半を使って書いたコードが表に出せないので、
本流以外のコードでアピールしないといけないのが辛いところだね
36仕様書無しさん2014/06/17(火) 09:58:28.15
37仕様書無しさん2014/06/17(火) 20:29:56.10
>>34
それお前の問題じゃね？
その人が何を修正しているのか
コミットログから見抜けなかったんでしょう？
普通コミットログみれば、インデントや名前規約だけしか
変えていないということは、すぐに分かるはず。
（その人のコミットの前に、本当にコードを書いた人がいるわけだから） 38仕様書無しさん2014/06/17(火) 23:47:45.47
つか綺麗なコードってそういう事じゃねえだろっていう
39仕様書無しさん2014/06/17(火) 23:55:53.28
綺麗 模様とかデザイン的なもの
奇麗 清潔
40仕様書無しさん2014/06/18(水) 00:02:42.63
ぴかぴかきらきら
きれいきれい
41仕様書無しさん2014/06/18(水) 00:12:13.35
手書きで字が綺麗
OCRでもばっちりんこ
42仕様書無しさん2014/06/18(水) 01:40:01.32
>>37
俺が雇ったわけじゃない、伝聞だよ
著名なOSSのコントリビュータだったから深く調べずに採ったと思われ
そういう人はそれはそれで使い道があったと思うけどね 43仕様書無しさん2014/06/18(水) 16:54:33.54
>>15
いるわけがない
ゲームのメインディッシュはデザインだし、プログラマは脇役でしかない 44仕様書無しさん2014/06/18(水) 17:08:27.52
しかしプログラムがクソだとぬるぬるに動かなかったりで、
縁の下の力持ちってとこかな
45仕様書無しさん2014/06/18(水) 18:23:02.21
やさしいコードすき
46仕様書無しさん2014/06/18(水) 22:28:10.32
>>43
バカジャネーノ
ゲームはコンピュータサイエンスの最先端
花形中の花形だし 47仕様書無しさん2014/06/19(木) 08:00:37.41
>>46
それプログラマちゃう、グラフィッカーや･･･ 48仕様書無しさん2014/06/19(木) 08:06:08.27
>>43
少なくとも昔のショボいハードの時代は脇役なんかじゃなかった。
任天堂の社長なんて、元は協力会社のプログラマだろ？ 49仕様書無しさん2014/06/19(木) 08:26:10.27
>>48
デザインは確かに目立つ部分だが、アイスで言えばトッピング。
トッピングだけで売れると勘違いしてるのが多いだけ。 50仕様書無しさん2014/06/19(木) 08:59:27.68
>>49
いつの時代のゲームだか
今やプログラミングのほうがトッピング
アイスの部分はグラフィック、コーンはデザイナー
そしてアイスとコーンが不足して開発難
トッピングは在庫にどっさり、腐ったら入れ替えにゃならん 51仕様書無しさん2014/06/19(木) 10:08:06.08
美しいソースリストはいいな
でもなあ
Ｃ言語系だと美しくするといっても限界がありすぎる
もともときたねえんだよ
高速省タイプ、楽々コンパイル
ふりーふぉまっとおー
読みやすさ？
すごいでっせ！
アッセンブラーなんかやりたくなくなるほどですぜ
そうですかあ
52仕様書無しさん2014/06/19(木) 13:15:57.67
今の時代のゲームはガワさえ良ければ売れるからな
ソシャゲとか、デバッグをユーザーにやらせながらユーザーに金を払わせるという異常なシステムを広告というガワで囲って見えなくしてる
53仕様書無しさん2014/06/19(木) 15:23:20.91
それだけ設計者の質がどんどん落ちてるから
人材不足でプログラマ上がりのゲーム脳だったり、ゲーム未経験の絵描きだったり
数日あれば紙の上で再現できるシステムを、ゲームと呼んでしまう自称開発者
54仕様書無しさん2014/06/19(木) 19:13:02.82
頭の悪い女向けに疑似恋愛仕向けるだけだからな
55仕様書無しさん2014/06/19(木) 21:26:14.25
デバッグ完全に終わらせてからリリースなんてしてたら会社潰れるんじゃね
56仕様書無しさん2014/06/19(木) 22:55:27.72
>>55
だったら任天堂みたいなコンシューマーゲー作ってる会社は全部潰れてるよ 57仕様書無しさん2014/06/19(木) 23:06:02.60
これは凄いとか、これは酷いっていう見極めるポイントとかありますか(´・ω・｀)？
58仕様書無しさん2014/06/19(木) 23:38:46.75
ビルアトキンソンの書いたQuickdrawのソースは凄かった
あのまま石版に刻んでもいいレベル
59仕様書無しさん2014/06/19(木) 23:42:52.90
>>57
変数名、関数名、関数の長さ、ネストの深さ。 60仕様書無しさん2014/06/20(金) 00:00:03.86
とりあえず暗号化した後のjsみたいな変数名をつける奴まじふざけんな
61仕様書無しさん2014/06/20(金) 00:12:02.12
>>56
ソシャゲの話になんでコンシューマが入ってくるのか 62仕様書無しさん2014/06/20(金) 05:17:15.13
63仕様書無しさん2014/06/20(金) 12:35:14.07
>>1
おまえが優秀ということか？
思い上がりも大概にせぇやww 64仕様書無しさん2014/06/20(金) 13:23:25.15
おおっとここで匿名相手に嫉妬かぁ
65仕様書無しさん2014/06/20(金) 19:32:33.90
63がいちばん優秀で決まり。
66仕様書無しさん2014/06/20(金) 21:57:18.16
いや65がいちばん優秀だな
67仕様書無しさん2014/06/20(金) 22:01:08.14
じゃあもういいよ、俺が一番優秀ってことで。
68仕様書無しさん2014/06/20(金) 22:03:02.93
お前かよ
69仕様書無しさん2014/06/20(金) 23:01:29.97
うわーすごいですね！ とってもかっこいいです！（棒
70仕様書無しさん2014/06/21(土) 12:23:06.39
おたふく以外認めない
71仕様書無しさん2014/06/22(日) 17:57:35.02
コードが美しいとかいってるやつは１００％無能な馬鹿。
72仕様書無しさん2014/06/22(日) 20:30:32.07
動くもの作れて初級
その上で客が喜ぶもの作れて中級
更にその上で保守性に優れたもの作れて上級
73仕様書無しさん2014/06/22(日) 21:07:11.05
>>71
有能なやつはほとんど、コードが美しいって
話をしていると思うが？ 74仕様書無しさん2014/06/22(日) 22:42:31.72
正しく、美しく、速く (この順番で)
75仕様書無しさん2014/06/23(月) 02:54:48.68
清く正しく美しくの順だろjk
76仕様書無しさん2014/06/23(月) 06:39:54.77
有能な奴はプログラマなんて卒業してる
77仕様書無しさん2014/06/23(月) 07:57:44.33
はいはい
78仕様書無しさん2014/06/23(月) 10:34:01.87
>>76
もっと有能な奴は...入社していきなりSEなのぉ...!? 79仕様書無しさん2014/06/23(月) 13:48:41.50
>>59
変数名、関数名、関数の長さ、ネストの深さ。
関数の実態の前につけるコメント
//ロットNumberを表示
DispLotNum()
{
}
というコメントはいらない。頭痛が痛い、というような書き方だから
大体が名が機能を表すという書き方しているよね。どの本を見てもそれだ。
ただ関数の（メソッド）先頭にはコメントあったほうがいい。
コメントが区切りになりわかりやすい、
では、なにを書くかだが、俺は機能の説明ではなく、
この関数が呼ばれるまでの順序を書く
この関数はTimer-＞Disp関数から呼ばれる、と書く 80仕様書無しさん2014/06/23(月) 19:27:52.43
>>79
> この関数はTimer-＞Disp関数から呼ばれる
新手の頭痛が痛いだな 81仕様書無しさん2014/06/23(月) 19:33:05.20
呼ぶ側が1箇所なら関数化する必要ないよね
82仕様書無しさん2014/06/23(月) 19:50:48.27
mainから出せる物全部追い出した方が可読性が上がる的な
83仕様書無しさん2014/06/23(月) 20:10:24.04
>>81
そうとは限らん。
// ここから○○の処理
：
：
// ここから○○の処理
：
：
// ここから○○の処理
：
：
って書くぐらいなら関数にした方がいい。 84仕様書無しさん2014/06/23(月) 20:14:27.54
「頭痛が痛い」にならないコメント書いときゃええがな
右脳で認識できる文章がベスト
右脳が使えないなら諦めろ
85仕様書無しさん2014/06/23(月) 20:19:53.42
>>84
>「頭痛が痛い」にならないコメント書いときゃええがな
最初からそう書いてあると思うが？
「頭痛が痛い」と書くなって書いてるのに、
「頭痛が痛い」を書かない方がいいとか。 86仕様書無しさん2014/06/23(月) 20:26:50.46
書いてある"と思う"って何なんだ･･･
87仕様書無しさん2014/06/23(月) 20:27:14.65
頭痛が痛いってそんなにおかしいか？
88仕様書無しさん2014/06/23(月) 20:31:14.89
>>85
おま、ロボットかよ
もういっその事、0か1で喋っちまいなよ 89仕様書無しさん2014/06/23(月) 20:34:56.28
>>88
なにいってんの？
書いているか書いてないかに
0と1以外の答えがあるのか？
半分だけ書いているとか？ｗ 90仕様書無しさん2014/06/23(月) 20:37:42.58
＞0と1以外の答えがあるのか？
病院行け
91仕様書無しさん2014/06/23(月) 20:44:04.33
なんで悪口しか言えないんだろう？
人間性を疑うよ。
92仕様書無しさん2014/06/23(月) 21:11:13.14
そういえば、きみのコードは(関数が多くて)あっちこっちにいって読みにくいと言われたことがある
ちなみに、その人のコードはグローバル変数に一つの長い関数という、読む気の失せるコードだった
頭のスペックの違いなのか、前者では流れるように脳内デバッグできるのだが、後者では脳内デバッグにやたら時間を要するのだ
アスペにはプログラミングが心地よいのです、それはまるで機械のように理路整然と
複雑なものを分解し、最小単位のものを組み合わせて構築していく様、実に美しい
93仕様書無しさん2014/06/23(月) 21:14:19.10
>>92
そういう人には、じゃあなんであなたのコードは
コードメトリクスにかけると評価が低いんですか？
って聞いてやれｗ 94仕様書無しさん2014/06/23(月) 21:14:50.44
>>92
適切な粒度があるだろ。
分ける意味が無いのに分けるのは良くない。 95仕様書無しさん2014/06/23(月) 21:17:53.45
意味なんか後付けでいい、短い関数こそ正義。
96仕様書無しさん2014/06/23(月) 21:31:08.86
2chでもグローバル変数支持派を見たことあるな。
変数宣言が一か所にまとまっていてわかりやすいとか、今は検索機能が充実してるからどこで使われてるかすぐわかるとか。
97仕様書無しさん2014/06/23(月) 21:37:11.15
98仕様書無しさん2014/06/23(月) 22:29:26.87
時間をかければ一定の綺麗さにはなるけども
そんな時間は趣味のコーディングでもない限りない
それが現実
99仕様書無しさん2014/06/23(月) 23:28:52.87
>>98
でもさ、それって複雑コードを読むのに時間取られてるでしょ？
テストする時間もなくて手動テストして結局時間取られてる。
やっぱり綺麗（メンテナンス性が高くて修正に時間がかからない）コードが
一番時間がかからないよ。 100仕様書無しさん2014/06/23(月) 23:38:50.79
101仕様書無しさん2014/06/24(火) 00:04:19.87
綺麗に書くのに時間かかるっていう奴の気がしれない
102仕様書無しさん2014/06/24(火) 00:33:53.66
>>100
おまえの経験した仕事はどんな仕事？
どんな言語使ってる？ 103仕様書無しさん2014/06/24(火) 01:13:55.10
104仕様書無しさん2014/06/24(火) 01:18:18.92
105仕様書無しさん2014/06/24(火) 05:58:57.38
106仕様書無しさん2014/06/24(火) 07:14:51.22
107仕様書無しさん2014/06/24(火) 07:25:28.37
>>102
詳しくは言えないが組み込み系だよ
今はC言語
毎日ビルドとテストを自動で走らせるなんてもはや常識なんだが 108仕様書無しさん2014/06/24(火) 07:30:05.48
109仕様書無しさん2014/06/24(火) 08:02:19.47
>>107
98-100の流れだと「テストは今時自動だから綺麗に書く必要はない」という文脈になるけど？
あと組み込みなら尚更、"綺麗"の方針を明確にしないとね。
富豪プログラミングが容認される環境ならともかく、"綺麗"とはプログラマにとってなのか、デバイスやコンパイラにとってなのか、それらのバランスは？など決めて行くべき事が多い。 110仕様書無しさん2014/06/24(火) 10:53:43.18
綺麗というのは、開発や修正に時間がかからないって意味だよ。
とても重要なこと。
111仕様書無しさん2014/06/24(火) 15:16:25.60
とりあえず組み込みならMISRA C:2004に準拠しとけ
誰が書いてもそこそこ綺麗になるから
112仕様書無しさん2014/06/24(火) 17:31:23.05
>そういえば、きみのコードは(関数が多くて)あっちこっちにいって読みにくいと言われたことがある
ちなみに、その人のコードはグローバル変数に一つの長い関数という、読む気の失せるコードだった
頭のスペックの違いなのか、前者では流れるように脳内デバッグできるのだが、後者では脳内デバッグにやたら時間を要するのだ
この文の前者の指しているものがわからない。
プログラマのデバッグとはこのようにやる。
プログラマはソースコードをよみながら変数の関連付けをやる
この文には前者の指しているものが抜けている。そして、この文にバグがあると見る。
113仕様書無しさん2014/06/24(火) 17:38:03.96
前者は「君のコード」でしょ？ 関数があるコード。
114仕様書無しさん2014/06/24(火) 17:47:08.83
＞前者は「君のコード」でしょ？ 関数があるコード。
なるほど、俺のデバッグがまちがっていたな。そうよめばいいのだな
前者というのが「君」。「その人」をさすものが先の「君」だと読んでしまった
115仕様書無しさん2014/06/24(火) 18:00:36.72
>>96で思い出したんだけど
ICE使えない環境でデバッグするのが前提のときって
モジュール毎の出力をグローバルで渡すようにして
モジュール間の連携をRAMプローブでモニタするよね 116仕様書無しさん2014/06/24(火) 18:52:18.12
デバッグの時はどうでもいいと思うが。
117仕様書無しさん2014/06/24(火) 19:15:18.23
デバッグ終わったバイナリ変えたらだめだろ
118仕様書無しさん2014/06/24(火) 19:40:02.35
その後にテストするんだから問題ないよ。
デバッグコード消すまでが開発。
119仕様書無しさん2014/06/24(火) 21:30:10.23
確認手段をなくすのは感心しないな
120仕様書無しさん2014/06/24(火) 22:59:38.71
ロガーのログレベルを変えて対応するのがいいのだが、そのレベルまで到達
していない人やプロジェクトって案外あるんだよね。 せめてデバッグフラグで
ONOFF切り替えれるようにしておけばいいのに、それすら手修正なんてのも
いたりするから油断ならない。
121仕様書無しさん2014/06/24(火) 23:03:52.78
122仕様書無しさん2014/06/24(火) 23:26:00.79
よくこういう事言うけど直接話した方早くね？
123仕様書無しさん2014/06/24(火) 23:26:27.16
stdioがあればログ吐くコードをコンパイルスイッチで切って入れておけばいい。
ないならそのままリリース。
当然と言えば当然だが。
124仕様書無しさん2014/06/24(火) 23:29:17.57
アホみたいにあちこちにログ入れないでくれ
例外握りつぶさないでくれ
似たコードあちこちにコピペしてこんがらがったツギハギ作らないでくれ
変な名前つけないでくれ
125仕様書無しさん2014/06/25(水) 00:25:12.38
>ソースコードを見せてどんなことを言うかで 採用試験を行ったほうがいいのではないか？
>コードのいい点、悪い点、コードの意図を 読み取れるかどうか、どう直せばいいか。
採用のとき、ソースコードを見せて反応するようでは駄目だな。
どういった挙動をするかを見極めるまでコードを変更できない。
軽がしく意見をいうよなのは知ったかぶりプログラマ
126仕様書無しさん2014/06/25(水) 07:27:16.79
ソースの体裁はコードの本質ではないからな
127仕様書無しさん2014/06/25(水) 23:54:50.05
とかいって
とんでもないゴミ糞スパゲティ生産します
128仕様書無しさん2014/06/26(木) 05:25:28.83
129仕様書無しさん2014/06/26(木) 16:05:27.24
>>126
ああ、もうそんなのが増える季節か。
服は人間の本質では有りません！
率直な姿になって交流しましょう！ 130仕様書無しさん2014/06/26(木) 21:31:25.66
オレは裸のコード書き
131仕様書無しさん2014/06/26(木) 22:29:25.99
132仕様書無しさん2014/08/08(金) 10:30:18.47
>>60
ツッコむのわすれてた
難読化と暗号がの違いがわからない奴は引っ込んどけ(#･∀･) 133仕様書無しさん2014/08/09(土) 12:25:51.32
.jseじゃね？
134仕様書無しさん2014/08/09(土) 15:49:49.35
言いたいことを言おうとするとアスペ化する
135仕様書無しさん2014/08/09(土) 18:37:54.30
ソースコード見ればその設計人の技術力や考え方がわかる
136仕様書無しさん2014/08/13(水) 11:33:41.94
論理面の美しさと字面的な美しさの二種類あるよね。
137仕様書無しさん2014/08/15(金) 20:23:35.47
宇宙的？芸術的だろ
論理 ←→ 芸術
宇宙って何だ、カルトか
138仕様書無しさん2014/08/15(金) 20:53:23.80
139仕様書無しさん2014/08/15(金) 21:11:47.92
実は宇宙は俺のゲップから始まったんだぜ
140仕様書無しさん2014/08/15(金) 21:22:14.72
字面宇宙字面字宙字面宇宙
141仕様書無しさん2014/08/16(土) 01:28:08.60
字面宇面字宙宇宙字面宇苗字面字苗字面宇宙
142仕様書無しさん2014/08/16(土) 18:37:04.29
字（じ）と宇（う）違いだ。
字面 ＝ じづら ＝ lexical
143仕様書無しさん2014/09/03(水) 05:59:22.30
>>136
論理面で美しいコードは字面も美しかったりすると思うがどうか？ 144仕様書無しさん2014/09/03(水) 08:47:17.23
ロジックは美しいがネーミングセンスが残念なコードってあるよな
145仕様書無しさん2014/09/03(水) 09:03:16.15
146仕様書無しさん2014/09/03(水) 20:24:34.01
>>144
名前付けるのが下手≒抽象化が下手
だから、きれいなロジックを書けるとは思えんが。 147仕様書無しさん2014/09/04(木) 08:09:13.01
いや抽象化の程度とかじゃなくて
スペル間違ったり単語のセンスが変なやついるでしょ
148仕様書無しさん2014/09/04(木) 09:07:42.41
俺が見た例
InvalidityKey
149仕様書無しさん2014/09/04(木) 09:08:15.32
data_1st
data_2nd
data_3nd … サンド？
150仕様書無しさん2014/09/04(木) 09:50:03.28
英語にするとなじみが無さ過ぎてよく分からない単語を使われた場合
残念といって良いのか、自分の不勉強を反省するべきなのか。
151仕様書無しさん2014/09/04(木) 11:24:39.61
年金をPensionって書かれると一瞬戸惑うな
152仕様書無しさん2014/09/04(木) 11:27:13.67
やっぱYearGoldって書かないと駄目っすか、先輩
153仕様書無しさん2014/09/04(木) 14:00:53.86
年金なんてNenkinで駄目か？
154仕様書無しさん2014/09/04(木) 14:07:47.65
いまどきのまともな言語なら、そのまま「年金」でいいじゃん。
いつまでASCII文字に縛られているんだよ、労害ども。
155仕様書無しさん2014/09/04(木) 14:41:50.08
156仕様書無しさん2014/09/04(木) 15:47:48.27
多バイト文字とトライグラフは使用禁止なんだよね
157仕様書無しさん2014/09/04(木) 15:53:27.24
といいつつ、コメントや埋め込みリソースにはばっちり多バイト文字が
あったりするｗ
158仕様書無しさん2014/09/04(木) 16:32:50.37
ああ・・、オナニーしたくないなあ。。１ヶ月に一回しないとどうしようもない。。でも、絶対したくない・・
すると、１週間くらいパフォーマンス落ちるんだよな･･マジ嫌だ･･
159仕様書無しさん2014/09/12(金) 08:39:30.06
よく見るといったらregistなんちゃらメソッドがダントツで多い
160仕様書無しさん2014/09/12(金) 09:58:55.83
Observable晒せよ
161仕様書無しさん2014/09/14(日) 16:20:18.80
>>159
registって英単語は存在しないのにかｗ 162仕様書無しさん2014/10/15(水) 00:36:47.28
163仕様書無しさん2014/10/15(水) 08:18:59.63
また旧いのにレスしてるな・・・
どう読んでも流石に>>79はネタ。
スレタイ通りのものが書きたかっただけだろ。 164仕様書無しさん2015/02/09(月) 19:27:23.55
165仕様書無しさん2015/04/19(日) 16:02:21.75
>>83
すげーアホなコードだなー。
関数化しないでコメントとかで区切っておけばいいだけ。
お前はそこでしか使わないことしってても
他の人はこれどこで使うんだろと思う。
無駄な時間を取らせるなよ 166仕様書無しさん2015/04/19(日) 17:09:11.67
どこで使うって、その１ファイル(モジュール、クラス)内に
決まってるじゃんｗ
そういう関数は当然privateっしょ？
え、まさかpublicなの？そりゃないっしょ
167仕様書無しさん2015/04/19(日) 17:27:34.10
>>1 のような偏った考え方をする人を雇ってしまうリスクを少しでも
減らす方法って何かないだろうか？ 168仕様書無しさん2015/04/19(日) 17:56:32.97
169仕様書無しさん2015/04/19(日) 18:46:20.84
>>166
Aのクラス、Bのクラス、Cのクラスがあったとしよう
CにPublicな関数があるわけ。たとえばc::Dispということにしよう
なまえのとうり表示関数だな。Aのクラスで
それを呼び出すときはA->C->Dispというようにやるとしよう。継承だな
Bのクラスでそれを呼びたいときがあったら
B->C->Dispとはやらない。
俺はAのクラスを通してやる。B-＞A->C->Dispだ。
あちをみたりこっちをみたりというのがいやだから
MainクラスがAでそれを必ず通るというやりかた 170仕様書無しさん2015/04/19(日) 18:51:43.83
ある開発の依頼を、自分なりのクオリティを担保したコードで
書こうとすると２週間は欲しいところを、>>1のようなソースコードに
対する自分のこだわりのようなものは腹の中に押し殺して、マーケ
ティングや 営業の人たちが欲しいと言っている明後日までに仕上げるほうが 、
回り回って、自分のプログラマーとしての仕事のしやすい環境づくり
のために なることがよくある。
話は変わるが、 171仕様書無しさん2015/04/19(日) 18:54:56.57
話は変わるが、
最近スポーツ解説者の張本勲が、サッカーで、現役を続ける三浦知良に
失言した一件で、松本人志が
「自分の美学を押し付けると美しくなくなる」
と言った。
>>1のような、ごく個人的な自己愛の腐臭が漂うレスも、
松本のいう「美しくないもの」の典型なのだが、
一番大事なのは、>>1みたいものを読んだときに、
「こういう押し付けは、美しくないなあ。俺はこういう押し付けを
周りにしていないだろうか。気をつけよう」
と即座に感じるセンスだ。
そういうセンスがないと、いつまでも他人の言うこと
(そのほとんどは無責任なものだが。)
に右往左往させられてしまうからね。 172仕様書無しさん2015/04/19(日) 18:59:03.34
脱字修正
> 1みたいもの
1みたいなもの
173仕様書無しさん2015/04/19(日) 19:08:56.60
>>168
>それは>>1が間違っているってことを
>証明してから
やらなければならない理由は何だ？
分かりやすく説明してみ 174仕様書無しさん2015/04/19(日) 19:10:18.80
繰り返すが。
>>1 のような偏った考え方をする人を雇ってしまうリスクを少しでも
減らす方法って何かないだろうか？ 175仕様書無しさん2015/04/19(日) 19:18:33.87
>>1
ソースを一目みたくらいで本質をすぐに見抜くことなど不可能
識別子が読みやすいとかインデントが綺麗とか、その程度の理解でもって判断するのか？ 176仕様書無しさん2015/04/19(日) 19:22:38.28
>>1
あるでしょ。2ちゃんに>>1みたいなことを書いてる人間は
リアルで認められない鬱憤が溜まっていて、そういうのは
面接ではどう隠してもモいオーラとして発散してしまうからな。 177仕様書無しさん2015/04/19(日) 19:31:30.52
178仕様書無しさん2015/04/19(日) 19:52:36.11
>>1に現実がどういうものか、ちょっと教えてあげると、スレタイの
ソースコード見ればその人の技術力や考え方がわかる
は、間違いとは言えないが、正しくはこういうものだ。
ソースコード見ればその人の技術力や考え方がわかる
という（やや短絡的な）評価の仕方で差し支えないポジションも
あるかもしれない。その場合は、本当に付加価値を生む頭脳労働を
する人のタスクと、そのような短絡的な評価の仕方をしても
かまわない人たちの（単純労働的な）タスクとに、きちんと分割した人が
偉いという話だ。 179仕様書無しさん2015/04/19(日) 20:45:05.68
自分のこだわりはこだわりで持ってもいいと思うけど、
それを他人には押し付けてしまう人間に
ならないために、
どうしたらいいでしょう？
180仕様書無しさん2015/04/19(日) 20:59:07.83
綺麗なコードは単なるプログラマーのオナニー。
ユーザーは動けば良いし、綺麗なコードが利益を出す訳でもないw
181仕様書無しさん2015/04/19(日) 21:30:11.33
汚いコードは明らかに生産性をと落とす
つまり、コストが高くなる原因になってる。
182仕様書無しさん2015/04/19(日) 21:43:36.46
所詮プログラマーなんて、所詮人月で数えられる程度の計れるコスト。
そもそも、他人の汚いコードごときで生産性が落ちるプログラマーは無能だ。
有能なプログラマーは、汚いコードでも手に取るようにプログラミングした人間の脳内と
即座にシンクロできる。
183仕様書無しさん2015/04/19(日) 21:49:25.63
おいおい >>1 と言っていることが変わらないのだが‥ 184仕様書無しさん2015/04/19(日) 22:39:40.06
そんな風に読み取れた君は立派なコミュ障プログラマー
185仕様書無しさん2015/04/20(月) 00:56:25.26
>ソースコード見ればその人の技術力や考え方がわかる
ソースコードから設計図を作れるかだな。
それでプログラミングの技術がわかるのではないか
コードがユーザからの処理で追加、追加となっているのと、
設計図を意識したコードでは違う
前者は設計図を描けない。
設計図とは視覚的にコードの構造を見せるというようなことだ
確立された手法は無いともいえる。設計者の技量が問われる
人にどう伝えるかの技量の世界ともいえる
漫画で言えばネーム、小説で言えばプロット。これで編集者さんに伝える
ソフトの場合、設計図でもってエンジニアに伝える
186仕様書無しさん2015/04/20(月) 03:23:03.69
>>185
だめだな。
コードレビューのとき、あんたは、他の人の書いたコードを批判するときに
>設計図を意識したコード
になってない
とか言っちゃうわけ？
話がまったく通じないよ、それじゃ
>設計図を意識したコード
みたいな、自己愛を満たすだけのワードって、絶対使っちゃダメ 187仕様書無しさん2015/04/20(月) 06:59:36.72
外注にお前が作ったソースコードを元に、そこから設計図を作ってよ、と頼んだことがあった
こんな風にしてよと、クラス図とか、画面表示に使われる変数一覧とかを渡す
で、掛かった時間だけの賃金を払うから、と言ったが、できてこない
そ言う訓練が、できていないからできないわけ。
ソースコードが属人的というのではだめだな。
ソースコードの良し悪しは属人的から脱することにあると思う
ソースコードの良し悪しの判断は、ソースコードの書き方でなく
設計図をもってこれるかどうかで判断したほうがいいよ
188仕様書無しさん2015/04/20(月) 11:14:35.20
>>186
お前、否定しているくせに
何一つその理由を書けないんだな。
お前のいっていることは間違ってるよ。
（俺も理由書いてないけど、こいつにはこれで十分） 189仕様書無しさん2015/04/20(月) 11:15:46.86
>>187
ある機能に関するコードが
複数のファイルに分散されている状態で
設計図なんて出来ると思う？
ソースコードが汚い可能性があるよね。 190仕様書無しさん2015/04/21(火) 05:49:53.98
>>189
>>187は本物のアホ
>外注にお前が作ったソースコードを元に、そこから設計図を作ってよ、
とか、言われたほうにしてみればただのパワハラ
ソースから設計図を書けることに個人としてこだわるのは別にかまわないが、
誰もがそこに価値を認めているわけではないのに、そこの理解を求める
努力もしないで押し付けたら、単なる嫌われ者。
自分のコミュニケーション能力が足りないことを自覚するセンスもなく、努力も
しないで、こういう
>お前のいっていることは間違ってるよ。
>（俺も理由書いてないけど、こいつにはこれで十分）
ことを言い出す、ちょっとおかしな人、最近の現場で一人はいるよね。
充実していない技術者ライフの鬱憤を周囲に撒き散らす、最も迷惑なタイプ
私は技術者採用の面接のときに、こういう人間を採らないようにすることを
一番気をつけている。 191仕様書無しさん2015/04/21(火) 05:55:56.31
>外注にお前が作ったソースコードを元に、そこから設計図を作ってよ、
みたいな注文てね、何でダメかというと、
外注先のプログラマーよりも、発注元の自分のほうが
プログラマーとして優れている、だから俺様が教えてやる、
というふうに相手に完全にマウンティング前提での命令だからだよ。
本当に失礼
>>187は自分が失礼な言動をしてきたことに気がつかないんだろうな。
はっきりいうが、もう手遅れだと思う。
人の性格は治らない。 192仕様書無しさん2015/04/21(火) 06:13:57.66
実際、プログラミングの技術も大事だけど、この業界で仕事していく際には
いかにして>>187のような人間と関わらないようにするかが、極めて重要。
もし運悪く、こういう手合いから依頼を受ける立場になってしまったら、
お前の依頼を誠実にやってやるメリットは、こちらには何もないんだよ
ということを、きちんと、分かりやすく伝えてあげるという、とても骨の折れる仕事を
しなければならない。
そんなヤでしょ？
だから関わらない技術というのが、すごく大事になってくる。 193仕様書無しさん2015/04/21(火) 07:33:38.72
>>1=187=188
のレスからは、それほどスキルは高くないが承認欲求を満たしたい
というエゴだけは強い人物が浮かび上がってくる。 194仕様書無しさん2015/04/21(火) 07:40:03.23
ほんとうは、自説に自信がないんだろうな。
自信があれば、実名出してブログとか技術系投稿サイトに書くはずだもん。
自信のないやつほど、自分のこだわりを人に押し付けるものだけど、
そういうやつは一目みりゃすぐわかる。
僕は自信がありませんという、卑屈なオーラを出しているからな。
そういうのって伝染するから近寄らないほうがいいのです。
195仕様書無しさん2015/04/21(火) 16:39:34.74
196仕様書無しさん2015/04/21(火) 20:50:07.52
>>195
>意見
ではない。単に事実を述べただけだ。 197仕様書無しさん2015/04/22(水) 11:37:29.88
そういう一例もある、というだけの話に過ぎない
19812015/04/22(水) 18:08:13.69
199仕様書無しさん2015/04/22(水) 19:49:48.22
>>1
はどうやらキレやすい子みたいw
まあ最近どこの現場でもフツーによくいるタイプ 200仕様書無しさん2015/04/23(木) 06:59:45.83
＞外注先のプログラマーよりも、発注元の自分のほうが
＞プログラマーとして優れている、だから俺様が教えてやる、
発注元が無能だと、下請けが優秀でも碌な物が出てこない
こんな感じ、発注元がVBで作られたコードを参考に直してくれというなら、
外注はそれに従う。
発注元が、NEC98から更新してDOSV機にしてほしい、言語は自由でというなら、
C++で作ると言う具合だな
201仕様書無しさん2015/05/05(火) 04:38:06.34
ここの人はみんな、保守系底辺派遣PGなのかなぁw？
頑張って綺麗なコード書いて！
202仕様書無しさん2015/05/05(火) 11:11:38.31
ニートは朝早くから元気だなぁ
それとも夜遅くか？（笑）
203仕様書無しさん2015/05/09(土) 17:57:52.32
204仕様書無しさん2015/07/29(水) 19:58:53.66
>>187
研究試作をやっていると、大規模なオープンソースのソフトに、新規に機能拡張するようなケースがある。
そんな場合、ソフトのアーキテクチャというか構造を調べた上で、適切な箇所に、適切な手法で機能を追加することになる。
当然、ソースコードから構造を理解しなけれはならないし。
また納品物には、何故そのように機能拡張するのが正しいのかのエビデンスとして、ブロック図程度は書くことになる。
そういうのを求めているんでしょ？？
まあ、ぶっちゃけ、ある程度のエンジニアなら、誰でもできるだろ。
そんなに難しくないかと。
エンジニアのレベルか見たいなら、ソースコードと、gitなんかのコミットを見るのが一番。
それと、OSの知識を持っているかの確認かな。
素質を見るだけなら、日本語で論理的な文章を書かせてみるのが良いかもね。 205仕様書無しさん2015/07/29(水) 22:30:49.72
206仕様書無しさん2015/07/30(木) 08:30:15.52
207仕様書無しさん2015/07/31(金) 14:55:29.15
ソースから設計図を描き直すのもリバースエンジニアリングだよね。
208仕様書無しさん2015/07/31(金) 15:50:42.45
ソース＝設計図
209仕様書無しさん2015/07/31(金) 17:05:02.35
岡さんbanされちゃった…
210仕様書無しさん2015/08/01(土) 14:33:14.74
ソース＝設計図(カスタムデザインとかオーダーメイドデザインとよばれるべきもの)
設計図＝ベースデザインとかドラフトデザインをさす
211仕様書無しさん2015/08/02(日) 01:07:33.36
詳細設計って必要なの？
建築なら、設計を元に建築するから必要だけど、プログラムはそのままコンピュータが建築してくれんじゃん。
212仕様書無しさん2015/08/02(日) 01:52:17.47
詳細設計をプログラム言語でかけない人間がいるんだよ。
例えれば、英語が話せないのに、英語への通訳の仕事をしている人。
日本語でこれを英語になおしてくれと指示している。
213仕様書無しさん2015/08/02(日) 03:14:28.49
ソースはOnly One Desineで詳細はソースからみてBased(Draft) Desine、基本から見るとCustum Desineとなるものといった方が正しいかな
214仕様書無しさん2015/08/02(日) 04:51:18.60
発音しない文字を書かない主義なら語末のeもオミットするもんじゃないの？
まあ釣りなんだろうけど。
215仕様書無しさん2015/08/02(日) 04:52:39.36
つーか元々e無いじゃんかよ。思わず↑書いちまったよ
216仕様書無しさん2015/08/02(日) 07:38:16.52
設計は言語に依存してはならん、のだとさ
217仕様書無しさん2015/08/02(日) 11:25:47.37
design
だろ…
218仕様書無しさん2015/08/02(日) 11:57:10.75
Only One でシネｗｗｗｗ
219仕様書無しさん2015/08/02(日) 15:29:10.80
>>216
間違いじゃないだろ。
本来継承を使った設計をするべき所で、
COBOLだからそういう設計にはしませんと
いったらおかしいと思うだろ。
こういう設計です。この設計を実装しやすいように
適切な言語を選びましょう。
というのが正しい流れだ。
Rubyではパフォーマンス重視の設計が無理だから
Goに乗り換えたとかいう話もあるよな。 220仕様書無しさん2015/08/02(日) 16:36:17.06
フェイスブックだっけ？
221仕様書無しさん2015/09/06(日) 18:56:52.80
社名 労基
でググると過去の2chスレが出てくる会社
and（orではない）
転職会議で2.5点の会社は超絶要注意
実話です
転職する際は思い出して下さい
222仕様書無しさん2015/09/16(水) 03:31:29.93
うちの大学の教授は
例えば
bool a; があったとき
if(a) てかけるやつはレベルが高いらしい
if( a==1) とか書いてしまうやつはまだまだらしい
223仕様書無しさん2015/09/16(水) 04:28:34.46
>>222
それは正しい。しかも後者は動くだろうが意味的には間違い。
（ただし変数名はisHogeみたいにboolであることが分かる名前にすること） 224仕様書無しさん2015/09/16(水) 12:31:40.62
文脈依存の表記を意味的には間違いと断定する事もまた間違い
225仕様書無しさん2015/09/16(水) 12:48:26.67
boolは0以外と比較しちゃ嫌
226仕様書無しさん2015/09/16(水) 15:23:06.43
227仕様書無しさん2015/09/16(水) 15:23:59.13
228仕様書無しさん2015/09/16(水) 18:14:53.17
if(!IsTrue)は見逃しやすいから意図的にfalseで書く
229仕様書無しさん2015/09/16(水) 20:51:20.74
なんでもかんでもソースコードの末尾に追加する奴は馬鹿だ
挿入する場所が間違ってることが多い
230仕様書無しさん2015/09/16(水) 20:58:27.33
syain、syousaiとかローマ字で書く人
231仕様書無しさん2015/09/17(木) 00:51:31.57
>>230
ローマ字表記はあながち悪くない。
下手な英語の方が困る。 232仕様書無しさん2015/09/17(木) 01:12:16.09
システム用語に合致した用語 ＞ 平易で正しい英語 ＞ 正しいが高度すぎる英語 ＞ オレオレなローマ字 ＞ 下手で間違った英語
233仕様書無しさん2015/09/17(木) 01:14:35.14
最初の項目がなんか変だった
システム用語集やデータベース項目の単語(ローマ字 or 英語)と同じってこと
234仕様書無しさん2015/09/17(木) 08:18:10.95
理想なのが、一目で「意味」が分かる表記だな
下手に分かり難い英単語を見つけてくるよりも、ダサくてもローマ字表記の方がいい。
単語を省略しまくって暗号になっている名前とかも最悪。
しかも、ほぼ同名で1文字だけ違う名前も有ったり、見分けが付かない。。
235仕様書無しさん2015/09/17(木) 10:26:20.54
unicodeのシンボルが使えるから、って
日本語のメソッド名とかやめてほしい
236仕様書無しさん2015/09/17(木) 12:59:02.04
業務系ならそれでいいんだよな。
用語統一できるし。
むしろ、勝手に英語で新しい用語作るなっての
237仕様書無しさん2015/09/17(木) 20:45:55.27
英語でも日本人が分かる英語だからな。
正しい英語にこだわると日本人には分かりにくくなる。
238仕様書無しさん2015/09/18(金) 00:06:49.66
他人のソースにケチつけるほどディープに関わらない。
インターフェースだけやり取り。
昔はソースコードレビュー派で完璧を目指したが、
今はうんこが混ざっても担当部分をハッキリさせた方良いと思ってる。
239仕様書無しさん2015/09/18(金) 00:20:35.52
>>238
一生その人が担当するならそれでもいい。 240仕様書無しさん2015/09/18(金) 00:41:08.79
カプセル化が何たるかを分かってないやつがいるな。
テストが通ってれば、うんこだろうと構わないし、中にあるこがのうんこであることを知る必要もない。
インタフェースとテストが全てだよ。
241仕様書無しさん2015/09/18(金) 02:14:28.46
と、うんこが申しております
242仕様書無しさん2015/09/18(金) 02:31:23.13
中身の分からないシステムを管理したことがない（またはできない）人発見。
APIだけは作りを全部知らなくても使っていいとか言うなよ？
243仕様書無しさん2015/09/18(金) 03:51:26.50
>>240
中身をレビューしたり、デバッグしたり、仕様変更したりしないならそれでもいい。 244仕様書無しさん2015/09/18(金) 08:15:51.43
>>243
うんこ作りそうなやつに影響大きいもん担当させるなアホ 245仕様書無しさん2015/09/18(金) 12:26:29.40
と、影響の大きいうんこ製造者が申しております
246仕様書無しさん2015/09/18(金) 14:27:54.01
247仕様書無しさん2015/09/18(金) 16:22:40.15
うんこの混入を許さないシステムは
拡張性の低いうんこなんだよ。
248仕様書無しさん2015/09/18(金) 18:24:33.56
単語を正しく置き換えると
「問題のあるコード」の混入を許さないシステムは
拡張性の低い「問題のあるコード」なんだよ。
なんか文章が意味不明だな。
249仕様書無しさん2015/09/18(金) 19:05:09.85
うんこはうんこだ
他の何物でもない
250仕様書無しさん2015/09/18(金) 19:14:16.25
うんこの話ならうんこ板でやればよくね？
251仕様書無しさん2015/09/18(金) 20:49:19.06
252仕様書無しさん2015/09/18(金) 22:49:45.61
単にうんこ不足だ
253仕様書無しさん2015/09/19(土) 00:50:23.98
この世界に足りないのはうんこだ
254仕様書無しさん2015/09/27(日) 11:47:50.91
社名 労基
でググると過去の2chスレが出てくる会社
and（orではない）
転職会議で2.5点の会社は超絶要注意
and
IT系です
転職の際はご注意ください
255仕様書無しさん2015/09/29(火) 01:03:17.56
>>234
「お前のコードを外国人も読む可能性がある、ウソ英語で構わないから英語でやれ」
という教育を受けたかどうかによるな。
まあ現場による。 256仕様書無しさん2015/09/29(火) 05:31:18.34
ウソ英語で良いという理屈だと、
日本人が読む可能性があるから
ウソ日本語でも良いということなんだよな。
そんなコメントに何の意味があるのか？
正しい日本語は、英語に翻訳できるが
ウソ日本語は、日本語にも英語にも翻訳できない。
ウソ英語も同じ、英語にも日本語にもならないのに
情報としての価値はない。
257仕様書無しさん2015/09/29(火) 08:37:17.34
>>256
俺もそう思って日本語関数とか作ってたらスゲー怒られたw
外人さんだと、さすがに漢字の違いの識別すら困難らしいw 258仕様書無しさん2015/09/29(火) 08:53:32.92
>>257
日本語が間違っている問題と日本語が読めない問題は全然違うんだが。大丈夫？
あんたんとこは外人のためにコメントも英語なのか？
それともコメントは読めなくても問題ないの？ 259仕様書無しさん2015/09/29(火) 09:06:32.95
>>257
日本語関数はありえないな。
なぜなら関数はどちらにしろ短い名前になる。
というか文章というか名前。
で関数名が名前じゃなくて文章になるような
関数は作るべきじゃない。 260仕様書無しさん2015/09/29(火) 09:24:55.70
マイクロソフトの悪口はそのくらいにしておけ。
261仕様書無しさん2015/09/29(火) 09:45:45.29
コメントくらい英語で読み書きしろ
262仕様書無しさん2015/09/29(火) 10:56:47.16
263仕様書無しさん2015/09/30(水) 01:24:42.91
日本語のコメントの中唐突に現れる英語コメント
どう見てもコピペです本当に以下略
264仕様書無しさん2015/09/30(水) 01:38:46.35
ジャパニーズのコメントの中にサドゥンリー現れるイングリッシュコメント
どうみてもルー大柴です。
265仕様書無しさん2015/09/30(水) 02:21:19.08
どんなカタコトな文法の英語でもグーグル翻訳を介すとあら不思議、
素晴らしく解りやすい日本語に変換される。
そんな英語のコメントを私は残したい。
グーグル翻訳で暗号のような英文をエンコード、デコードして日本人同士通じあうのだ。
266仕様書無しさん2015/10/16(金) 07:58:32.48
変数名、関数名は単純に英語にはしづらい物もあるからなぁ。
医療やってるけど、健康保険はKenpoで、あんまり英語にはしない。民間保険とごっちゃになるし。
入院中他科外来、とか。
それより変数名や引数名の頭に、内部コードか、外部コードか、ただの行位置か、検索キーか持ってるのを徹底してるコードの方が技術力と言うより、
技術力が無いかもしれなかったり、ポカミスがあったりするかもしれない可能性を出来るだけ避けようとしている
って感じで、
その人の逆説的な意味での技術力が高評価になる。
267仕様書無しさん2015/10/16(金) 12:25:29.93
正しいハンガリアン記法やね
268仕様書無しさん2015/11/18(水) 12:02:07.49
転職の際に必ず思い出してください。
下記の条件が全て当てはまる会社にご注意下さい。
・IT系 in 東京
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される
269仕様書無しさん2015/11/19(木) 02:37:40.16
【 オンラインTCGエディター 】 >>1
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーローなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリ−グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ〜て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
http://wc2014.2ch.net/test/read.cgi/entrance2/1447639727/-18 270仕様書無しさん2015/11/19(木) 12:31:40.88
型シノニムじゃダメなの？
271仕様書無しさん2016/02/01(月) 20:44:32.43
わかるようなきがするだけだ
科学的根拠をもって確かめられたことではない
272仕様書無しさん2016/02/11(木) 13:11:11.21
例えば、昔かいたソース見てわかるとか言われてもなあ
273仕様書無しさん2016/02/11(木) 23:08:44.13
age
274仕様書無しさん2016/02/13(土) 00:11:08.62
人のコードを読む際の、この変数はこうで、あそこのフラグがどうで、ここでループに使用している変数が1増えて…
といった感じでたどたどしく読むのがもっとなんとかならんか、と思う。
英語が得意な人が英語をスラスラ読めるように
コードがスラスラ読めるようにならないものか。
275仕様書無しさん2016/02/13(土) 01:16:29.39
>>274
なる。
・決まり切った書き方やアルゴリズムを覚えろ。
・ひとつの関数を読むとき、呼び出し先の関数やクラスの中まで読むな。
・変数のスコープと役割を把握しろ。
・ちょっとでも分かったことはひたすら書き留めろ
そしてもっとだいじなこと
・まずコードの前に仕様書と設計書を読め。
・書いてなかったら作成者に聞くか書かせろ。
・それもだめなら処理内容を聞け。
・それもできないならデバッガを動かせ。
他人のコードを読むなぞ、趣味で勉強かハッキングでもしてるのでなければ
本当に最後の最後の手段
基本的には時間のムダだ。仕事としては筋が悪いことこの上ない。 276仕様書無しさん2016/02/14(日) 11:02:06.06
277仕様書無しさん2016/02/14(日) 20:34:27.77
>>275
ありがとう。
それを念頭に仕事してみる。 278仕様書無しさん2016/02/15(月) 11:15:24.17
>>275
> 他人のコードを読むなぞ、趣味で勉強かハッキングでもしてるのでなければ
> 本当に最後の最後の手段
最近はそうでもないんだなこれが。
サードパーティーのライブラリを多用するのが普通になって、挙動がおかしい場合は
ググったりするよりコード見たのが早いケースが多い。 279仕様書無しさん2016/02/15(月) 13:01:39.59
自分のコードも３ヶ月経ったら
他人のコード
280仕様書無しさん2016/02/15(月) 13:26:56.33
>>275
> 他人のコードを読むなぞ、趣味で勉強かハッキングでもしてるのでなければ
> 本当に最後の最後の手段
GitHubとか知らないんだろうなぁ 281仕様書無しさん2016/02/15(月) 13:44:06.03
>>280
GitHub使ってるのって、全プログラマの1割未満じゃないか？ 282仕様書無しさん2016/02/15(月) 14:01:24.38
283仕様書無しさん2016/02/15(月) 15:01:35.05
>>282
めんどくさい奴だな。プログラミングを職業にしてりゃプログラマだよ。 284仕様書無しさん2016/02/15(月) 17:52:48.33
組み込み系の連中はGitHubなど使わないだろう
285仕様書無しさん2016/02/15(月) 21:45:32.54
でgithub使ったらなんなのさ
286仕様書無しさん2016/02/15(月) 21:49:15.43
GitHubを使っていないプログラマは例外なくカス
287仕様書無しさん2016/02/15(月) 21:56:28.89
は？突然何いってんのこいつ？
288仕様書無しさん2016/02/15(月) 23:58:14.23
289仕様書無しさん2016/02/16(火) 00:03:26.24
290仕様書無しさん2016/02/16(火) 01:14:05.77
ドキュメントGitに入れようとしたらおこられた
ExcelはSVNにしとけ！って…
どういうこと
291仕様書無しさん2016/02/16(火) 01:55:18.78
当たり前だろ。
バージョン管理するメリットがない。
そんなのただのバックアップで十分
292仕様書無しさん2016/02/16(火) 02:19:45.67
gitは使ってるけどgithubは使うてないわ
293仕様書無しさん2016/02/16(火) 08:02:11.73
俺もgit３年使ってから初めてgithub貫通した
294仕様書無しさん2016/02/16(火) 08:06:26.80
>>290
gitはデカめのバイナリが苦手だもんね
最近のverはどうなんだろ 295仕様書無しさん2016/02/16(火) 08:08:15.10
>>290
騙されたと思って一度やってみるといいよ
少し経つとrepo肥大化してどうしてこうなった・・・状態になると思うよ 296仕様書無しさん2016/02/16(火) 08:44:44.14
道具に縛られてるうちは半人前
297仕様書無しさん2016/02/16(火) 09:10:29.20
>>296
もっともらしいことを言ってみたかった？ 298仕様書無しさん2016/02/16(火) 11:09:10.92
作業に合った道具を選べよ
299仕様書無しさん2016/02/16(火) 12:31:49.11
でgithubやったら他人のコード読まんといかんのか？
300仕様書無しさん2016/02/16(火) 12:54:20.50
>>299
読まなきゃいけないみたいな表現してる時点でお前はドカタ確定な 301仕様書無しさん2016/02/16(火) 13:19:15.03
ＦＪネクスト迷惑電話で検索しよう
302仕様書無しさん2016/02/16(火) 14:40:13.70
303仕様書無しさん2016/02/16(火) 20:21:17.66
そんなのいちいち読んでられるか
304仕様書無しさん2016/02/16(火) 20:21:29.93
>>302
は？読みたけりゃgithub関係なく他人のコードなんかいくらでも読めるぞ
それより誰か>>280を説明しろよ 305仕様書無しさん2016/02/16(火) 21:04:08.67
>>299
根源的な所で、プログラミングが楽しくないのですね
義務でやってるなら、やめてください 306仕様書無しさん2016/02/16(火) 22:43:28.62
幸福という義務を押し付けるNard
307仕様書無しさん2016/02/16(火) 23:39:23.32
プロ野球選手なら、野球好きだろっていうようなもんだろ。
別に仕事で野球やってるんだから好きとは限らねぇよ。
コンビニ店員とか土木工事とか好きでやってると思うか？
308仕様書無しさん2016/02/17(水) 02:45:24.68
>>290
肥大したリポジトリは、分散型だとキツイもんな。SVNなら各自必要なドキュメントだけローカルに落とせばいいし。 309仕様書無しさん2016/02/17(水) 02:56:55.56
>>275
プログラマー様曰く、コード=設計書らしいからな 310仕様書無しさん2016/02/17(水) 08:32:46.95
>>306
それNardじゃなくてNerdじゃね？ 311仕様書無しさん2016/02/17(水) 12:22:39.89
インターネット接続がなくても使えるなら使ってやってもいい
312仕様書無しさん2016/02/17(水) 21:22:47.75
313仕様書無しさん2016/02/20(土) 13:59:13.74
【主な偽装請負従犯要員SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理
[業務ソフト作り捨てツール]
ノンプログラミングツール
フレームワーク
COBOL
VＢ
.net
Java
Web
DB
ERP
SAP
314仕様書無しさん2016/02/21(日) 09:42:51.30
使い捨て早死に貧困の助長SEは大迷惑
相場下がって迷惑だから偽装請負の従犯は辞めろ！
・1,000万円/年以下低レベルの会社は辞めろ
・80万円/月以下低レベルの契約は辞めろ
・5,000円/時間以下低レベルの契約は辞めろ
・多重契約は辞めろ
・不利益な現場は辞めろ
・残業見積りは辞めろ
・時間外労働違反は辞めろ
・契約外納期は守るな
・客先指示に従うな
・知的財産を渡するな
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ
【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/ 315仕様書無しさん2016/02/23(火) 13:20:50.14
ERPなんかはSAPならドイツ、AWSやsalesforceならアメリカで基幹部分は作っていて、
その日本人スタッフが日本仕様にカスタマイズして、日立とかのコンサル屋に卸して
いるから、末端でABAPやJAVA触っているレベルじゃ単なる仕様書→コードの書き換え屋
にしかならない。この仕様書書いてるレベルが日本資本下請けITの限界か。
旧NETWEAVERの基幹コードなんて読んだことある日本人ほとんどいないでしょ。
あとは各社の業務に合わせようとしているだけ。
これならきっちりしたコード書く高いPGより、若くてデスマOKな派遣や請負ドカタ仕入れて
書かせるか、ベトナムやフィリピンに外注したほうが安い。
動きゃいいんだよレベルだが。ほぼスクラッチから書かせているWEB系の方がまだ真剣かも。
316仕様書無しさん2016/02/23(火) 15:09:53.34
NetWeaverのコードを読んだ経験だけが唯一のよりどころのジジイ
317仕様書無しさん2016/02/24(水) 19:53:01.56
318仕様書無しさん2016/02/24(水) 19:54:28.25
319仕様書無しさん2016/03/13(日) 08:05:32.33
残業SEは大迷惑！
時間外労働違反となる
契約に作業期限はない
契約の延長がなくなる
健康障害をもたらす
対人障害をもたらす
能力評価が低下する
生産評価が低下する
時間報酬が低下する
学習時間が減少する
副業時間が減少する
訴訟が増加する
失業が増加する
貧困が増加する
独身が増加する
早死が増加する
321仕様書無しさん2016/05/07(土) 05:57:45.66
>>319
残業したくない人はこの業界に向いてないんじゃ…。 322仕様書無しさん2016/05/07(土) 06:35:30.49
残業したい奴なんて、仕事ができない奴だけだろう
残業しかアピールする方法がないんだし
323仕様書無しさん2016/05/07(土) 07:00:20.24
>>322
定時で帰る習慣がないところは、定時で帰るようにやっても定時で帰れない。
定時で帰る人と思われるようになれば可能性だが、定時以降に話が進んでしまうので、デメリットもある。 324仕様書無しさん2016/05/07(土) 07:19:24.57
残業しなければ情報共有されないってのも おかしな話だな
325仕様書無しさん2016/05/07(土) 07:31:55.52
326仕様書無しさん2016/05/07(土) 07:35:03.74
そんな現実は知らん
もっぱら残業時間に話を進めて、残業しない奴には
情報共有しないとかいう虐めでも流行ってんの？
327仕様書無しさん2016/05/07(土) 08:25:02.48
残業はやれる内にやっておいた方がいい
328仕様書無しさん2016/05/07(土) 08:27:35.19
俺もそんな"現実"は知らんな・・・
どんなに酷い状況でも、
ミーティングは必ず昼間に行われたし
重要なことはデジタルな形で共有されてた
329仕様書無しさん2016/05/07(土) 10:43:42.55
「」とか¨¨とか無意味に使う馬鹿多いよね
330仕様書無しさん2016/05/07(土) 11:16:25.44
平日は早く帰ってもどうせやることないから、残業代でも稼いでいたい勢ですｗ
331仕様書無しさん2016/05/07(土) 12:24:42.42
それが現実。
332仕様書無しさん2016/05/07(土) 17:47:39.96
もっと残業やらせてくれ勢です
333仕様書無しさん2016/05/08(日) 14:25:35.68
334仕様書無しさん2017/03/19(日) 09:50:40.76
>>10
オープンソースのコードを
実際に見たことのない事が良くわかるレス
重要なのはテストだよ 335仕様書無しさん2017/06/11(日) 13:27:08.03
いあ
336仕様書無しさん2017/07/07(金) 13:21:00.38
給料だけもらっておうち帰りたい
337仕様書無しさん2017/07/11(火) 13:10:15.80
public static Manko m = new Manko();
m.insert(tinko);
338仕様書無しさん2017/07/11(火) 22:38:40.53
やめてくれ、明日マジで書きそうだ
339仕様書無しさん2017/07/22(土) 17:56:05.39
書いてもいいのよ？
340仕様書無しさん2017/11/30(木) 23:24:15.60
開発する力が高いのは確かなんだけど
こっちの業界人特有の特徴が出てしまっている
機能の盛り込みが優先してしまって
使い易さが考慮されてない
341仕様書無しさん2017/12/29(金) 19:56:37.22
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
H3IRM1N6S1
342仕様書無しさん2018/02/16(金) 01:11:28.68
☆ 私たち日本の、改憲を行いましょう。現在、衆議員と
参議院の両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
343仕様書無しさん2018/03/30(金) 21:32:29.90
彼の作り方というか思想がわかってきたな
経験が浅い人と同じ作り方、最もトラブルを起こしやすい類
344仕様書無しさん2018/05/22(火) 14:59:05.26
とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
IHVY0
345仕様書無しさん2019/08/02(金) 02:36:44.10
コードをまともに書けない、今後書くこともない人が
コーディングルールを決めると酷いもんだね
あれは多分色々障害にしかならない
346仕様書無しさん2021/08/16(月) 19:53:53.86
ソースは８割以上の人間が理解できるように書かないとダメ。
独り善がりで難解なロジックを書く奴は大抵無能。
ソフトウェアのライフサイクルを考えた場合、実行効率よりメンテナンス性の方が大事。
347仕様書無しさん2021/08/16(月) 20:48:04.16
AIのエンジンを難解じゃないロジックで書いてみてくれ
そういうことだよ
348仕様書無しさん2021/08/17(火) 01:55:28.66
349仕様書無しさん2021/08/17(火) 19:23:32.43
