◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net ->画像>16枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/prog/1422621412/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1仕様書無しさん
2015/01/30(金) 21:36:52.73
納期に苦しんでいるSEさま必見の情報です。
今すぐコードが綺麗か汚いかを
ツールを使って調査してみましょう
2仕様書無しさん
2015/01/30(金) 23:53:54.99
リア充のイメージ
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
>>1のイメージ
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
3仕様書無しさん
2015/01/31(土) 00:10:43.49
>>1
コードがクソなのは設計がクソなのはだからな。
4仕様書無しさん
2015/01/31(土) 00:32:43.44
>>2
1番下初見だわwww
5仕様書無しさん
2015/01/31(土) 08:03:48.11
それっぽく見えるけど、あれあれってのもあるかもね
6仕様書無しさん
2015/01/31(土) 08:32:19.44
>>3
設計通りに書くのは無能のコーダー
バイト君レベル
設計通りだと汚くなりそうなら提案する
実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ
設計の早期修正は他メンバーを楽にさせる点(1人のコストで10人のコスト削減)で重要
勿論その実績をまとめておいて後で賞与面接とかでアピールするんだぞ
7仕様書無しさん
2015/01/31(土) 09:02:58.53
そんなのが賞与に反映されると思ってるんだ。
8仕様書無しさん
2015/01/31(土) 09:24:33.73
太鼓持ちにならないと増えませんからね
9仕様書無しさん
2015/01/31(土) 10:23:47.52
>>6
>設計通りだと汚くなりそうなら提案する
>実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ

報酬をケチるから、そういうバイト君しか来ないんだろ。
良い人材が欲しければ、それなりに払えよ。
10仕様書無しさん
2015/01/31(土) 12:07:36.92
どこかの研究か調査で分かったの?それならそのソースは?
昔から割と言われているプログラマーの生産性は数十倍違うってやつは
1950年代だったか1960年代だったかに実際計測して出た数字だから
今でも折にふれて言われているわけで。

>>1の根拠になるソースはどこ?体感()?
11仕様書無しさん
2015/01/31(土) 13:57:04.58
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚


これエロすぎだろwwww鼻血出るわwwwwww
12仕様書無しさん
2015/01/31(土) 15:09:10.65
割り込み電話と、無駄な会議を減らせば、それだけで生産性10倍いきそうだな。
13仕様書無しさん
2015/02/01(日) 09:05:53.59
設計を直すだけならいいけど、そういう奴は大抵仕様を変更しようとするからな。
14仕様書無しさん
2015/02/01(日) 12:35:07.68
コードコンプリートの下巻にこの話題があったな
15仕様書無しさん
2015/02/02(月) 19:48:10.79
無能残業して時間報酬相場を下げるな
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死
16仕様書無しさん
2015/02/02(月) 21:08:42.11
コードが汚いとかわりと関係無くて、関数やクラス分けがメチャクチャとかのがデスマーチになり易いよ。
17仕様書無しさん
2015/02/02(月) 21:38:37.36
>>16
そういうのを汚いと言う。
18仕様書無しさん
2015/02/03(火) 06:21:15.47
0と1というビットの反転で済むところが全部 x = 1 - x; なんて書かれていたから
x ^= 1; へ修正するのに手間が掛かり過ぎた。
19仕様書無しさん
2015/02/03(火) 07:28:06.37
WebやDBなんてパートがやるべき
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死
20仕様書無しさん
2015/02/03(火) 08:17:28.34
手入力を増やしてしまう低技術者
なんとかならないかな?
21仕様書無しさん
2015/02/03(火) 08:20:28.66
>>18
わりとどうでもいい事の例えかな?
最近のコンパイラに掛かれば同じコードに変換されてるみたいな。
22仕様書無しさん
2015/02/03(火) 08:41:28.35
>>18
自分の巣に帰れよ。キチガイ野郎
23仕様書無しさん
2015/02/03(火) 11:38:31.54
>>20
>手入力を増やしてしまう

どういう状況?
24仕様書無しさん
2015/02/03(火) 12:03:46.85
>>23
そのシステムの画面か、データベースに直接、データを登録するとかじゃないの?
25仕様書無しさん
2015/02/03(火) 12:21:22.72
よくSEがいう「運用で対応します」ってやつだろw
システム化に失敗しましたって意味でも有る。
26仕様書無しさん
2015/02/03(火) 12:42:41.47
>>25
設計や実装のまずさを手作業で修正、ってのは失敗だけどね。
ただ、システム化=オールコンピュータ化では必ずしもない。
機械に任せた方が良い部分と手作業が良い部分との区別は必要。
結果的に殆ど機械化というのも当然あり。
事務システムの移行で、氏名の一部が外字登録されてたケースがあったが、
手作業だと年7人日、機械化すると200万円くらい掛かるってんで、
今でもそこは手作業でやってる。
27仕様書無しさん
2015/02/03(火) 13:09:33.18
>>23
ツール作らない状況です。
28仕様書無しさん
2015/02/07(土) 11:12:20.98
普通ならメインの処理メソッドの中に、処理Aの呼び出し、処理Bの呼び出し・・・って感じで書くと思うが
とある現場のプログラム見たら、メイン処理の末尾で処理Aの呼び出し、処理Aの末尾で処理Bの呼び出し・・・
って感じで書かれてて、眩暈がした
さらに再帰は全て関数で実現してるし、どんだけコールスタック積むつもりだよwww
29仕様書無しさん
2015/02/07(土) 11:17:59.46
>>28
プログラミング初心者がよくやる。
30仕様書無しさん
2015/02/07(土) 11:23:31.53
>>28
すまんが、お前の指摘は
コールスタックだけだよな?
31仕様書無しさん
2015/02/07(土) 11:47:46.58
結婚希望者は不適合
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死
32仕様書無しさん
2015/02/07(土) 15:58:34.08
コールスタックなんて真っ先にオプティマイズされちまう些細な問題だろ。
33仕様書無しさん
2015/02/07(土) 17:04:35.15
話がそれるかもだが、以前ローカル変数で1Mぐらいのバッファを宣言してるのを見てびっくりした。
スタック溢れないの?と聞いたら、ダイナミックスタックだから溢れない。と言われて、さらにびっくりした。
34仕様書無しさん
2015/02/07(土) 21:58:58.87
>>33
ダイナミックスタックって何よ?
足りなくなったらヒープから取るのか?
35仕様書無しさん
2015/02/08(日) 12:59:23.93
>>34
アドレスだけ足りてればメモリはどっかから取ってくるよ。
仮想記憶を勉強してからまたおいで。
36仕様書無しさん
2015/02/08(日) 15:04:28.69
>>35
実装されてるシステムあるの?
37仕様書無しさん
2015/02/08(日) 15:09:46.36
初めからちんたら綺麗なコード書いてても時間かかるの同じ
38仕様書無しさん
2015/02/08(日) 19:20:47.33
>>37
きれいなコードを書くのに時間がかかるという前提が間違ってるよ。
むしろ綺麗なコードを書く人の方が開発速度速いから。

絵がうまい人が、絵を描くのも速いのと同じようなものかもしれないね。

綺麗なコードを書くのが遅いのは、綺麗なコードを書いたことがないから。
書いたことがないから、汚いコードを書く。それを直そうとすると時間がかかるのは当たり前
どうすればいいかわからないからね。初心者が書くのが遅いのも同じ理由。

でも綺麗なコードを書いたことがある人は、前にやったパターンを
なぞるだけだから、最初から綺麗なコードを書ける。だから速い。
39仕様書無しさん
2015/02/08(日) 19:23:25.92
デスマにしないとホクホクできないブラックさんが・・・
40仕様書無しさん
2015/02/08(日) 19:29:26.34
>>35
お前再帰関数のスレでも訳の分からん事書いてるだろ
41仕様書無しさん
2015/02/08(日) 20:16:43.71
関数の最後で関数コールしてるコードでは、普通ジャンプ命令に置き換わってるから、気にすんな。
みんなみんな賢いコンパイラさんが解決してくれてるよ。
42仕様書無しさん
2015/02/08(日) 20:27:52.13
>>39
デスマってもともとのスケジュールが悪いのが
大きな原因だけど、

技術力が低いっていうのもやっぱり原因の一つなんだよね。

自分のところの開発フローの効率化も出来ない奴が
他社のシステムの効率化なんて出来ないわけで。
43仕様書無しさん
2015/02/08(日) 20:47:35.45
>>42
はあ?
44仕様書無しさん
2015/02/08(日) 20:58:27.79
>>43
はぁじゃねぇよw

俺がやったら5分で終わったバグの修正に
いちいち報告文とか書いて、これを修正するべきか?とかいう
やりとりをいちいちやってたからな。

技術力が低いから修正する時間がかかるから
やらなくて済むならやらずにいよう(ユーザー喜ばない)
そのために無駄な時間をかけて、そんなことだから
デスマになるんだと思ったね。
45仕様書無しさん
2015/02/08(日) 21:34:39.35
>>44
おまえマネジメントも上流工程もやったことないだろ?
46仕様書無しさん
2015/02/08(日) 21:38:44.79
>>45
それ、何も言い返してないからw
47仕様書無しさん
2015/02/08(日) 21:51:17.07
>>46
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
48仕様書無しさん
2015/02/08(日) 21:53:25.02
>>42
デスマについて多い勘違いだね。
デスマってのは、スケジュールひく前に運命が決まるんだよ?
49仕様書無しさん
2015/02/08(日) 22:06:34.36
>>48
そうだよね。仕事の速度の問題じゃないからね。
50仕様書無しさん
2015/02/08(日) 22:17:44.75
うん。だから最初から余計なミーティングが問題だって言ってる。

ミーティングするにも時間はかかるわけで
簡単にすぐにできることにいちいちミーティングする?

そういう余計な会議で時間を無駄にしてるんだよ。
51仕様書無しさん
2015/02/08(日) 22:33:34.41
デスマが運命とか怖すぎ
52仕様書無しさん
2015/02/08(日) 23:15:19.44
ミーティングで納期が延びたらいいのにね
53仕様書無しさん
2015/02/08(日) 23:31:45.37
SEというのは血の巡りが悪いんだから、
プログラマからみれば会議していてもむだ

プログラマの頭の血のめぐりが悪いときは会議でなく散歩だね
会議でじっとしていることが、血行をわるくさせる
会議なんてものはSEの責任逃れ
54仕様書無しさん
2015/02/08(日) 23:53:56.67
>>51
デスティニー・マネジメント?
55仕様書無しさん
2015/02/09(月) 00:52:22.33
>>54
「人月の神話」で検索。
56仕様書無しさん
2015/02/09(月) 01:18:46.40
頭にアホ置いた時点で確定するから始まった瞬間に運命決まってるようなもんだ
57仕様書無しさん
2015/02/09(月) 02:47:31.21
死の三月
58仕様書無しさん
2015/02/09(月) 11:35:22.99
>>36,40
スタック領域 自動拡張
でググったらすぐでるじゃん。
まさか検索もしないでそんな投稿するなんて思いもしないから、英語で検索しないと出ないのかと思っちゃったよ。
すぐに手を動かさない奴は伸びないよ。
59仕様書無しさん
2015/02/09(月) 14:35:00.72
>>58
いや、具体的なシステムを知りたいんだが
60仕様書無しさん
2015/02/10(火) 19:25:54.41
無能残業者へ
SEの職務は、手入力を減らす事だと
わかってますか?
61仕様書無しさん
2015/02/10(火) 21:29:57.40
1行目と2行目がまるで噛み合ってない
本人は言いたいこと言えたと思ってるんだろうけど、伝えたいことがまるで伝わらない典型例みたいな文章だな
62仕様書無しさん
2015/02/11(水) 00:03:57.63
俺はわかったけど?
63仕様書無しさん
2015/02/11(水) 00:42:37.77
分かったと思って実は違ってたパターン
64仕様書無しさん
2015/02/11(水) 00:51:02.84
一行目は二行目以降のメッセージを伝えたい相手を特定してるだけだから
噛み合うとか噛み合わないの問題ではない。
65仕様書無しさん
2015/02/11(水) 23:42:39.13
http://daily.2ch.net/test/read.cgi/newsplus/1423664509/
【社会】 ソースコードは指紋… レイアウト、語彙、構文の特性で
作者はほぼ特定できる、その精度95%以上!
66仕様書無しさん
2015/02/24(火) 14:11:40.91
コードが汚くてもコストは変わらん
人月契約の作業者が疲弊するだけ
67仕様書無しさん
2015/02/28(土) 10:11:23.55
バク増えて品質は落ちるけどな
68仕様書無しさん
2015/03/04(水) 23:37:31.77
パクリ増えてに見えたw
69仕様書無しさん
2015/03/11(水) 05:13:45.86
工数を増やすために汚くしておくんだ
短くきれいで安いのでは困る
70仕様書無しさん
2015/03/13(金) 11:28:04.33
>>69
プログラミングの価値を、コード量で測ろうとしてるもんな。
重要なのは、改善効果の金額換算だろ。
71仕様書無しさん
2015/04/07(火) 16:08:16.36
今時、日立ですらコード量で仕事量ははからないんだが
どこの話なんだろうか
72仕様書無しさん
2015/04/13(月) 20:07:05.64
中華の作ったゴミ見るたびに全部書き換えたくなる
つーかあいつら書いたコードゴミすぎてみてるだけで吐きそう
73仕様書無しさん
2015/04/13(月) 21:00:33.69
開発終わるとステップ数数えさせられるんだが、今時そんなことしないの?
74仕様書無しさん
2015/04/13(月) 22:06:13.84
>>73
ステップ数はコストだよ?

同じ機能をある人は100行で作りました。
ある人は全く同じものを10000行かけて作りました。

どちらがコストがかかってるでしょう?
言うまでもなく後者だよね。

バグや機能修正が入った時、100行のコードから該当箇所を修正します。
ある人は、10000行の中から該当箇所を探し出します。

どっちがコストがかかるでしょう?
言うまでもなく後者だよね。

それを理解して、ステップ数を数えてこの人は行数が多い!
たったこれだけの機能をこんなに時間かけて作るんじゃねーよ
大赤字じゃねーか。っていう判断に使うのなら問題ない。
75仕様書無しさん
2015/04/13(月) 22:24:28.28
>>74
なんていうか、くどいなー
76仕様書無しさん
2015/04/13(月) 23:17:35.25
ステップ数が多いほど生産性が高いとかのたまうのが東証一部上場企業のPMだから終わってるわ
いしど
77仕様書無しさん
2015/04/25(土) 15:45:38.43
きれいなコードだなぁと思ったら異常処理が一切書かれてなかったでござる
78仕様書無しさん
2015/04/25(土) 16:53:57.26
プログラムは簡単という奴が書いたソースはほぼそれ
79仕様書無しさん
2015/04/25(土) 19:41:39.24
異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。
80仕様書無しさん
2015/04/25(土) 20:13:08.13
使うのが自分自身だけなら問題はない
他人が使うもので非対策はゴミ以下
81仕様書無しさん
2015/04/25(土) 20:29:11.16
異常系からのリカバリーを要求されるシステムだって世の中にごまんとあんのにな
82仕様書無しさん
2015/04/25(土) 22:02:47.66
要求されるならリカバリーが必要だな
83仕様書無しさん
2015/04/25(土) 22:25:29.99
リカバリ出来るのは正常系やで
それを異常系と呼んで場当たり的な対処で済まそうとするから
見るもおぞましいソースコードが出来上がるんや
84仕様書無しさん
2015/04/25(土) 22:58:35.57
>>79
> 異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。

わかってるねw

異常系に対するだめなコードは、エラーが発生する可能性があるから
発生した時に何かしなきゃいけない。と可能性がある場所毎に
何か書くこと。その場でログを出力するとかね。

そんなことやるから、あちらこちらに異常系のコードが大量に
生産されてしまうし、見逃しも沢山生まれる。

そんなことせずに、異常になった時に絶対呼ばれる部分があるんだから
そこにコードを一つ、または数個かけばいいだけ。

あとはまれにそれだけじゃ不十分な時に、追加のコードを
書くだけでいいんだよ。リカバリできる異常状態も
まれなんだから、リカバリできる場合に限って対処すればいい。

やり方が正反対なんだよな。
85仕様書無しさん
2015/04/25(土) 23:28:48.57
まったくわかってないね
実務経験あるの?
86仕様書無しさん
2015/04/26(日) 04:02:02.98
>>84
Windowsで言うところのブルースクリーンだな
復帰不能
87仕様書無しさん
2015/04/26(日) 07:50:30.00
どんなエラーも再起動が唯一の復帰手段、アホか
88仕様書無しさん
2015/04/26(日) 11:53:39.51
>>85
悔しいからって、負け惜しみ言うだけで
消えるなよw
89仕様書無しさん
2015/04/26(日) 11:54:25.37
>>87
それは論点ずれすぎてるw
わかってないよお前。
90仕様書無しさん
2015/04/26(日) 13:18:51.35
俺わわかってる。

要はエンジョイコーディングってことだろ?
91仕様書無しさん
2015/04/26(日) 14:56:29.83
異常処理は書かないwwww
92仕様書無しさん
2015/04/26(日) 15:27:09.91
>>83
そうなんだよね。
リカバリー出来る様にするならそれは正常系なんだよ。
設計のバカが担当が異常系で処理させれば済むって事で
初期の設計に入れてないんだよw
93仕様書無しさん
2015/04/28(火) 18:45:01.75
エラーを無視すれば、どんなエラーが出ても
続行できる。
94仕様書無しさん
2015/04/30(木) 05:32:00.21
>>93
エラーが物理的な要因による物でもそう言えるならあんた帰っていいよ。
95仕様書無しさん
2015/05/23(土) 10:09:24.72
>>71
未だにやってるよ
設計もしてないのにステップ数から
見積りとかバカかと言ったら
逆ギレされた
96仕様書無しさん
2015/09/16(水) 14:15:27.14
俺は綺麗なコードや汚いコードに基本文句を言わない。
ある程度スパゲティでも構わないし (いや実際には構うんだけど) 苦情や文句を言うこともない。
2ちゃんねるとかで質問者が変な書き方したがっててもいちいち突っ込まない。
同じ書き方で回答を提示する。

しかしそんな俺でも許せないものが一つある。
書き方が一貫してないコード。

特に複数人で修正して回ったようなスパゲティコードは手に追えない。
たぶん納期に追われてプログラマが辞めながら作って行ったらしきコードなんだろうけど、
これだけは本当にどうにかしてほしい。
97仕様書無しさん
2015/09/17(木) 12:30:24.05
思想が一貫してれば書き方なんかどうでもいいわ
>>96は多分思想がバラバラなんだろうけど
98仕様書無しさん
2015/09/17(木) 12:43:39.63
昔関数作ったら関数仕様書を作るプロジェクトがあった
その場合人は関数を作らないようにするためその関数の中で修正してしまう
こうして数千行の関数が量産されていく
そこで新たに関数を作ろうものなら空気が読めない人間になる
生きて行くって難しい
99仕様書無しさん
2015/09/17(木) 21:16:49.01
あるある
最長1万行の関数を見たことが有る
100仕様書無しさん
2015/09/17(木) 21:34:25.02
世の中って本当に難しいな
101仕様書無しさん
2015/09/18(金) 00:37:54.43
>>99
意図的にそれで手続きが問題ないならたいしたスキルだよ
102仕様書無しさん
2015/09/18(金) 06:29:38.61
>>101
マジレスすると意図的に長い関数を書くのは割と簡単
気をつかうのは変数名ぐらいで良い
無意識に長い関数を書けるからすごいんだ
103仕様書無しさん
2015/09/18(金) 07:18:35.22
>>102
確かにブロック化すればスコープも解決できるし
簡単といえば簡単だな、可読性も段違いで良くなるし
104仕様書無しさん
2015/09/18(金) 07:22:35.64
つか普段からやってるわ
関数化すると可読性が悪くなる(複雑化する)やつはブロック化
105仕様書無しさん
2015/09/18(金) 09:01:58.53
全然関係ないけど、90年代に比べて読みやすい関数の大きさが倍だと答えられてるらしい
単にディスプレイの大きさの問題だとか
106仕様書無しさん
2015/09/18(金) 10:37:14.73
経験しないとわからないものがあるw
昔のCコンパイラは関数の先頭で変数宣言しないとコンパイルエラー
使うかわからない変数が数十個並んでる
これには未初期化で使用されRelease版でのみ発生する不具合がつきまとう
再現性がたまに発生するものは極めて厄介
更にマッチスレッドがこれに絡むと地獄
またソースはこれまでの修正でコメントや#if0づくめ
数百行コメントアウトとかざらにある
ネストもむちゃくちゃで信用できない
統合環境なんてないから有効行の判断も解読しながらの作業
ほんと今の統合環境ありがたいw
107仕様書無しさん
2015/09/26(土) 06:40:15.97
OSの入ってるマシンで何かを動かそうとするからめんどくせぇんだよ
インベーダーマシンはインベーダー専用にしろよ
108仕様書無しさん
2015/12/09(水) 21:23:16.96
>>106
おまいは何歳だよ?w
結構、年齢の高い奴の発言に聞こえるぞ。
109仕様書無しさん
2015/12/09(水) 21:27:38.16
3ヶ月前
110仕様書無しさん
2015/12/09(水) 21:52:41.86
異変は
111仕様書無しさん
2015/12/09(水) 22:58:09.92
とある片田舎で
112仕様書無しさん
2015/12/09(水) 23:36:29.46
起きたかのように
113仕様書無しさん
2015/12/10(木) 00:31:33.21
少女が
114仕様書無しさん
2015/12/10(木) 00:48:12.52
(白人男性)「なんだ?あの雲は!?」
115仕様書無しさん
2015/12/13(日) 02:27:54.43
メニューボタン画面別に実装させんな
全部一緒でいいだろ!

いろんなことをなんどもなんども抗議したのに人を小馬鹿にして効く耳もたずに
まだできないのとか生産性悪くない?とかもっと働けとか
ふざけんなクソが
シロートの新入社員とか得体の知れないインド人やら朝鮮人もいるメンバーでどうせいちゅうねん

挙句に共通関数は自社の無能に任せて何度も仕様変更して全画面修正
getなんちゃらを呼び出すと副作用があったり画面側が頑張って仕様と違う動作を修正しなきゃいけなかったり
なんなのこいつら何で死なないの?
116仕様書無しさん
2015/12/13(日) 10:12:04.55
>>115
SIer系、かつ言語はMS系もしくはJava?
該当するなら、そういう仕事は避けるべし
117仕様書無しさん
2015/12/13(日) 10:15:22.43
> 共通関数は自社の無能に任せて
それ、"無能"に任せてるとかじゃなくて、"無能"が自社の"無能エース"を信頼してるって図式なんですが
118名無しさん@そうだ選挙に行こう
2015/12/14(月) 09:23:08.23
そりゃあ組織形態が汚いので
コードが汚いかは関係無いな。
119名無しさん@そうだ選挙に行こう
2015/12/14(月) 12:07:26.69
関係なくはないだろう?
組織形態の汚さが、コードの汚さにつながるのだから、
コードが汚いと、組織形態も汚いと考えるべき。
コードを見ればいろんなことがわかるんだよ。
120名無しさん@そうだ選挙に行こう
2015/12/14(月) 12:12:22.30
まず何が綺麗かを組織で決定してないとな。
「俺はこれが綺麗なんだもん」で書かれた記述は間違いなく汚い。
記述の綺麗さはまず統一性。
121名無しさん@そうだ選挙に行こう
2015/12/14(月) 12:19:35.19
> まず何が綺麗かを組織で決定してないとな。

それを組織で決めるのはダメ。

ソースコードの品質をはかるツールが有るのだから
まず最初にそれを使うことから始める。

そうしないと、変な書き方が社内標準とされてしまう。
122名無しさん@そうだ選挙に行こう
2015/12/14(月) 12:20:09.95
どう書いてもお前のコードが汚いコード
123名無しさん@そうだ選挙に行こう
2015/12/14(月) 12:40:51.47
>ソースコードの品質をはかるツールが有るのだから

なるほどね。
それで俺はネットをくぐった。複雑さがないと良い、という評価になるのだな

ニ三年前に見た評価ツールは、関数の大きさが100行もあるやつはだめで、
小さくなっているかを測るやつ。
124名無しさん@そうだ選挙に行こう
2015/12/14(月) 14:09:25.80
汚いコードってのは、クラス分けがテキトーで、
似た様な処理ってだけで集めて第1引数の値で細部が異なるスーパー関数で、
全部グローバル変数だから誰がどこからでも変更してOKで、
ポインターが三重くらいあるのがザラで…
125仕様書無しさん
2015/12/14(月) 22:54:16.45
綺麗さの基準が統一性ってのは賛成

統一性の前には
ほとんどの教科書やもてはやされるルールが霞む

クソも統一がとれていれば厳かなクソとなる
126仕様書無しさん
2015/12/14(月) 23:03:45.43
よし皆で一緒にクソしようぜ!
127仕様書無しさん
2015/12/14(月) 23:05:36.55
プログラミングの入門書に載ってるプログラムはなんであんなクソばかりなのかいつも疑問に感じてる。
128仕様書無しさん
2015/12/14(月) 23:59:47.68
>>127
カーニハン・リッチーもクソなの?
129仕様書無しさん
2015/12/15(火) 00:48:50.75
>>126
何の教科書なのか全然わからんが、
良い教科書のやり方に統一すればいいだけじゃん。
どの教科書もたいして変わらんだろうし。

なんで、統一 と 教科書 を別のものって考えてるの?
130仕様書無しさん
2015/12/15(火) 01:00:51.51
いや明らかに別だろ
131仕様書無しさん
2015/12/15(火) 01:03:36.30
では明らかに別であることを証明してください。
132仕様書無しさん
2015/12/15(火) 01:06:02.98
>>127
> プログラミングの入門書に載ってるプログラムはなんであんなクソばかりなのかいつも疑問に感じてる。
入門書だから

>>129
> カーニハン・リッチーもクソなの?
クソではなくて時代遅れ。
1978年出版でC言語が標準化されるよりも前のもの
133仕様書無しさん
2015/12/15(火) 01:08:39.85
>>131
そうゆう考えがより自分勝手に拍車をかけて結果的に別にするんだよ
134仕様書無しさん
2015/12/15(火) 01:43:37.16
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[生涯損害助長SI受注SEを追放すべき]
偽装請負従犯SEの動機
コミ障人格障害
コンピュータ趣味
文系大卒低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの損害
無償プログラム提供
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
事前面接
低予備工数残業見積
無料追加
労働違反
裁判苦手
学習不足
対人障害健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病
早死
135仕様書無しさん
2015/12/15(火) 02:05:54.08
133 返信:仕様書無しさん[sage] 投稿日:2015/12/15(火) 01:08:39.85
> >>131
> そうゆう考えがより自分勝手に拍車をかけて結果的に別にするんだよ

意味がわからん。 >>131に俺の考えなんて何も書いていない。

>>130
「明らかに別」と言ってるじゃないか?

それだけじゃ内容がないので、
>>130に対して>>130が自身が言ったことを
他人にも伝わるように正確に言えって言っただけだぞ。

そういう考えってなんだよ?
136仕様書無しさん
2015/12/15(火) 13:28:34.21
なんでも思い通りになると思わん方がいいんじゃね
137仕様書無しさん
2015/12/15(火) 15:31:50.56
自己主張乙
それが好き勝手に拍車をかけるっつーの
138仕様書無しさん
2015/12/18(金) 09:48:48.96
1行つか1文加えるだけで便利になるのに仕様に無いから削除しろって方が頭ん中疑うわ。
139仕様書無しさん
2015/12/18(金) 16:01:48.49
基本は外部仕様と一定の速度だけ満たせばいいって会社と、
内部仕様まで完全に綺麗に統一しなきゃだめって会社あるんだよね。

後者は害が多いと思う。
変なことにまで決まりが出来てくるのもそうなんだけど、
そもそも、結局内部実装をきちんと把握して管理できる人は事実上誰も居ないこと。
作者でさえ10日後にはコードを忘れてしまうのに。
140仕様書無しさん
2015/12/19(土) 12:18:28.17
上層部がそれを求めてるんだらしゃーない

粒度粒度粒度うっせーんだよ
141仕様書無しさん
2015/12/20(日) 02:11:03.71
求めてっつっても、その上層部含め誰もコードを把握してないじゃないか。
する必要すらないし。
142仕様書無しさん
2015/12/20(日) 14:20:33.69
中華が作った糞コードの保守は確かに10倍以上辛いわ
143仕様書無しさん
2015/12/20(日) 17:49:10.94
>>142
最終的に高くつくんだよな
保守も奴らにやらせりゃいいんだ、格安で
144仕様書無しさん
2015/12/20(日) 18:12:13.41
俺がプログラム作ると
いっつも名前がぐしゃぐしゃになるんだが

誰かどうすればいいか教えてくれ
145仕様書無しさん
2015/12/20(日) 18:19:24.95
英語を勉強しる
146仕様書無しさん
2015/12/20(日) 23:05:40.97
>>144
動詞、目的語の順に書いて、Listのときには_listとつける。
日本語を使いまくる。俺はこれで保守しやすいプログラムを
量産してる。

List<Customer> 取引先_list = get_取引先_list();

for (Customer 取引先 : 取引先_list) {

}
147仕様書無しさん
2015/12/21(月) 09:40:28.90
日本語変数や関数って、文字コード問題あるから要注意な。
148仕様書無しさん
2015/12/26(土) 08:59:52.56
>>146
listより複数形sをつける方が直感的だと思う
俺も昔はlistをつけてたけど、sの方が直感的だと思うようになった
149仕様書無しさん
2015/12/26(土) 09:06:29.63
日本語プログラムってエディタで書いて実行するだけなら、問題は起きないよね
周辺ツール(チェックツールとか)が対応していなかったりするから、日本語はやっぱり避けてる
150仕様書無しさん
2015/12/26(土) 10:30:49.19
>>148
sは配列のときに使う。
リストのときは_listがいい。
配列とリストを相互に変換するときわけがわからなくなる。
_listだ。_listにしとけ。_listはすばらしい。
151仕様書無しさん
2015/12/26(土) 10:46:12.59
構造体は?
152仕様書無しさん
2015/12/26(土) 11:44:46.31
>>148
sで終わらない複数形はどうするの?
153仕様書無しさん
2015/12/26(土) 12:03:47.30
>>150
言いたい事は分かるんだが、
enumarableなモノを使わずに、レガシーなlistや配列を多用してるから
そういうワケの分からない自体に陥る
enumarableを使え
listや配列とか古臭い概念からオサラバですわ
154仕様書無しさん
2015/12/26(土) 12:04:38.90
しまった
enumerableなモノですね
155仕様書無しさん
2015/12/26(土) 12:08:03.18
>>153
フレームワークで配列しか受け付けないのもあるし、
Listを使うのは追加の処理があってインデックスでアクセスしたいからだよ。
古いとか新しいとか関係ない。ケースバイケースだ。
156仕様書無しさん
2015/12/26(土) 12:08:51.72
>>152
そういう英単語は、プログラミングではまず登場しないから、心配無用
万が一の場合は間違っていても無理矢理sをつけるとかして、ごまかせばいい
そもそも、そういう英単語を選んだらダメなんだけどな
personとかdataとかinformationとか・・・
157仕様書無しさん
2015/12/26(土) 12:09:56.16
dataはまあ別にいいかもな(個人的には好きじゃないけど)
datum -> dataで済むし
158仕様書無しさん
2015/12/26(土) 12:10:58.91
>>157
data_list
これでおk
159仕様書無しさん
2015/12/26(土) 12:11:48.87
datumってなんか秋みたいじゃない?せつなくならない?
_listってつけたらほっこりするよ。
160仕様書無しさん
2015/12/26(土) 12:14:03.81
今は使ってる人が随分と減った気がするけど
オブジェクトは接頭辞で明確化するのが今でも最強だと思ってる。
データベースならマスタがm_***、テーブルはt_***、ビューはv_***。
クラスならC***、変数ならi***、l***、n***、dw***、s***みたいに。

これなら変数の目的が一文字目を見るだけで一目瞭然。
先頭小文字もクリアだし、***の部分は名詞に限定すればいい。
型という概念が曖昧なPHPなんかはこういう書き方してると特に助かる。
161仕様書無しさん
2015/12/26(土) 12:15:52.52
>>155
大体分かりましたわ
アナタがたぶん正しいわ
俺も必要に迫られたらlistとsを使い分けると思う
162仕様書無しさん
2015/12/26(土) 12:17:48.33
>>160
ハンガリアン記法の一言で
163仕様書無しさん
2015/12/26(土) 12:21:25.69
つまり連続物かどうかがわかれば良い話で
listとsをわざわざ分けて名前を付ける必要があるのかと
164仕様書無しさん
2015/12/26(土) 12:21:51.86
>>160
懐かしいな。
昔はそれがスタンダードな命名の1つだったよな。
俺は10年くらい前に卒業したけど。
165仕様書無しさん
2015/12/26(土) 12:23:42.37
>>164
使うなという現場なら使わないけど、それ以外は使ってる
卒業するようなものじゃない
166仕様書無しさん
2015/12/26(土) 12:24:04.39
>>163

>>161を書いたけど、必要に迫られるケースがあるんだよ
ListとArrayで大幅にメソッドが違う言語では特に
ListとArrayがほぼ同じ扱いな言語とは話が違ってきたり
167仕様書無しさん
2015/12/26(土) 12:25:31.12
>>165
いや、別にそれが好きなら使えばいいじゃんね
俺は、もう使わない
ただそれだけ
168仕様書無しさん
2015/12/26(土) 12:29:07.99
>>160はハンガリアンじゃなくて
何なる命名規則な。

○○Formとか○○Viewとかいう名前にするのも、
f_ とか v_ という名前にするのもほとんど変わらない。

省略されたらわかりづらい程度の話
169仕様書無しさん
2015/12/26(土) 12:31:18.51
> 変数ならi***、l***、n***、dw***、s***みたいに。
こっちはハンガリアンだな。

あー、正確に言うと、本来意味のハンガリアンを
MSが間違って解釈した間違いハンガリアンだな。

これはMSが間違いだったと認めたもので、
つまり誰も推奨していない。やってはいけないもの。
170仕様書無しさん
2015/12/26(土) 12:32:30.22
ハンガリアン表記は批判的に言われることが多いけど、
実践的な技術だと思うんだよなあ
171仕様書無しさん
2015/12/26(土) 12:43:42.77
>>166
宣言部を見れば良い
今時ならカーソルを合わせれば型が見れるし
インテリセンスもあるでしょ
172仕様書無しさん
2015/12/26(土) 12:47:08.03
宣言部を見なければいけない。
カーソルを合わせなければいけない。
インテリセンスを使わなければいけない。
これらは、リーディングのときの負担だと思うぞ。
173仕様書無しさん
2015/12/26(土) 12:48:59.81
>>170
MSが間違って解釈したハンガリアンはだめだよ。
変数名にデータ型を表す接頭語をつけるのはね。

データ型ではなくて、データの種類。例えば、フォームとかボタンとか
コントローラとかビューとかそういう種類の略字を接頭語にするやつは問題ない。

例えば、Startという名前はわかりづらいが、StartButtonやStartMenuだと
わかりやすいだろ?これと同じ。

実際にはButtonは、ボタンクラスを継承したものかもしれないし、
リンクをボタンにように見せているだけかもしれない。
でも種類としてはボタンなのでボタンでいい。

この時、接尾語にButtonとつけるか、接尾語にBtnとつけるか
接尾語ではなく接頭語にしてbtnとつけるか。それは名前の付け方の好みでしか無い。
StartButton も StartBtn も btnStart もこうしてみれば大した差はないのがわかるでしょ?


比較的最近のウェブフレームワークであるAngularは接尾語にCtrlとかControllerを
つけるというコーディング規約。
https://github.com/mgechev/angularjs-style-guide/blob/master/README-ja-jp.md
174仕様書無しさん
2015/12/26(土) 12:49:18.32
>>172
その最初の一瞬だけ見れば済む確認手順を省略するために
名前に長々としたものを書き加える無駄さ
175仕様書無しさん
2015/12/26(土) 12:49:49.47
>>171
> 今時ならカーソルを合わせれば型が見れるし

動的言語なので、カーソル合わせただけじゃわかりませんー。
176仕様書無しさん
2015/12/26(土) 12:51:15.91
>>174
可読性ってそういうものだよ。

書くのが面倒でも、読みやすさの方を優先するべき。
どうせ補完機能で、書く面倒さは軽減されるんだから。
177仕様書無しさん
2015/12/26(土) 12:54:40.25
>例えば、Startという名前はわかりづらいが、StartButtonやStartMenuだと
>わかりやすいだろ?これと同じ。

接頭辞の話と違うくね?
StartButtonだけじゃbooleanなのか整数なのか文字列なのかクラスなのかが一目でわからんて話でしょ
178仕様書無しさん
2015/12/26(土) 12:55:27.36
>>176
可読性が悪いってことなんだが
179仕様書無しさん
2015/12/26(土) 12:57:53.41
>>178
省略すると基本的に可読性は悪くなるんだぞ?

必要となる情報が、すぐ近くに揃っていることが重要。
あちらこちらを見ないとわからないものは可読性が低い
180仕様書無しさん
2015/12/26(土) 13:00:36.15
>>175
いきなり動的で書き始めるバカはいないだろ
181仕様書無しさん
2015/12/26(土) 13:02:15.73
>>177
> StartButtonだけじゃbooleanなのか整数なのか文字列なのかクラスなのかが一目でわからんて話でしょ

だから、それをわかるように、頭にデータ型をつけたのが
MSが正しいハンガリアンを間違って解釈した「間違いハンガリアン」で
これをMSが間違いだと認めた時点で、推奨する人はだれもいなくなった。

で、正しいハンガリアンとは、StartButtonの代わりに、
頭に省略した名前の接頭語をつけて、btnStart としましょうというもので
本質的には、btnStart も StartButton も変わらない。

btnStart だと、タイプ数が減る代わりに覚えることが増える。
今の主流が省略した名前をつけるのではなく、その場に明確に
書きましょうって流れなだけ。
182仕様書無しさん
2015/12/26(土) 13:06:27.46
>>179
だったらintAbc、doubleDefなら一目瞭然だろ、と言ってるのと同じ
というかlistだのsだの付けるよりこの方がもっと正確に一発でわかるわな
183仕様書無しさん
2015/12/26(土) 13:12:42.11
>>181
それはC#のように全てをクラスとして考えてる言語の場合だろ
C言語だったらdoubleを使わずに浮動小数点クラスを使えって話
184仕様書無しさん
2015/12/26(土) 13:13:00.20
>>182
それが一目瞭然に見えるのは、

AbcとかDefという名前が悪いだけ。
正しい名前をつけましょう。count とか lengh とか。

ボタンに対してstartとつけても、これは正しい名前とは思えない。
startという動詞だし意味が違ってしまう。

英文で説明することを考えよう。これはボタンなのだから
button(に相当する)という単語が含まれていなければならない。

intAbcもstart も同じことを言ってる、意味がわかるように
"正しい名前をつけましょう" だ。

だから、正しい名前として、StartButtonとつけるのが今は主流だが
それを btnStart とつけるのは、名前の付け方の好みの違いなだけ。
185仕様書無しさん
2015/12/26(土) 13:13:43.52
>>182
データ型を変換するところではそれやる。
double型のAなのか、int型のAなのか示したいってとき。
オーバーフローを気にしたいときはint32_valueとかね。
186仕様書無しさん
2015/12/26(土) 13:16:36.71
MSが間違って解釈した「間違いハンガリアン」は
データ型を含めるもの。

変数にはデータ型は含める必要はないが、
"正しい名前"をつけることは重要。

データ型は名前の一部ではないが、Buttonというのは
名前の一部であるから、正しい名前をつける一貫として
Buttonという単語を含めるのは至極当然の話である。
187仕様書無しさん
2015/12/26(土) 13:18:31.92
>>186
だからそれは全てがクラスだからだろ
188仕様書無しさん
2015/12/26(土) 13:19:33.86
一応補足しておく。

本来の意味の正しいハンガリアンは「アプリケーションハンガリアン」
MSが間違って解釈したやつは「システムハンガリアン」

この2つの言い方は紛らわしいので、ハンガリアンの名誉回復と
頭に接頭語をつけることが全て間違いだと勘違いしている人のために
俺はあえて「間違いハンガリアン」と言わせてもらうけどなw
189仕様書無しさん
2015/12/26(土) 13:21:32.56
>>184
valueとか型も正しい名前も糞もあったもんじゃねえ名前のオブジェクトもあるわな
190仕様書無しさん
2015/12/26(土) 13:21:39.02
>>187
> だからそれは全てがクラスだからだろ
関係ねーよ。

たとえクラスがなかったとしても、ボタン(データかポインタか知らんが)に
ボタンという名前を含めるのは何も間違ったことではない。
191仕様書無しさん
2015/12/26(土) 13:22:44.95
>>190
>>177
192仕様書無しさん
2015/12/26(土) 13:23:18.64
>>189
それ以外に正確に意味を表せる言葉がないんだろ?
ならvalueでいいだろ。

俺が言ってるのは、ボタンに対してbuttonという単語を
含めることの何が悪いんだ?って話。

逆に入れたほうがいいだろ。
193仕様書無しさん
2015/12/26(土) 13:23:49.40
>>191
話を戻すな。>>181でレスしてる。
レスするなら、続きを書け
194仕様書無しさん
2015/12/26(土) 13:30:28.85
>>192
話が通じねえ、深海と火星の話を思い出した
195仕様書無しさん
2015/12/26(土) 13:34:11.65
トルネコ「
  まあまあ きみたち。そんなに こうふんしないでください。

お前らはいきり立った。
196仕様書無しさん
2015/12/26(土) 13:54:56.52
システムハンガリアンのデメリットは、システムハンガリアンがアプリケーションハンガリアンじゃないってことだろ。
つまり、両方使ったら最強。
button_button_agree ←OKボタン
boolean_agree ←OKボタンを押したか
197仕様書無しさん
2015/12/26(土) 13:58:02.82
ボットンボットンって便所みたいだな
198仕様書無しさん
2015/12/26(土) 13:59:27.32
日本以外でなんとかハンガリアン使ったら大笑いモノ
199仕様書無しさん
2015/12/26(土) 14:03:17.71
海外のソース見るとMSハンガリアンとやらを使ってる奴多いわ
200仕様書無しさん
2015/12/26(土) 23:13:41.63
釣りだろうけど、
Buttonを含めるのが当然とは思えないなあ。

ボタンの絵が描いてあって、Startと表示してあったら
それはスタートボタンのことを意味してるのだよ。

じゃ、スーパーのドアなどに「引」と書いてあるけど、
あれは「ドアを引く」と書いてないと意味が通じないのか?
ドアに「引」と書いてあったら、ドアを引くにきまってるじゃん?
201仕様書無しさん
2015/12/27(日) 04:43:27.61
> ボタンの絵が描いてあって、Startと表示してあったら
> それはスタートボタンのことを意味してるのだよ。

ソースコードにボタンの絵が書いてあるのか?
202仕様書無しさん
2015/12/27(日) 05:36:50.25
ソースコードにテキストしか使えないのにvisual studioとか言いはる詐欺製品w
203仕様書無しさん
2015/12/27(日) 07:01:30.79
なんか屁理屈言い出したからどうでもいいや
204仕様書無しさん
2015/12/27(日) 08:03:22.69
変数は、型と名称でワンセットなんだから名称だけじゃソース的には情報不足
型名の代わりに長ったらしい名前を付ける奴もいるみたいだけど
そんな回りくどく非直感的な変数名など、読む方はたまったもんじゃない

日常会話でも略称で話すことは多々あるし、ましてやプログラミングは
文章ではなくコードを書くんだから、コードのメリットを最大限に活かして
見たら考えるまでもなく、直感的に読めるソースを書かないと

MSがなんと言ったのかは知らないけどMSハンガリアンとやらは
シンプルながら可読性を一気に押し上げる良いルールだと思うよ
205仕様書無しさん
2015/12/27(日) 08:09:44.37
>>199
MSも2003年(もっと前?)からシステムハンガリアンは禁止みたいなことを言い出したが
ドライバー開発のサンプルプログラムから消えたのはWindows8のWDKサンプルからだし
MSが推奨しないので頭にデータ型を書くのは辞めようと決めてもCやC++の開発者の中には、
StartButton_bとしたり、アンダーバーが禁止されるとStartButtonbとかStartButtonBとかで
とにかく変数にデータ型を入れないことに抵抗する輩は必ずいたそうだ。
しかし今残っているのは既存コードの変数名を替える様なこともしていないだけでは?
206仕様書無しさん
2015/12/27(日) 08:24:00.30
> ドライバー開発のサンプルプログラムから消えたのはWindows8のWDKサンプルからだし

そりゃ互換性を保たないといけないから仕方ない
207仕様書無しさん
2015/12/27(日) 08:32:30.65
型が変わったから変数名を変えるというのをデメリットと言う奴もいるけど
型を変えるってのはそもそもリスクのある行為だから使用箇所を確実に確認できるメリットもある

>>205
そうでもない
大体コロコロ変わるMSの方針転換にいちいち付き合ってられんて奴が多い
特にJavaの影響を受けたんだろう、VSも色々な対抗策を模索してきてる傾向が見える

もちろんハンガリアンに馴染みのない世代がダセェと思うのは当然
俺だって仕事用だったり、公開目的なら言語に合わせて書き方は変えてるけど
便利なものは便利なんだよね
208仕様書無しさん
2015/12/27(日) 09:09:07.33
>>181
> これをMSが間違いだと認めた時点で、推奨する人はだれもいなくなった。

こういう嘘を恥ずかしげもなく言う馬鹿いるんだw
MSは別に間違いだとはまったく認めてないぞ
.Net開発では使わないでくれと言っているだけ
一方で賛否両論があることを認めている
209仕様書無しさん
2015/12/27(日) 09:45:26.60
ハンガリアン記法に拘る人って時代の変化についていけない人たちだよね~
どっちがいいとか悪いとかの以前の問題で、なんか気持ち悪い~
210仕様書無しさん
2015/12/27(日) 09:47:01.21
あとWindowsプログラミングしかやったことない人たちだよな~
視野が狭すぎて傍からみてると可哀想ぅ~
211仕様書無しさん
2015/12/27(日) 09:52:24.43
>>209 >>210
頭の弱い人も可哀想ぅ~w
212仕様書無しさん
2015/12/27(日) 10:20:01.96
1.変数の頭に型を示す文字を入れる
 bStartButton


2.変数に型を入れる
 boolStartButton

3.型を入れない
 StartButton


4.変数の後ろに型を示す文字を入れる?
 StartButton_b
 

基本は3だが1、4も捨てがたい
2はなんか嫌かも
213仕様書無しさん
2015/12/27(日) 10:50:40.82
変数名大文字始まりとか嫌だわ
214仕様書無しさん
2015/12/27(日) 11:18:30.38
booleanのstartButtonって用途が全く分からん変数だな
そこからして全然ダメじゃん
215仕様書無しさん
2015/12/27(日) 12:51:12.08
そのインスタンスを使う関数の内容次第だろ。
5,6行の関数ならインスタンス名は b とかで十分な時もあるだろうし、
他のボタンも引数で必要なら start_b とかする必要があるだろうし。
216仕様書無しさん
2015/12/27(日) 13:46:25.57
>>212
3の1択
型変わるときに変数名に型あるとミスリードする可能性がある
昔short使っていてそれをintに変えるからと修正したらとんでもない無駄な工数が発生する
型推論も随分広まってきたから型の判断は統合環境に任せればいい
217仕様書無しさん
2015/12/27(日) 16:42:12.52
shortからintでどんな名称変更したんだよ
というか型を変えるのに影響箇所いっさい確認しないのか?
218仕様書無しさん
2015/12/27(日) 16:45:15.36
データ型を変更するくらいなら、変数を新しく作って使った方がいい。
219仕様書無しさん
2015/12/27(日) 16:55:24.26
いまはIDEのリファクタリング機能で変数の名前変更はサクッと行けちゃうよ
220仕様書無しさん
2015/12/27(日) 16:57:49.88
>>209
プログラミングってのは書けば書くほど、どんな記法が最良かってのが自然と見えてくる
限られた時間で沢山書いて沢山読むのに、誰だって面倒なのは嫌だからね
他人が作ったルールを馬鹿正直に全て受け入れてるプログラマはまずいないし
A型の融通利かないバカとド素人以外は

メリットがあるからこそ使い続ける人がいる、それだけの話
221仕様書無しさん
2015/12/27(日) 17:00:56.87
>>218
確かにそうだな
とするとハンガリアンのデメリットは無いね >>212は1の1択
222仕様書無しさん
2015/12/27(日) 17:02:51.33
>>217
影響箇所はもちろん確認するが型だけ変えるのと変数も変えるのとでは大きく違う
型なら全置換で終わる場合もあるが変数名となるとマンパワーが欠かせない
また人がやるからヒューマンエラーが入り込んでくる
規模が大きいと些細なことでも山となる
そもそも型程度が可読性に影響するならそれは糞でかメソッドだと思うがな
223仕様書無しさん
2015/12/27(日) 17:10:52.53
>>214
StartButtonを例えに出すのがそもそも悪い
こんなのボタンコントロールのインスタンス以外の何物でもないわ

たとえばメートル管理、小数点管理ならfMeter
メートル単位の整数管理ならiMeter、nMeter
構造体ならsMeter、クラスインスタンスならcMeter
224仕様書無しさん
2015/12/27(日) 17:16:57.65
>>222
影響箇所の確認について矛盾したこと思いっきり書いてるぜ
225仕様書無しさん
2015/12/27(日) 17:26:04.92
>>222
オブジェクト指向言語で、同じ変数名の変数の型を自動的に置換なんて絶対ありえない。
226仕様書無しさん
2015/12/27(日) 17:36:37.94
>>224
修正は自動でテストは修正箇所全部だ
テストコードあれば工数は極めて小さくできる
>>225
オブジェクト指向なら尚更だが…
抽象化を柱としているのに型に依存するのは本末転倒
符号付きだろうが符号なしだろうが32bitだろうが64bitだろうが関係ない
数値をどう処理するかにだけ依存するべき
型推論使えばあまり型なんて気にせずにすむぞ
インターフェイスが変わっても修正無しで行けることもある
227仕様書無しさん
2015/12/27(日) 17:45:49.04
今度はマンパワーと自動修正の矛盾
228仕様書無しさん
2015/12/27(日) 17:51:31.77
具体性のあるコードがあって初めて抽象化ってのができるもんだろ
ゆとりか?
229仕様書無しさん
2015/12/27(日) 17:59:42.00
>>210
NDKなどLinux系でも使ってるよ
230仕様書無しさん
2016/02/11(木) 16:05:57.82
age
231仕様書無しさん
2016/02/17(水) 02:42:20.92
いきなり途絶えてたな。全部自演か。
232仕様書無しさん
2016/02/17(水) 21:17:35.64
俺は二重人格じゃないよ
233仕様書無しさん
2016/02/18(木) 00:11:06.79
また俺か…忍びねえな…
234仕様書無しさん
2016/02/18(木) 01:38:44.87
この板なんか臭い
235仕様書無しさん
2016/02/18(木) 21:31:26.21
同じコードなのに、人によって、書き方(スタイル)が違うのって嫌だよなぁ

common_method1(a, b, c)

x = a, y = b, z = c
common_method1(
x,
y,
z
)

こういうのも汚いよね
grepしにくいし、2,3ならまだしも何十もあると、理解するだけで大変
236仕様書無しさん
2016/02/18(木) 21:31:58.06
例はあんまり突っ込まないで
適当に書いただけ、とくに意味はない
237仕様書無しさん
2016/02/18(木) 21:44:51.47
わかるよ
1行の文字数は、もちろん長すぎるのも読みにくいけど
一番読みにくいのが1行1文字みたいな使い方。
見易さに気を使ってるのかもしれないけど
見たいのは一つ一つの命令じゃなくて前後を含めた広範囲のロジックだから
スクロールせず1画面でできるだけ多くの情報を見たいわけで

だからってコメントも空行もなしじゃ境がわかりにくいので
何事も程々にだな
238仕様書無しさん
2016/02/18(木) 22:03:00.74
横80文字を超えなければいいんでしょ超えなければ。っていう考えで
method(aaaaaaaaaa, bbbbbbbbbb, cccccccccc, dddddddddd, eeeeeeeeee, ffffffffff, gggggggggg, hhhhhhhhhh)

というのを安易にこうするのも良くない

method(aaaaaaaaaa, bbbbbbbbbb, cccccccccc, dddddddddd, \
    eeeeeeeeee, ffffffffff, gggggggggg, hhhhhhhhhh)

変数名が長いのは、関数が長すぎるせいだし、引数が多いのは
意味がある塊ごとに構造体やオブジェクトにした方がいい。

長い文字列、例えばメッセージやURLがない限り、無理やり
改行させなくても横80~100文字に収められる。
239仕様書無しさん
2016/02/18(木) 22:13:16.85
80文字ってMSDOS時代じゃないんだから

なんでも構造体にすりゃいいってもんでもなくて
引数はI/Oを厳密に指定できるメリットがある
不要な引数はデフォルト化したりね
240仕様書無しさん
2016/02/18(木) 22:25:25.81
>>239
文字数はMSDOS時代とは関係ない。視野の話。

お前だってその文章、たった半角40文字程度で改行入れてるだろ?
241仕様書無しさん
2016/02/18(木) 22:31:21.97
だってスマホなんだもの
242仕様書無しさん
2016/02/18(木) 22:34:10.92
> 80文字ってMSDOS時代じゃないんだから

今はスマホ時代ですよ
243仕様書無しさん
2016/02/18(木) 22:55:09.92
スマホでプログラミングはしないだろ
244仕様書無しさん
2016/02/18(木) 23:21:41.78
>>235の意味は

横にするのか、縦にするのかどっちでもいい
同じ内容の記述なら同じスタイルじゃないとメンテしにくい

です
245仕様書無しさん
2016/02/18(木) 23:29:25.41
80は今の時代にすこし狭く感じる
commit msgとかは80 (76)でいいけど
今は100とかの方がよいと個人的に思う
246仕様書無しさん
2016/02/18(木) 23:32:48.29
>>244
> 同じ内容の記述なら同じスタイルじゃないとメンテしにくい

同じスタイルにする意味はない。

長いときと短いときで、適切な書き方をするべきである。
247仕様書無しさん
2016/02/19(金) 07:04:15.83
>>246
"同じ内容の記述"なんだから、長いとき短いときはないのです
はい
248仕様書無しさん
2016/02/19(金) 09:15:44.40
>>247
意味がわからないなら無理やり参加しなくていいんだよ
249仕様書無しさん
2016/02/19(金) 13:20:15.91
吉野健太郎の卑怯なTwitterで検索しよう
250仕様書無しさん
2016/02/19(金) 18:28:14.22
フォーマッター使えばいいやん
メジャーな言語なら大体定義ファイルも特定の箇所だけ除外する仕組みも用意されてるでしょ
251仕様書無しさん
2016/02/19(金) 18:35:04.78
フォーマッターは見にくいものを直してくれるのと
誤字脱字を発見するためで、見やすくするためのものじゃないよ
252仕様書無しさん
2016/02/19(金) 21:05:18.75
>>250
なるほど、フォーマッターでスタイルは完全に揃うね
でも、IDE/Vim/Sublimeとか色々あって、1つのformatterを強制できないわ
どしたらいい?
253仕様書無しさん
2016/02/19(金) 21:09:08.73
「スタイルが統一されていれば見やすい」は間違いだからな。
254仕様書無しさん
2016/02/19(金) 21:27:53.44
統一されてると、格段に理解しやすいし、修正しやすいよ
255仕様書無しさん
2016/02/19(金) 21:37:54.83
>>253
スタイルがバラバラなのよりマシ
256仕様書無しさん
2016/02/20(土) 07:05:41.63
バラバラって、たかが2種類だろ大袈裟な
257仕様書無しさん
2016/02/20(土) 07:15:47.41
可読性が高いならスタイルの違いなんて些細な問題
258仕様書無しさん
2016/02/20(土) 09:33:26.59
>>256
そもそもスタイルが存在してない場合もある。
259仕様書無しさん
2016/02/20(土) 09:56:45.61
初心者はそうだろうな
プログラミングに長けてる奴は適材適所で2、3種類くらいじゃん?
260仕様書無しさん
2016/02/20(土) 13:55:08.84
【主な偽装請負従犯要員SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てツール]
ノンプログラミングツール
フレームワーク
COBOL
VB
.net
Java
Web
DB
ERP
SAP
261仕様書無しさん
2016/02/20(土) 14:10:36.69
>>256
2種類じゃなくて、7,8種類もあったらどう?
262仕様書無しさん
2016/02/20(土) 14:11:34.06
>>235は何十って言ってるじゃん
そこを"2つ"と言い切るのは、変ですな
263仕様書無しさん
2016/02/20(土) 22:18:15.01
>>261
慣れてない奴は間違いなく無限にあるが
7、8種類しかなくて使い分けてるならいいんでない?
264仕様書無しさん
2016/02/20(土) 22:20:01.55
>>262
まずは何十を挙げてから出直せ、話はそれからだ
265仕様書無しさん
2016/02/21(日) 09:42:25.56
使い捨て早死に貧困の助長SEは大迷惑
相場下がって迷惑だから偽装請負の従犯は辞めろ!

・1,000万円/年以下低レベルの会社は辞めろ
・80万円/月以下低レベルの契約は辞めろ
・5,000円/時間以下低レベルの契約は辞めろ
・多重契約は辞めろ
・不利益な現場は辞めろ
・残業見積りは辞めろ
・時間外労働違反は辞めろ
・契約外納期は守るな
・客先指示に従うな
・知的財産を渡するな
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/
266仕様書無しさん
2016/02/24(水) 17:41:07.65
・main()にすべてが詰まってる
・コメントでバージョン管理されている
そんな汚物コードをメンテするんだが
そういうときの精神衛生保全のために皆どんな工夫してる?
267仕様書無しさん
2016/02/24(水) 18:02:33.66
>>266
1ヶ月くらいならクソコードがどんな悲惨な状況を生み出すか体験するために我慢するけど、長期間になるなら転職する。
そんなコードを生み出す組織は、コードだけではなくソフトウェア開発に関するすべてにおいてレベルが低いに違いないので、
そんな組織で働くことは成長の機会を放棄するのと同じです。
268仕様書無しさん
2016/02/24(水) 18:08:10.16
吉野健太郎は危険ドラッグ薬事法違反で有罪判決 [転載禁止]・2ch.net
http://potato.2ch.net/test/read.cgi/21oversea/1445778429/
269仕様書無しさん
2016/02/24(水) 19:49:27.98
>>266
他の会社行こう
270仕様書無しさん
2016/02/24(水) 19:56:01.86
>>コメントでバージョン管理されている
バージョン管理はファイル名だろ。やり直し
271仕様書無しさん
2016/02/24(水) 21:36:28.64
>>266
マジレス

・ローカルPCでGitを使って開発する (これ絶対)
・コード整形verと汚物verの両方を、うまく使い分ける
(閲覧・開発は前者、成果物は汚物verへ移植)
272仕様書無しさん
2016/02/24(水) 21:38:37.45
>>266
移植作業には、WinならWinMergeがよいと思う
編集しながらコード差分、比較可能だから
(そんな知ってるわ!wだったらスマソ)
273仕様書無しさん
2016/02/24(水) 21:42:02.57
>>266
修正コメント("YYYY/MM/DD 山田太郎 追加"みたいなの)は、
自作ツールとかで、さくっと行単位で追加、編集、削除できるようにする
エディタのマクロでもいいし、AutoHotkeyとかのキーバインドツールでもおk
(そんな既にやってるよ!だったらスマソ)
274仕様書無しさん
2016/02/24(水) 21:42:55.43
色々書いたけど、最終的には転職した方がいいよ
全く希望がないです。そういう企業は
275仕様書無しさん
2016/02/24(水) 21:49:07.24
>>273
可読性とは言うが、可書性とは言わない。

なぜなら書くのは一回ですむが、
読むのは何度でもするからだ。

読みにくなる原因の一つである修正コメントを
簡単に増やせるようにしてはいけない。
それは簡単に読みにくくするための道具だ。
276仕様書無しさん
2016/02/24(水) 22:27:32.57
何をしてるのかをコメントに残して欲しいのに
そういうのは一切書かないで、変数の日本語名を
使用箇所全てにコメントとして書く意味不明さ。

LcBookMargReq = True;  // 予約要求フラグ
    :
LcBookMargReq = False;  // 予約要求フラグ

変数名自体もわかりにくいし、どの変数も似た名前だし。
これならC#みたいに変数名に日本語使われた方がまだマシ。
277仕様書無しさん
2016/02/24(水) 22:42:16.43
>>276
そういう名前の変数が出来る本当の原因は
関数が異常に長いから
278仕様書無しさん
2016/02/24(水) 22:45:50.13
>>277
DB設計
279仕様書無しさん
2016/02/24(水) 23:10:21.23
今は変数の話をしてる
280仕様書無しさん
2016/02/25(木) 00:16:50.00
ここで変数の話は終わった
281仕様書無しさん
2016/02/25(木) 00:39:06.68
>>275

>>273だけ見て脊髄反射やめて
>>266もミテネ!
282仕様書無しさん
2016/02/25(木) 00:52:48.78
>>276
少し分かる

日本語として意味不明なコメントはダメだわな

例えば、

// 遷移状態完了済フラグ

みたいな奴
283仕様書無しさん
2016/02/25(木) 11:17:24.47
先日コードが汚ないと注意されたプログラマーが拗ねて退職したw
284仕様書無しさん
2016/02/25(木) 19:05:27.03
何が汚いかより何が綺麗かでコードを語れよ
285仕様書無しさん
2016/02/25(木) 20:28:36.79
時給換算5,000円以下のSEの皆様へ

相場が下がって迷惑ですので、SE辞めてもらえませんか?
主婦SE以下の時給換算レベルですよ。
学習期間や契約終了の不利益リスクにどう対処するおつもりですか?
こちらこそ優秀なSEの離職で大損害なんですから。

発注者より
286仕様書無しさん
2016/02/25(木) 21:46:20.57
>>284
元ネタは「何が嫌いかより 何が好きかで自分を語れよ」だが、
それとは全然意味が違ってる。

嫌いなもの言った所で好きなものはわからない。
例:ゴーヤーチャンプルーが嫌い・・・好きなものは? ⇒ 不明
だから好きなものを言えと言っているのだが、

コードの処理が冗長で汚い ⇒ シンプルなのが綺麗
クラスの依存関係がおかしくて汚い ⇒ 正しい依存関係が綺麗

のように汚いコードを言えば、その反対の綺麗なコードがどういうものかわかる。
287仕様書無しさん
2016/02/25(木) 22:55:32.98
>>286
オブジェクト指向で書かれてて汚い
288仕様書無しさん
2016/02/25(木) 23:26:21.52
>>287
どういうコードが?
289仕様書無しさん
2016/02/25(木) 23:36:30.76
>>286
ヒント:それはお前の主観にすぎん
290仕様書無しさん
2016/02/25(木) 23:38:25.59
>>289
ツール使って解析しているので主観ではない。
291仕様書無しさん
2016/02/25(木) 23:46:02.92
>>290
客観的な指標があるのならわざわざ反例をあげて回りくどいやり方をする必要はないな。
お前の思う良いコードを例にだせば良いよ、誰も文句は言えんだろ。
292仕様書無しさん
2016/02/25(木) 23:49:16.27
>>291
仕事で書いたコードなのだから書いたコードは誰でも見れるので例に出すまでもない。
ただし良いコードを見ただけで同じように書けるわけじゃないので
日々コードレビューを行って問題点の指摘とどうすればいいかを教えている。
293仕様書無しさん
2016/02/25(木) 23:50:15.73
ツールで計測できる客観的な指標というのは、だめであると言う理由だけ
どうすればいいかまでは教えてくれない。もしどうすればいいのかまで
教えるツールが存在するならば、ツールが勝手に修正できるはずだろう。
294仕様書無しさん
2016/02/25(木) 23:54:30.52
>>292
お前はアホか?俺にはお前のコードか見えんぞ。
それともアホの俺には見えんコードを書いてるのかお前は?
295仕様書無しさん
2016/02/25(木) 23:57:25.78
>>294
会社のコードなんだから、社外の人間のお前にはみれん。
当たり前だろw
296仕様書無しさん
2016/02/25(木) 23:59:34.44
>>295
お前自分が支離滅裂な事言ってるって分かってる?
297仕様書無しさん
2016/02/26(金) 00:02:29.89
>>296
どこが?
文章に下線引くなどして、具体的に指摘してみて。
298仕様書無しさん
2016/02/26(金) 00:04:27.86
>>297
素直に分かってないって言えんのかお前は
299仕様書無しさん
2016/02/26(金) 00:04:46.74
指摘して見せてって言った後のレスがこれかw
300仕様書無しさん
2016/02/26(金) 06:39:49.50
コードの前に心を綺麗にしなくちゃいけませんね
301仕様書無しさん
2016/02/26(金) 11:11:45.36
そうですね
302仕様書無しさん
2016/02/26(金) 13:35:50.03
その前に風呂はいれよ
303仕様書無しさん
2016/03/02(水) 21:42:56.28
時給換算5,000円以下のSEの皆様へ

相場が下がって迷惑ですので、SE辞めてもらえませんか?
主婦SE以下の時給換算レベルですよ。
学習や設備や裁判や営業や管理や離職等の費用も含まれてるのですよ。
こちらこそ優秀なSEの離職で大損害なんですから。

発注者より
304仕様書無しさん
2016/03/04(金) 08:12:32.69
犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)

告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)

審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす

受理 → 告訴事実を認め示談交渉(↓) →示談成立  →法廷相場50~100万円の示談金 ※示談拒否が良い
↓                ↓
事案化 ←←←←←← 示談不成立(↓) →示談外交渉 →犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓                ↓
↓               起訴  →公判  →罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓                    
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟

不起訴、起訴猶予

検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上

◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
305仕様書無しさん
2016/03/06(日) 19:26:02.69
>>300
心の汚い奴が汚いコードを書くんだよ。
306仕様書無しさん
2016/03/07(月) 09:00:44.47
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[生涯損害助長SI受注SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
低予備工数見積
時間外労働違反
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死
307仕様書無しさん
2016/03/07(月) 13:26:53.10
>>305
心が汚い俺は
極力他人に責任を擦り付けるように
簡潔で綺麗なコード書いてるぞ
308仕様書無しさん
2016/03/12(土) 22:43:39.85
普通そうだよなー
309仕様書無しさん
2016/03/13(日) 12:10:34.19
オフショアは知らないけどニアショアから返ってきたコードですらまともな物に一度もお目にかかったことないんだけど、そんなもの?

外注の成果物で、おっ、これ書いたやつスゲーって感動したことある人いない?

本当は内部できっちりレビュー出来ればいいんだけど、そうもいかないこともあって死ぬほどメンテしづらいコードをメンテする羽目になるパターンが結構あって大変なんだ。
310仕様書無しさん
2016/03/13(日) 12:42:23.26
>>309
コーディング規約キッチリしてないおまいが悪いだけ。
311仕様書無しさん
2016/03/13(日) 12:52:54.26
規約通りのクソコード書いてやるぜ
312仕様書無しさん
2016/03/13(日) 13:52:34.61
そもそもメーカー側にスゴい人が居ない件
313仕様書無しさん
2016/03/13(日) 14:56:20.18
>>309
スゲー人が書いたスゲーコードが
後にダメな奴にメンテされてダメコードになっている
ってものに、お目にかかった事あるぞ

メンテしづらい、ってのはメンテ方法が分かってないだけの可能性もある

でもまあ、どっちにしろ
ダメコーダーが大多数なのは確かだな
314仕様書無しさん
2016/03/13(日) 16:21:09.90
ダメなオリジナルがダメダメなメンテでボロボロになってるの診てるけど…逃げたい…。
315仕様書無しさん
2016/03/13(日) 17:41:44.42
>>309
>本当は内部できっちりレビュー出来ればいいんだけど、そうもいかないこともあって死ぬほどメンテしづらいコードをメンテする羽目になるパターンが結構あって大変なんだ。
レビューとメンテ、どちらが大変か分かっているなら
答えはひとつだろ?
どんな状況であれレビュー工程をすっ飛ばした人が悪い。

つか、要点を押さえたレビューを適切な時期に軽く実施するだけで、随分と仕上がりは良くなる。
316仕様書無しさん
2016/03/13(日) 22:27:33.16
>>313
スゲー人が書いたスゲーコードを別のスゲー人がメンテしてスゲーコードを書いたら
結果スゲーメンテしづらいコードになる事象が世に溢れている
317仕様書無しさん
2016/03/13(日) 22:39:39.12
>>316
だからレビューしろって。

どこが担当しようが、レビューをしなければ
コードの品質は統一されないの当たり前じゃないか。

コードを書くっていうのは設計をやってるんだぞ。
318仕様書無しさん
2016/03/13(日) 23:28:07.58
>>317
それじゃない
319仕様書無しさん
2016/03/13(日) 23:29:38.24
> スゲー人が書いたスゲーコードを別のスゲー人がメンテしてスゲーコードを書いたら
> 結果スゲーメンテしづらいコードになる事象が世に溢れている

それが本当なら、そうなったものを見てみたいね(笑)


なんなら君、書いてくんない?w
320仕様書無しさん
2016/03/14(月) 00:34:26.77
まあ、スゲーの方向性にもよるな
スゲー人力オプティマイズしたアセンブラとか

でもまあ、話の流れとか行間くらい読んでくれとは思う
321仕様書無しさん
2016/03/17(木) 00:49:29.74
>>319
お前がメンテしたコードにもあったと思うよ
自分が当事者だと気が付かないのかやっぱり
322仕様書無しさん
2016/03/17(木) 01:10:41.52
>>321
そのレスは間違いだね。
なんで言い訳するの?
323仕様書無しさん
2016/03/17(木) 03:39:40.60
綺麗とか汚いとか、定量化出来ない話で盛り上がれるのは技術者じゃ無い。
324仕様書無しさん
2016/03/17(木) 12:20:35.01
>>322
なに言ってんだお前
325仕様書無しさん
2016/03/17(木) 15:41:25.87
俺が思う、メンテできない酷いコード(パート1)

・タブ、空白のインデントがあちこちで乱れている
とにかく汚ねえ!
326仕様書無しさん
2016/03/17(木) 16:29:01.26
コードの見た目に関しては
わりと、どうでもいい。
フォーマッタで解決。
327仕様書無しさん
2016/03/18(金) 20:27:55.03
余計なこといろいろ書いていたらフォーマッタでも解決できない。
328仕様書無しさん
2016/03/18(金) 20:42:55.79
フォーマッタで整形出来ないってw
それ、コンパイルは通るのか?
329仕様書無しさん
2016/03/18(金) 20:58:40.22
引数やローカル変数がたくさん並んでるコードは、バグもたくさん並ぶ
330仕様書無しさん
2016/03/18(金) 21:01:25.43
>>327はどういうケースなんだろうか
具体例が知りたい
草生やしてもなんにもならんし
331仕様書無しさん
2016/03/18(金) 21:04:27.78
>>329
個人的には、引数やローカル変数は4つ以上だと臭うなぁ
10以上とかはもう見るのも嫌
332仕様書無しさん
2016/03/18(金) 21:07:14.94
>>331
引数は少ないに越した事は無いが、ローカル変数はむしろ多い方がいいぞ。
いっそ引数以外は全部ローカル変数にしなさい。
333仕様書無しさん
2016/03/18(金) 21:30:50.90
ローカルがやたら多いのは機能をうまく整理・分割できてなくて、
関数内がコボル状態だろう?
334仕様書無しさん
2016/03/18(金) 21:36:56.26
グローバル変数が多いよりよっぽどまし。
335仕様書無しさん
2016/03/18(金) 22:26:09.43
参照可能な変数がたくさん並んでるコード(ry

メソッドの頭からお尻が巨大なtryで囲まれたコードは、人力トライ&エラーの無限ループに陥る
336仕様書無しさん
2016/03/18(金) 22:59:20.09
local variablesにはimmutable、mutableがあるよね

mutableなのはなるべく少ない方がいいと思う
でも、なるべく少なくする為に、むやみにmethod分割するのはアンチパターンが多い気がする
関数型なlibraryや、block scopeを上手く使えば、自然と減ってくる

一方、immutableの方は、多少多くても、
それが適切なモノなら、まいっかって感じ
337仕様書無しさん
2016/03/18(金) 23:02:00.00
>>333
コボル状態って・・・
それが何か分かってしまう俺がもう嫌

コボラーの人の書いた別の言語のコードって、それが特徴的なんだよなぁ
338仕様書無しさん
2016/03/18(金) 23:05:27.31
>>336
youはlocal variablesよりもtoo manyなenglish wordsをsomehowした方がbetterかと
339仕様書無しさん
2016/03/19(土) 00:47:32.92
>>338
youはsomehowという間違った英語をsomehowした方がいいと思う
340仕様書無しさん
2016/03/19(土) 11:07:36.28
>>337
なるほどあれはコボル由来の書き方だったのか
341仕様書無しさん
2016/03/19(土) 11:34:35.89
ZEROとかONEとかの定数が並ぶコードを書く奴は業界から追放すべき
342仕様書無しさん
2016/03/19(土) 15:20:40.58
リファクタリングにもローカル変数が増えてきたらメソッド分ける指標って書いてあったな。

短いスコープならローカル変数はあまり気にならないけど、スクロール必要なスコープで宣言されてるとレビューしててイラっとくる。
343仕様書無しさん
2016/03/20(日) 02:15:30.33
cssでこういう↓汚いゴミを書く奴

<div class="width-100 font-size-15">

.width-100 {
width: 100%;
}
.font-size-15 {
font-size: 15px;
}
344仕様書無しさん
2016/03/22(火) 16:34:15.62
【偽装請負搾取盗難】

作業やめて盗難届け出せよ!

盗難被害者の例
発注者 支払 140万円 1億円の大儲け
1次受注者 報酬 120万円 20万円の盗難被害額
2次受注者 報酬 80万円 60万円の盗難被害額
3次受注者 報酬 60万円 80万円の盗難被害額
345仕様書無しさん
2016/03/24(木) 01:27:24.98
吉野健太郎の卑怯なTwitterで検索しよう
346仕様書無しさん
2016/04/13(水) 21:26:36.02
動きゃいいんだろ動きゃ
347仕様書無しさん
2016/04/24(日) 13:09:04.87
工数見積りの海を彷徨う
http://hidekatsu-izuno.hatenablog.com/entry/2016/04/24/035446

この手の工数、工期という話題の時、役に立つのは次の資料だ。
IPA ソフトウェア開発データ白書
JUAS ソフトウェアメトリックス調査
素晴らしいことにどちらも PDF 版は無料で配布されているので、ダウンロードして見ることができる。
システム開発サイドだけでなく、エンドユーザ側でも有用な資料だと思う。
348仕様書無しさん
2016/04/24(日) 13:11:30.49
問題は、工数見積りだ。工数は単価をかければそのまま金額になるわけだし、標準工期のベースともなる。
一番重要な指標と言える。しかし工数については、データを見ても分散が大きく、
IPAでも、あくまで目安として50%の信頼幅に収まっているかを見るのに使ってください、というスタンスを取っている。

JUASはもう少し踏み込み、毎年データから回帰分析を行い総工数の見積りに使える式を算出しているのだが、
各年の結果がかなり異なる。例えば、2007年度版では、総工数=1.55×画面数だと書かれている一方、
2009年度版では、総工数=1.09×画面数となっている。ここ数年の版に至っては、画面数だけの分析は削除され、
画面と帳票での分析のみが掲載されている。同じ機能数なのに工数が50%も違うのでは、見積りチェック用途だとしても使いづらい。

とはいえ以前、システム開発はもっと明朗会計にならなければいけないでも書いたように、FP法と総工数には、
分散はあるものの明らかに正の相関が認められる。FP法は「機能」をポイント化しているわけだから、
工数は機能を正しく見積ることができればある程度予測できることが想像できる。

このことから考えると、面倒ではあるが、まじめに FP を求めろという話ではあるのだが、
実際には FP 法での見積りは次のような理由があって難しい。

概算見積りを求められるのは、RFP(Request For Proposal)提示時など要件定義前の
早いタイミングでありエンティティと言った詳細な設計まではとても落とせない。

FP法は、機能ごとの見積りではないため、機能数の削減が工数に与える影響を見積るのが極めて困難である。
この機能を削るからいくら安くします、などという交渉が難しくなる。
349仕様書無しさん
2016/05/03(火) 15:35:39.88
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrent(Covenant)が活発な情報交換・交流コミュニティでオープンソース開発されています(プログラマー募集中)

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise氏)がそういう人と話したいそうなので、よろしければツイートお願いします<(_ _)>
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできない情報発信好きアスペルガーw


通話料が激安になるブラステル(050 Free)で、かなり遅延や音声途切れが発生する方は、以下の設定を試してください
○ Wifiと3Gのコーデックは2つ(GSM、G.711u-Law)とも有効にしておく
○ エコーキャンセルをOFF(チェックを外す)にする
○ あとの設定はデフォルトのまま
http://blog.livedoor.jp/gnunobian/archives/52013458.html
上記の設定でも音質が悪い方は、wolfsonの高音質チップを搭載した機種(Galaxy 初代S、S3、S6、 AQUOSPhone ZETA SH-06E、AQUOSPhone si SH-07E、AQUOSPhone Xx 206SH、 Galaxy Note II)に買い換えて下さい。

500円以下の格安SIMで使えて登録・月額無料、IPベース発信なら携帯へは5.5円/30秒、固定へは8円/3分(月額無料でこの価格はすごい!)
http://blog.jikoman.jp/2015/11/brastel-050-free.html

あと、050Freeの起動もしくは発着信が2週間以上ないとプッシュサーバー期限切れでプッシュ着信が出来なくなるので、Llama Location Profilesで1週間に一度050Freeを自動起動するように設定すると、2週間以上経過してもプッシュ着信できます


最後にロケットストーブの焚き口へ超省電力なDC扇風機で風を送ると、横引き煙突が12m以上あっても煙が逆流してきません。
よって、横引き煙突で超高効率な熱回収ができるので薪が少量で済みます
あと、燃焼室の大きさは『無煙竹ボイラMBG150』で検索して参考にして下さい
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚  
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net	->画像>16枚
350仕様書無しさん
2017/06/08(木) 21:17:42.88
素晴らしいね
351仕様書無しさん
2017/12/29(金) 22:14:01.49
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

ZTZH3R583H
352仕様書無しさん
2018/04/17(火) 07:26:56.74
>>343
ごめんなさい、一カ所変えれば連動させたい部分の調整中にたまにやる
353仕様書無しさん
2018/05/22(火) 13:04:42.81
とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

W3427
354仕様書無しさん
2019/01/21(月) 18:36:08.72
具体的にどのように数字を出したのか
論文にして
355仕様書無しさん
2019/01/21(月) 20:54:47.75
スキルと時間
356仕様書無しさん
2019/01/21(月) 21:18:46.86
汚い方ときれいな方を同時に同じ技術力のプログラマがやって試したの?
357仕様書無しさん
2019/01/21(月) 21:22:27.47
あたりまえだのくらっかー
コード酷いと機能拡張に耐えられなくて下手すりゃ作り直しだからな
358仕様書無しさん
2019/01/21(月) 21:46:39.50
試したの?
359仕様書無しさん
2019/01/22(火) 00:00:57.98
競技プログラミングは害悪ってことかい?
360仕様書無しさん
2019/06/19(水) 12:40:56.24
きれいなコードより単純なコード
必然的にコード量は少なくなり生産性が向上する。
361仕様書無しさん
2019/08/08(木) 20:42:47.58
下手すりゃ、リファクタリングという言葉を知らないプログラマーもいそうだよな
362仕様書無しさん
2019/08/08(木) 20:59:03.45
働かない死んでるコードを大量に残してる奴とかな
363仕様書無しさん
2019/08/09(金) 07:30:12.28
コードの汚さって、ゴミが残されてるのも一つだけど、設計的な意味で中身が汚い。
実際リファクタリングの必要性を感じるコードというのは初心者に多く
そもそもの作り方に難があり、作成者本人でさえ仕様変更に耐えない
SEの要望を満たせないなど、主に保守性に致命的な問題があると
判断されたコードを直す場合がほとんどだね。
作成者を含み誰かしらサラサラっと難なく対応できるなら保守性の高いコード。
364仕様書無しさん
2019/08/22(木) 01:17:42.38
同僚が、1人で1から書いたプログラムを実行しようとしたら、うまく動かなくてソース見たら、
1つの変数の中でキャメルケースとスネークケースと、ローマ字変数名と英語変数名が混ざった上に、ログの出力時刻を固定値代入して、ずっとその時刻使ってログを吐くように書いてあった

他にも色々酷い有様

基地外なのか!?
365仕様書無しさん
2020/01/30(木) 07:56:58.80
【犯罪】無能時間外労働違反SEの追放【損害】
☆不利益で迷惑だから料金増やすか生産減らせ☆
【契約料金や知的財産の生涯損害促進者ばかり】
[偽装請負多重派遣の従犯SEを追放すべき]
偽装請負多重派遣SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者
偽装請負多重派遣SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死
偽装請負多重派遣SEの代償
低収入低技術
非婚離婚
鬱病早死
366仕様書無しさん
2020/02/03(月) 20:55:09.15
競技プログラミングでシンプルなコーディングを身に着けよう!

ニューススポーツなんでも実況



lud20250706021908
このスレへの固定リンク: http://5chb.net/r/prog/1422621412/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net ->画像>16枚 」を見た人も見ています:
IntelCPUの脆弱性修正に使われる秘密鍵が判明 マイクロコード更新内容の解読が可能に
スルガ銀行、若い女性に中古マンションを相場の数倍で買わせ、暴力団に債権回収させてたことも判明
5ちゃんねる不具合★専用ブラウザdatエラー修正方法判明
【悲報】俺氏の彼女、経験人数が3人と判明
池江璃花子選手への五輪出場辞退要請、応援ツイ垢のわずか1/13だった… サブ垢を使い少数が大量に送信していたと判明 [Felis silvestris catus★]
月21回のオナニー射精で前立腺ガン予防になると判明
月21回のオナニー射精で前立腺ガン予防になると判明
「スマホ、SNS、愛知」はハゲの原因になる可能性があると判明
月21回のオナニー射精で前立腺ガン予防になると判明
【悲報】安倍首相はトランプ氏の「完全なるしもべ」だと判明
ウォシュレットを使いすぎるとうんちが漏れやすくなると判明
ドラゴンボール最新映画、悟飯がスーパーサイヤ3になると判明
大坂なおみの家、ロサンゼルスの山火事で黒焦げになる寸前だったと判明
葉書が値上げされると 数枚切手を貼った出し方はできなくなると判明 画像あり
【速報】イギリスでは95%の人がナチスのホロコーストがあったと信じていると判明
【ナゾロジー】不安や抑うつ症状の強い子どもほど、周りに相談できなくなると判明 [すらいむ★]
旧速、安倍政権に都合悪いスレだけ削除基準が厳しいと判明 そりゃ安倍信者の巣窟にもなる罠
【仏】サメの胃から指輪をはめた手…ビーチでシュノーケリング中に行方不明になった男性の結婚指輪と判明
Apple「M2」がアチアチ108度になるのでCPU発熱に警戒感増すところすでにAMD「Zen4」は95度が上限と判明
【研究】世界中の男性の精子数が激減…2045年までに人類は子孫を残せなくなることが判明 ★2 [ニライカナイφ★]
日本、深海探査船が作れなくなる…老朽化で作り直そうとするも、技術者は引退済み、製造設備もすでに撤去されていたと判明
【米調査結果で判明】 喫煙は免疫システムを低下させ、新型コロナウイルス感染を重症化させる、たばこは感染した細胞の数が3倍になる原因 [影のたけし軍団★]
ビーガン菜食主義は寿命が20年縮まると判明
冨田尚弥 座右の銘は「楽勝」と判明
ミハエル・シューマッハはO型と判明
ガン患者の8割が、抗がん剤などの副作用死と判明
【悲報】移民大国の犯罪率、日本より高い国だらけと判明
スティーヴンスピルバーグの血液型はA型と判明
【悲報】BABYMETALの紅白出場が今年も絶望的と判明 …
アメリカのラッパーAZの現在のギャラ、50万と判明
【PSO2】田村、AV同人漫画を割りまくる性獣だと判明
【速報】シーザー、統合失調症(キチガイ病)と判明
ミドリムシを食べ続けると脳の認知機能が改善すると判明
(群馬県) 糞かっぺだった 鉄道の存続すら危うい状態と判明
アラブ人の過半数が日本は核保有国だと認識している事が判明
【超速報】天皇陛下、学生時代のあだ名が「でんでん」だったと判明
ロシア、年間10万本の野球バットが売れる野球大国だったと判明
【悲報】ニシくん、うっかり竹島を独島と言ってしまい&(韓国)と判明
【証拠あり】 寺田のガセネタを次から次へと流してるのはみり愛オタと判明
【地質学】島根で採取の岩石 25億年前のものと判明 日本最古[03/25]
【豚悲報】星2.7のMHWアイスボーンの尼レビューの半数近くが荒らしと判明
女は40代で卵子老化 閉経で出産0%と判明 女終了で何かの生物に変化
上念司のツイートがファクトチェックの結果、デマだったと判明
ネトウヨホルホル雑誌、戦前からあったと判明 日本の伝統だった
【悲報】ジャップの中学3年生の約5人に1人が主語と目的語を読み取れないと判明
チンコの大きさ世界平均 勃起時で長さ13.12cm、太さ11.66cmと判明
美談と思われたバーのマスターが神戸アニメストリート事件の首謀者と判明
現在の運転免許証は 通名 本名 書いてあると判明 在日コリアン オワタw
【速報】 ビル工事現場3人転落死、耐荷重150kgの足場に作業車を載せたためと判明
ブヒッチとPS3の比較動画が公開!ブヒッチはやはりPS3以下の性能だったと判明
男の性欲は女の20倍 性欲の原因の男性ホルモンが20倍あるから 女の性欲0と判明
男の性欲は女の20倍 性欲の原因の男性ホルモンが20倍あるから 女の性欲0と判明
猫の多頭飼い&猫屋敷の糞尿の悪臭で近所迷惑なババアは精神病の異常者だと判明
オスガキは生まれつきジャップオスだと判明 これ半分間引くしかないだろ。。。
池袋のラブホテルで発見された“布団圧縮袋”に入った遺体、30代後半の女性と判明
「好きな子の縦笛を舐めた」経験者にふかわりょうドン引き  9%の男性がなめたことがあると判明
プラスチックパソコン業界に激震、GeForce1170は1080TIをブッちぎる超性能だと判明
マイニンテンドーストアで注文した商品はキャンセル不可と判明 ひどいストアだな
動画削除に激怒する自称主婦のネトウヨ、正体が映り込みでハゲ親父だと判明 弁明開始 ★20
【西日本豪雨】岡山の多数決壊した川 自民党のせいだと判明 整備せず劣化状態で基準未満だった
「君の名は。」1月3日の地上波初放送のエンドロールは新海誠監督自らが編集した特別版と判明
カプコンの真のラブプラス3DS『めがみめぐり』、基本無料+アイテム課金型のゲームだと判明
【日韓】岩屋防衛相、官邸が制止したのにも関わらず熱望して韓国防衛相と笑顔で握手していたと判明
【常識】台風の日に食べるラーメン二郎は普通より美味しいと判明 / ジロリアン「台風だからこそ行く」
【パヨク】玉木雄一郎「安倍が桜を見る会に後援会招待?追及する」 →民主党政権でも後援会を招待してたと判明
犬を飼うと健康で長生きできると判明 飼っていない人に比べて早死が24%低い、心臓発作後の死亡は65%低い

人気検索: 4k繧ュ繝」繝ウ繧ョ繝」繝ォ ロリあうロリ 繧ェ繝ェ繧キ繝シ 小学生 Marsha babko 女子小学生 preteen little girls nude すじコラ 女性顔 illegal porno video Child あうアウpedo little girls
14:59:21 up 101 days, 15:58, 0 users, load average: 8.57, 10.73, 14.11

in 2.4158589839935 sec @2.4158589839935@0b7 on 072803