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

0001仕様書無しさん

2015/01/30(金) 21:36:52.73

納期に苦しんでいるSEさま必見の情報です。
今すぐコードが綺麗か汚いかを
ツールを使って調査してみましょう

0002仕様書無しさん

2015/01/30(金) 23:53:54.99

リア充のイメージ

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

>>1のイメージ

0003仕様書無しさん

2015/01/31(土) 00:10:43.49

>>1
コードがクソなのは設計がクソなのはだからな。

0004仕様書無しさん

2015/01/31(土) 00:32:43.44

>>2
1番下初見だわｗｗｗ

0005仕様書無しさん

2015/01/31(土) 08:03:48.11

それっぽく見えるけど、あれあれってのもあるかもね

0006仕様書無しさん

2015/01/31(土) 08:32:19.44

>>3
設計通りに書くのは無能のコーダー
バイト君レベル
設計通りだと汚くなりそうなら提案する
実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ
設計の早期修正は他メンバーを楽にさせる点(1人のコストで10人のコスト削減)で重要
勿論その実績をまとめておいて後で賞与面接とかでアピールするんだぞ

0007仕様書無しさん

2015/01/31(土) 09:02:58.53

そんなのが賞与に反映されると思ってるんだ。

0008仕様書無しさん

2015/01/31(土) 09:24:33.73

太鼓持ちにならないと増えませんからね

0009仕様書無しさん

2015/01/31(土) 10:23:47.52

>>6
>設計通りだと汚くなりそうなら提案する
>実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ

報酬をケチるから、そういうバイト君しか来ないんだろ。
良い人材が欲しければ、それなりに払えよ。

0010仕様書無しさん

2015/01/31(土) 12:07:36.92

どこかの研究か調査で分かったの？それならそのソースは？
昔から割と言われているプログラマーの生産性は数十倍違うってやつは
1950年代だったか1960年代だったかに実際計測して出た数字だから
今でも折にふれて言われているわけで。

>>1の根拠になるソースはどこ？体感（）？

0011仕様書無しさん

2015/01/31(土) 13:57:04.58

これエロすぎだろｗｗｗｗ鼻血出るわｗｗｗｗｗｗ

0012仕様書無しさん

2015/01/31(土) 15:09:10.65

割り込み電話と、無駄な会議を減らせば、それだけで生産性10倍いきそうだな。

0013仕様書無しさん

2015/02/01(日) 09:05:53.59

設計を直すだけならいいけど、そういう奴は大抵仕様を変更しようとするからな。

0014仕様書無しさん

2015/02/01(日) 12:35:07.68

コードコンプリートの下巻にこの話題があったな

0015仕様書無しさん

2015/02/02(月) 19:48:10.79

無能残業して時間報酬相場を下げるな
【知的財産と契約料金の搾取助長者ばかり】
［受注系SI生涯損害促進者を追放すべき］
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

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

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死

0016仕様書無しさん

2015/02/02(月) 21:08:42.11

コードが汚いとかわりと関係無くて、関数やクラス分けがメチャクチャとかのがデスマーチになり易いよ。

0017仕様書無しさん

2015/02/02(月) 21:38:37.36

>>16
そういうのを汚いと言う。

0018仕様書無しさん

2015/02/03(火) 06:21:15.47

0と1というビットの反転で済むところが全部 x = 1 - x; なんて書かれていたから
x ^= 1; へ修正するのに手間が掛かり過ぎた。

0019仕様書無しさん

2015/02/03(火) 07:28:06.37

WebやDBなんてパートがやるべき
【知的財産と契約料金の搾取助長者ばかり】
［受注系SI生涯損害促進者を追放すべき］
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

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

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死

0020仕様書無しさん

2015/02/03(火) 08:17:28.34

手入力を増やしてしまう低技術者
なんとかならないかな？

0021仕様書無しさん

2015/02/03(火) 08:20:28.66

>>18
わりとどうでもいい事の例えかな？
最近のコンパイラに掛かれば同じコードに変換されてるみたいな。

0022仕様書無しさん

2015/02/03(火) 08:41:28.35

>>18
自分の巣に帰れよ。キチガイ野郎

0023仕様書無しさん

2015/02/03(火) 11:38:31.54

>>20
>手入力を増やしてしまう

どういう状況？

0024仕様書無しさん

2015/02/03(火) 12:03:46.85

>>23
そのシステムの画面か、データベースに直接、データを登録するとかじゃないの？

0025仕様書無しさん

2015/02/03(火) 12:21:22.72

よくSEがいう「運用で対応します」ってやつだろｗ
システム化に失敗しましたって意味でも有る。

0026仕様書無しさん

2015/02/03(火) 12:42:41.47

>>25
設計や実装のまずさを手作業で修正、ってのは失敗だけどね。
ただ、システム化＝オールコンピュータ化では必ずしもない。
機械に任せた方が良い部分と手作業が良い部分との区別は必要。
結果的に殆ど機械化というのも当然あり。
事務システムの移行で、氏名の一部が外字登録されてたケースがあったが、
手作業だと年7人日、機械化すると200万円くらい掛かるってんで、
今でもそこは手作業でやってる。

0027仕様書無しさん

2015/02/03(火) 13:09:33.18

>>23
ツール作らない状況です。

0028仕様書無しさん

2015/02/07(土) 11:12:20.98

普通ならメインの処理メソッドの中に、処理Aの呼び出し、処理Bの呼び出し・・・って感じで書くと思うが
とある現場のプログラム見たら、メイン処理の末尾で処理Aの呼び出し、処理Aの末尾で処理Bの呼び出し・・・
って感じで書かれてて、眩暈がした
さらに再帰は全て関数で実現してるし、どんだけコールスタック積むつもりだよｗｗｗ

0029仕様書無しさん

2015/02/07(土) 11:17:59.46

>>28
プログラミング初心者がよくやる。

0030仕様書無しさん

2015/02/07(土) 11:23:31.53

>>28
すまんが、お前の指摘は
コールスタックだけだよな？

0031仕様書無しさん

2015/02/07(土) 11:47:46.58

結婚希望者は不適合
【知的財産と契約料金の搾取助長者ばかり】
［受注系SI生涯損害促進者を追放すべき］
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒

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

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死

0032仕様書無しさん

2015/02/07(土) 15:58:34.08

コールスタックなんて真っ先にオプティマイズされちまう些細な問題だろ。

0033仕様書無しさん

2015/02/07(土) 17:04:35.15

話がそれるかもだが、以前ローカル変数で1Mぐらいのバッファを宣言してるのを見てびっくりした。
スタック溢れないの？と聞いたら、ダイナミックスタックだから溢れない。と言われて、さらにびっくりした。

0034仕様書無しさん

2015/02/07(土) 21:58:58.87

>>33
ダイナミックスタックって何よ？
足りなくなったらヒープから取るのか？

0035仕様書無しさん

2015/02/08(日) 12:59:23.93

>>34
アドレスだけ足りてればメモリはどっかから取ってくるよ。
仮想記憶を勉強してからまたおいで。

0036仕様書無しさん

2015/02/08(日) 15:04:28.69

>>35
実装されてるシステムあるの？

0037仕様書無しさん

2015/02/08(日) 15:09:46.36

初めからちんたら綺麗なコード書いてても時間かかるの同じ

0038仕様書無しさん

2015/02/08(日) 19:20:47.33

>>37
きれいなコードを書くのに時間がかかるという前提が間違ってるよ。
むしろ綺麗なコードを書く人の方が開発速度速いから。

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

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

でも綺麗なコードを書いたことがある人は、前にやったパターンを
なぞるだけだから、最初から綺麗なコードを書ける。だから速い。

0039仕様書無しさん

2015/02/08(日) 19:23:25.92

デスマにしないとホクホクできないブラックさんが・・・

0040仕様書無しさん

2015/02/08(日) 19:29:26.34

>>35
お前再帰関数のスレでも訳の分からん事書いてるだろ

0041仕様書無しさん

2015/02/08(日) 20:16:43.71

関数の最後で関数コールしてるコードでは、普通ジャンプ命令に置き換わってるから、気にすんな。
みんなみんな賢いコンパイラさんが解決してくれてるよ。

0042仕様書無しさん

2015/02/08(日) 20:27:52.13

>>39
デスマってもともとのスケジュールが悪いのが
大きな原因だけど、

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

自分のところの開発フローの効率化も出来ない奴が
他社のシステムの効率化なんて出来ないわけで。

0043仕様書無しさん

2015/02/08(日) 20:47:35.45

>>42
はあ？

0044仕様書無しさん

2015/02/08(日) 20:58:27.79

>>43
はぁじゃねぇよｗ

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

技術力が低いから修正する時間がかかるから
やらなくて済むならやらずにいよう（ユーザー喜ばない）
そのために無駄な時間をかけて、そんなことだから
デスマになるんだと思ったね。

0045仕様書無しさん

2015/02/08(日) 21:34:39.35

>>44
おまえマネジメントも上流工程もやったことないだろ？

0046仕様書無しさん

2015/02/08(日) 21:38:44.79

>>45
それ、何も言い返してないからｗ

0047仕様書無しさん

2015/02/08(日) 21:51:17.07

>>46

0048仕様書無しさん

2015/02/08(日) 21:53:25.02

>>42
デスマについて多い勘違いだね。
デスマってのは、スケジュールひく前に運命が決まるんだよ？

0049仕様書無しさん

2015/02/08(日) 22:06:34.36

>>48
そうだよね。仕事の速度の問題じゃないからね。

0050仕様書無しさん

2015/02/08(日) 22:17:44.75

うん。だから最初から余計なミーティングが問題だって言ってる。

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

そういう余計な会議で時間を無駄にしてるんだよ。

0051仕様書無しさん

2015/02/08(日) 22:33:34.41

デスマが運命とか怖すぎ

0052仕様書無しさん

2015/02/08(日) 23:15:19.44

ミーティングで納期が延びたらいいのにね

0053仕様書無しさん

2015/02/08(日) 23:31:45.37

SEというのは血の巡りが悪いんだから、
プログラマからみれば会議していてもむだ

プログラマの頭の血のめぐりが悪いときは会議でなく散歩だね
会議でじっとしていることが、血行をわるくさせる
会議なんてものはSEの責任逃れ

0054仕様書無しさん

2015/02/08(日) 23:53:56.67

>>51
デスティニー・マネジメント？

0055仕様書無しさん

2015/02/09(月) 00:52:22.33

>>54
「人月の神話」で検索。

0056仕様書無しさん

2015/02/09(月) 01:18:46.40

頭にアホ置いた時点で確定するから始まった瞬間に運命決まってるようなもんだ

0057仕様書無しさん

2015/02/09(月) 02:47:31.21

死の三月

0058仕様書無しさん

2015/02/09(月) 11:35:22.99

>>36,40
スタック領域自動拡張
でググったらすぐでるじゃん。
まさか検索もしないでそんな投稿するなんて思いもしないから、英語で検索しないと出ないのかと思っちゃったよ。
すぐに手を動かさない奴は伸びないよ。

0059仕様書無しさん

2015/02/09(月) 14:35:00.72

>>58
いや、具体的なシステムを知りたいんだが

0060仕様書無しさん

2015/02/10(火) 19:25:54.41

無能残業者へ
SEの職務は、手入力を減らす事だと
わかってますか？

0061仕様書無しさん

2015/02/10(火) 21:29:57.40

1行目と2行目がまるで噛み合ってない
本人は言いたいこと言えたと思ってるんだろうけど、伝えたいことがまるで伝わらない典型例みたいな文章だな

0062仕様書無しさん

2015/02/11(水) 00:03:57.63

俺はわかったけど？

0063仕様書無しさん

2015/02/11(水) 00:42:37.77

分かったと思って実は違ってたパターン

0064仕様書無しさん

2015/02/11(水) 00:51:02.84

一行目は二行目以降のメッセージを伝えたい相手を特定してるだけだから
噛み合うとか噛み合わないの問題ではない。

0065仕様書無しさん

2015/02/11(水) 23:42:39.13

http://daily.2ch.net/test/read.cgi/newsplus/1423664509/
【社会】ソースコードは指紋…　レイアウト、語彙、構文の特性で
作者はほぼ特定できる、その精度95%以上！

0066仕様書無しさん

2015/02/24(火) 14:11:40.91

コードが汚くてもコストは変わらん
人月契約の作業者が疲弊するだけ

0067仕様書無しさん

2015/02/28(土) 10:11:23.55

バク増えて品質は落ちるけどな

0068仕様書無しさん

2015/03/04(水) 23:37:31.77

パクリ増えてに見えたｗ

0069仕様書無しさん

2015/03/11(水) 05:13:45.86

工数を増やすために汚くしておくんだ
短くきれいで安いのでは困る

0070仕様書無しさん

2015/03/13(金) 11:28:04.33

>>69
プログラミングの価値を、コード量で測ろうとしてるもんな。
重要なのは、改善効果の金額換算だろ。

0071仕様書無しさん

2015/04/07(火) 16:08:16.36

今時、日立ですらコード量で仕事量ははからないんだが
どこの話なんだろうか

0072仕様書無しさん

2015/04/13(月) 20:07:05.64

中華の作ったゴミ見るたびに全部書き換えたくなる
つーかあいつら書いたコードゴミすぎてみてるだけで吐きそう

0073仕様書無しさん

2015/04/13(月) 21:00:33.69

開発終わるとステップ数数えさせられるんだが、今時そんなことしないの？

0074仕様書無しさん

2015/04/13(月) 22:06:13.84

>>73
ステップ数はコストだよ？

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

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

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

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

それを理解して、ステップ数を数えてこの人は行数が多い！
たったこれだけの機能をこんなに時間かけて作るんじゃねーよ
大赤字じゃねーか。っていう判断に使うのなら問題ない。

0075仕様書無しさん

2015/04/13(月) 22:24:28.28

>>74
なんていうか、くどいなー

0076仕様書無しさん

2015/04/13(月) 23:17:35.25

ステップ数が多いほど生産性が高いとかのたまうのが東証一部上場企業のPMだから終わってるわ
いしど

0077仕様書無しさん

2015/04/25(土) 15:45:38.43

きれいなコードだなぁと思ったら異常処理が一切書かれてなかったでござる

0078仕様書無しさん

2015/04/25(土) 16:53:57.26

プログラムは簡単という奴が書いたソースはほぼそれ

0079仕様書無しさん

2015/04/25(土) 19:41:39.24

異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。

0080仕様書無しさん

2015/04/25(土) 20:13:08.13

使うのが自分自身だけなら問題はない
他人が使うもので非対策はゴミ以下

0081仕様書無しさん

2015/04/25(土) 20:29:11.16

異常系からのリカバリーを要求されるシステムだって世の中にごまんとあんのにな

0082仕様書無しさん

2015/04/25(土) 22:02:47.66

要求されるならリカバリーが必要だな

0083仕様書無しさん

2015/04/25(土) 22:25:29.99

リカバリ出来るのは正常系やで
それを異常系と呼んで場当たり的な対処で済まそうとするから
見るもおぞましいソースコードが出来上がるんや

0084仕様書無しさん

2015/04/25(土) 22:58:35.57

>>79
> 異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。

わかってるねｗ

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

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

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

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

やり方が正反対なんだよな。

0085仕様書無しさん

2015/04/25(土) 23:28:48.57

まったくわかってないね
実務経験あるの？

0086仕様書無しさん

2015/04/26(日) 04:02:02.98

>>84
Windowsで言うところのブルースクリーンだな
復帰不能

0087仕様書無しさん

2015/04/26(日) 07:50:30.00

どんなエラーも再起動が唯一の復帰手段、アホか

0088仕様書無しさん

2015/04/26(日) 11:53:39.51

>>85
悔しいからって、負け惜しみ言うだけで
消えるなよｗ

0089仕様書無しさん

2015/04/26(日) 11:54:25.37

>>87
それは論点ずれすぎてるｗ
わかってないよお前。

0090仕様書無しさん

2015/04/26(日) 13:18:51.35

俺わわかってる。

要はエンジョイコーディングってことだろ？

0091仕様書無しさん

2015/04/26(日) 14:56:29.83

異常処理は書かないｗｗｗｗ

0092仕様書無しさん

2015/04/26(日) 15:27:09.91

>>83
そうなんだよね。
リカバリー出来る様にするならそれは正常系なんだよ。
設計のバカが担当が異常系で処理させれば済むって事で
初期の設計に入れてないんだよw

0093仕様書無しさん

2015/04/28(火) 18:45:01.75

エラーを無視すれば、どんなエラーが出ても
続行できる。

0094仕様書無しさん

2015/04/30(木) 05:32:00.21

>>93
エラーが物理的な要因による物でもそう言えるならあんた帰っていいよ。

0095仕様書無しさん

2015/05/23(土) 10:09:24.72

>>71
未だにやってるよ
設計もしてないのにステップ数から
見積りとかバカかと言ったら
逆ギレされた

0096仕様書無しさん

2015/09/16(水) 14:15:27.14

俺は綺麗なコードや汚いコードに基本文句を言わない。
ある程度スパゲティでも構わないし (いや実際には構うんだけど) 苦情や文句を言うこともない。
2ちゃんねるとかで質問者が変な書き方したがっててもいちいち突っ込まない。
同じ書き方で回答を提示する。

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

特に複数人で修正して回ったようなスパゲティコードは手に追えない。
たぶん納期に追われてプログラマが辞めながら作って行ったらしきコードなんだろうけど、
これだけは本当にどうにかしてほしい。

0097仕様書無しさん

2015/09/17(木) 12:30:24.05

思想が一貫してれば書き方なんかどうでもいいわ
>>96は多分思想がバラバラなんだろうけど

0098仕様書無しさん

2015/09/17(木) 12:43:39.63

昔関数作ったら関数仕様書を作るプロジェクトがあった
その場合人は関数を作らないようにするためその関数の中で修正してしまう
こうして数千行の関数が量産されていく
そこで新たに関数を作ろうものなら空気が読めない人間になる
生きて行くって難しい

0099仕様書無しさん

2015/09/17(木) 21:16:49.01

あるある
最長1万行の関数を見たことが有る

0100仕様書無しさん

2015/09/17(木) 21:34:25.02

世の中って本当に難しいな

0101仕様書無しさん

2015/09/18(金) 00:37:54.43

>>99
意図的にそれで手続きが問題ないならたいしたスキルだよ

0102仕様書無しさん

2015/09/18(金) 06:29:38.61

>>101
マジレスすると意図的に長い関数を書くのは割と簡単
気をつかうのは変数名ぐらいで良い
無意識に長い関数を書けるからすごいんだ

0103仕様書無しさん

2015/09/18(金) 07:18:35.22

>>102
確かにブロック化すればスコープも解決できるし
簡単といえば簡単だな、可読性も段違いで良くなるし

0104仕様書無しさん

2015/09/18(金) 07:22:35.64

つか普段からやってるわ
関数化すると可読性が悪くなる（複雑化する）やつはブロック化

0105仕様書無しさん

2015/09/18(金) 09:01:58.53

全然関係ないけど、90年代に比べて読みやすい関数の大きさが倍だと答えられてるらしい
単にディスプレイの大きさの問題だとか

0106仕様書無しさん

2015/09/18(金) 10:37:14.73

経験しないとわからないものがあるw
昔のCコンパイラは関数の先頭で変数宣言しないとコンパイルエラー
使うかわからない変数が数十個並んでる
これには未初期化で使用されRelease版でのみ発生する不具合がつきまとう
再現性がたまに発生するものは極めて厄介
更にマッチスレッドがこれに絡むと地獄
またソースはこれまでの修正でコメントや#if0づくめ
数百行コメントアウトとかざらにある
ネストもむちゃくちゃで信用できない
統合環境なんてないから有効行の判断も解読しながらの作業
ほんと今の統合環境ありがたいw

0107仕様書無しさん

2015/09/26(土) 06:40:15.97

OSの入ってるマシンで何かを動かそうとするからめんどくせぇんだよ
インベーダーマシンはインベーダー専用にしろよ

0108仕様書無しさん

2015/12/09(水) 21:23:16.96

>>106
おまいは何歳だよ?w
結構、年齢の高い奴の発言に聞こえるぞ。

0109仕様書無しさん

2015/12/09(水) 21:27:38.16

3ヶ月前

0110仕様書無しさん

2015/12/09(水) 21:52:41.86

異変は

0111仕様書無しさん

2015/12/09(水) 22:58:09.92

とある片田舎で

0112仕様書無しさん

2015/12/09(水) 23:36:29.46

起きたかのように

0113仕様書無しさん

2015/12/10(木) 00:31:33.21

少女が

0114仕様書無しさん

2015/12/10(木) 00:48:12.52

（白人男性）「なんだ？あの雲は！？」

0115仕様書無しさん

2015/12/13(日) 02:27:54.43

メニューボタン画面別に実装させんな
全部一緒でいいだろ！

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

挙句に共通関数は自社の無能に任せて何度も仕様変更して全画面修正
getなんちゃらを呼び出すと副作用があったり画面側が頑張って仕様と違う動作を修正しなきゃいけなかったり
なんなのこいつら何で死なないの？

0116仕様書無しさん

2015/12/13(日) 10:12:04.55

>>115
SIer系、かつ言語はMS系もしくはJava？
該当するなら、そういう仕事は避けるべし

0117仕様書無しさん

2015/12/13(日) 10:15:22.43

＞共通関数は自社の無能に任せて
それ、"無能"に任せてるとかじゃなくて、"無能"が自社の"無能エース"を信頼してるって図式なんですが

0118名無しさん＠そうだ選挙に行こう

2015/12/14(月) 09:23:08.23

そりゃあ組織形態が汚いので
コードが汚いかは関係無いな。

0119名無しさん＠そうだ選挙に行こう

2015/12/14(月) 12:07:26.69

関係なくはないだろう？
組織形態の汚さが、コードの汚さにつながるのだから、
コードが汚いと、組織形態も汚いと考えるべき。
コードを見ればいろんなことがわかるんだよ。

0120名無しさん＠そうだ選挙に行こう

2015/12/14(月) 12:12:22.30

まず何が綺麗かを組織で決定してないとな。
「俺はこれが綺麗なんだもん」で書かれた記述は間違いなく汚い。
記述の綺麗さはまず統一性。

0121名無しさん＠そうだ選挙に行こう

2015/12/14(月) 12:19:35.19

> まず何が綺麗かを組織で決定してないとな。

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

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

そうしないと、変な書き方が社内標準とされてしまう。

0122名無しさん＠そうだ選挙に行こう

2015/12/14(月) 12:20:09.95

どう書いてもお前のコードが汚いコード

0123名無しさん＠そうだ選挙に行こう

2015/12/14(月) 12:40:51.47

>ソースコードの品質をはかるツールが有るのだから

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

ニ三年前に見た評価ツールは、関数の大きさが100行もあるやつはだめで、
小さくなっているかを測るやつ。

0124名無しさん＠そうだ選挙に行こう

2015/12/14(月) 14:09:25.80

汚いコードってのは、クラス分けがテキトーで、
似た様な処理ってだけで集めて第１引数の値で細部が異なるスーパー関数で、
全部グローバル変数だから誰がどこからでも変更してOKで、
ポインターが三重くらいあるのがザラで…

0125仕様書無しさん

2015/12/14(月) 22:54:16.45

綺麗さの基準が統一性ってのは賛成

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

クソも統一がとれていれば厳かなクソとなる

0126仕様書無しさん

2015/12/14(月) 23:03:45.43

よし皆で一緒にクソしようぜ！

0127仕様書無しさん

2015/12/14(月) 23:05:36.55

プログラミングの入門書に載ってるプログラムはなんであんなクソばかりなのかいつも疑問に感じてる。

0128仕様書無しさん

2015/12/14(月) 23:59:47.68

>>127
カーニハン・リッチーもクソなの？

0129仕様書無しさん

2015/12/15(火) 00:48:50.75

>>126
何の教科書なのか全然わからんが、
良い教科書のやり方に統一すればいいだけじゃん。
どの教科書もたいして変わらんだろうし。

なんで、統一と教科書を別のものって考えてるの？

0130仕様書無しさん

2015/12/15(火) 01:00:51.51

いや明らかに別だろ

0131仕様書無しさん

2015/12/15(火) 01:03:36.30

では明らかに別であることを証明してください。

0132仕様書無しさん

2015/12/15(火) 01:06:02.98

>>127
> プログラミングの入門書に載ってるプログラムはなんであんなクソばかりなのかいつも疑問に感じてる。
入門書だから

>>129
> カーニハン・リッチーもクソなの？
クソではなくて時代遅れ。
1978年出版でC言語が標準化されるよりも前のもの

0133仕様書無しさん

2015/12/15(火) 01:08:39.85

>>131
そうゆう考えがより自分勝手に拍車をかけて結果的に別にするんだよ

0134仕様書無しさん

2015/12/15(火) 01:43:37.16

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［生涯損害助長SI受注SEを追放すべき］
偽装請負従犯SEの動機
コミ障人格障害
コンピュータ趣味
文系大卒低偏差値大卒
情報処理資格非保有者

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

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病
早死

0135仕様書無しさん

2015/12/15(火) 02:05:54.08

133 返信：仕様書無しさん[sage] 投稿日：2015/12/15(火) 01:08:39.85
> >>131
> そうゆう考えがより自分勝手に拍車をかけて結果的に別にするんだよ

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

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

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

そういう考えってなんだよ？

0136仕様書無しさん

2015/12/15(火) 13:28:34.21

なんでも思い通りになると思わん方がいいんじゃね

0137仕様書無しさん

2015/12/15(火) 15:31:50.56

自己主張乙
それが好き勝手に拍車をかけるっつーの

0138仕様書無しさん

2015/12/18(金) 09:48:48.96

１行つか１文加えるだけで便利になるのに仕様に無いから削除しろって方が頭ん中疑うわ。

0139仕様書無しさん

2015/12/18(金) 16:01:48.49

基本は外部仕様と一定の速度だけ満たせばいいって会社と、
内部仕様まで完全に綺麗に統一しなきゃだめって会社あるんだよね。

後者は害が多いと思う。
変なことにまで決まりが出来てくるのもそうなんだけど、
そもそも、結局内部実装をきちんと把握して管理できる人は事実上誰も居ないこと。
作者でさえ10日後にはコードを忘れてしまうのに。

0140仕様書無しさん

2015/12/19(土) 12:18:28.17

上層部がそれを求めてるんだらしゃーない

粒度粒度粒度うっせーんだよ

0141仕様書無しさん

2015/12/20(日) 02:11:03.71

求めてっつっても、その上層部含め誰もコードを把握してないじゃないか。
する必要すらないし。

0142仕様書無しさん

2015/12/20(日) 14:20:33.69

中華が作った糞コードの保守は確かに10倍以上辛いわ

0143仕様書無しさん

2015/12/20(日) 17:49:10.94

>>142
最終的に高くつくんだよな
保守も奴らにやらせりゃいいんだ、格安で

0144仕様書無しさん

2015/12/20(日) 18:12:13.41

俺がプログラム作ると
いっつも名前がぐしゃぐしゃになるんだが

誰かどうすればいいか教えてくれ

0145仕様書無しさん

2015/12/20(日) 18:19:24.95

英語を勉強しる

0146仕様書無しさん

2015/12/20(日) 23:05:40.97

>>144
動詞、目的語の順に書いて、Listのときには_listとつける。
日本語を使いまくる。俺はこれで保守しやすいプログラムを
量産してる。

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

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

}

0147仕様書無しさん

2015/12/21(月) 09:40:28.90

日本語変数や関数って、文字コード問題あるから要注意な。

0148仕様書無しさん

2015/12/26(土) 08:59:52.56

>>146
listより複数形sをつける方が直感的だと思う
俺も昔はlistをつけてたけど、sの方が直感的だと思うようになった

0149仕様書無しさん

2015/12/26(土) 09:06:29.63

日本語プログラムってエディタで書いて実行するだけなら、問題は起きないよね
周辺ツール(チェックツールとか)が対応していなかったりするから、日本語はやっぱり避けてる

0150仕様書無しさん

2015/12/26(土) 10:30:49.19

>>148
sは配列のときに使う。
リストのときは_listがいい。
配列とリストを相互に変換するときわけがわからなくなる。
_listだ。_listにしとけ。_listはすばらしい。

0151仕様書無しさん

2015/12/26(土) 10:46:12.59

構造体は？

0152仕様書無しさん

2015/12/26(土) 11:44:46.31

>>148
ｓで終わらない複数形はどうするの？

0153仕様書無しさん

2015/12/26(土) 12:03:47.30

>>150
言いたい事は分かるんだが、
enumarableなモノを使わずに、レガシーなlistや配列を多用してるから
そういうワケの分からない自体に陥る
enumarableを使え
listや配列とか古臭い概念からオサラバですわ

0154仕様書無しさん

2015/12/26(土) 12:04:38.90

しまった
enumerableなモノですね

0155仕様書無しさん

2015/12/26(土) 12:08:03.18

>>153
フレームワークで配列しか受け付けないのもあるし、
Listを使うのは追加の処理があってインデックスでアクセスしたいからだよ。
古いとか新しいとか関係ない。ケースバイケースだ。

0156仕様書無しさん

2015/12/26(土) 12:08:51.72

>>152
そういう英単語は、プログラミングではまず登場しないから、心配無用
万が一の場合は間違っていても無理矢理sをつけるとかして、ごまかせばいい
そもそも、そういう英単語を選んだらダメなんだけどな
personとかdataとかinformationとか・・・

0157仕様書無しさん

2015/12/26(土) 12:09:56.16

dataはまあ別にいいかもな(個人的には好きじゃないけど)
datum -> dataで済むし

0158仕様書無しさん

2015/12/26(土) 12:10:58.91

>>157
data_list
これでおｋ

0159仕様書無しさん

2015/12/26(土) 12:11:48.87

datumってなんか秋みたいじゃない？せつなくならない？
_listってつけたらほっこりするよ。

0160仕様書無しさん

2015/12/26(土) 12:14:03.81

今は使ってる人が随分と減った気がするけど
オブジェクトは接頭辞で明確化するのが今でも最強だと思ってる。
データベースならマスタがm_***、テーブルはt_***、ビューはv_***。
クラスならC***、変数ならi***、l***、n***、dw***、s***みたいに。

これなら変数の目的が一文字目を見るだけで一目瞭然。
先頭小文字もクリアだし、***の部分は名詞に限定すればいい。
型という概念が曖昧なPHPなんかはこういう書き方してると特に助かる。

0161仕様書無しさん

2015/12/26(土) 12:15:52.52

>>155
大体分かりましたわ
アナタがたぶん正しいわ
俺も必要に迫られたらlistとsを使い分けると思う

0162仕様書無しさん

2015/12/26(土) 12:17:48.33

>>160
ハンガリアン記法の一言で

0163仕様書無しさん

2015/12/26(土) 12:21:25.69

つまり連続物かどうかがわかれば良い話で
listとsをわざわざ分けて名前を付ける必要があるのかと

0164仕様書無しさん

2015/12/26(土) 12:21:51.86

>>160
懐かしいな。
昔はそれがスタンダードな命名の１つだったよな。
俺は１０年くらい前に卒業したけど。

0165仕様書無しさん

2015/12/26(土) 12:23:42.37

>>164
使うなという現場なら使わないけど、それ以外は使ってる
卒業するようなものじゃない

0166仕様書無しさん

2015/12/26(土) 12:24:04.39

>>163

>>161を書いたけど、必要に迫られるケースがあるんだよ
ListとArrayで大幅にメソッドが違う言語では特に
ListとArrayがほぼ同じ扱いな言語とは話が違ってきたり

0167仕様書無しさん

2015/12/26(土) 12:25:31.12

>>165
いや、別にそれが好きなら使えばいいじゃんね
俺は、もう使わない
ただそれだけ

0168仕様書無しさん

2015/12/26(土) 12:29:07.99

>>160はハンガリアンじゃなくて
何なる命名規則な。

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

省略されたらわかりづらい程度の話

0169仕様書無しさん

2015/12/26(土) 12:31:18.51

> 変数ならi***、l***、n***、dw***、s***みたいに。
こっちはハンガリアンだな。

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

これはMSが間違いだったと認めたもので、
つまり誰も推奨していない。やってはいけないもの。

0170仕様書無しさん

2015/12/26(土) 12:32:30.22

ハンガリアン表記は批判的に言われることが多いけど、
実践的な技術だと思うんだよなあ

0171仕様書無しさん

2015/12/26(土) 12:43:42.77

>>166
宣言部を見れば良い
今時ならカーソルを合わせれば型が見れるし
インテリセンスもあるでしょ

0172仕様書無しさん

2015/12/26(土) 12:47:08.03

宣言部を見なければいけない。
カーソルを合わせなければいけない。
インテリセンスを使わなければいけない。
これらは、リーディングのときの負担だと思うぞ。

0173仕様書無しさん

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

0174仕様書無しさん

2015/12/26(土) 12:49:18.32

>>172
その最初の一瞬だけ見れば済む確認手順を省略するために
名前に長々としたものを書き加える無駄さ

0175仕様書無しさん

2015/12/26(土) 12:49:49.47

>>171
> 今時ならカーソルを合わせれば型が見れるし

動的言語なので、カーソル合わせただけじゃわかりませんー。

0176仕様書無しさん

2015/12/26(土) 12:51:15.91

>>174
可読性ってそういうものだよ。

書くのが面倒でも、読みやすさの方を優先するべき。
どうせ補完機能で、書く面倒さは軽減されるんだから。

0177仕様書無しさん

2015/12/26(土) 12:54:40.25

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

接頭辞の話と違うくね？
StartButtonだけじゃbooleanなのか整数なのか文字列なのかクラスなのかが一目でわからんて話でしょ

0178仕様書無しさん

2015/12/26(土) 12:55:27.36

>>176
可読性が悪いってことなんだが

0179仕様書無しさん

2015/12/26(土) 12:57:53.41

>>178
省略すると基本的に可読性は悪くなるんだぞ？

必要となる情報が、すぐ近くに揃っていることが重要。
あちらこちらを見ないとわからないものは可読性が低い

0180仕様書無しさん

2015/12/26(土) 13:00:36.15

>>175
いきなり動的で書き始めるバカはいないだろ

0181仕様書無しさん

2015/12/26(土) 13:02:15.73

>>177
> StartButtonだけじゃbooleanなのか整数なのか文字列なのかクラスなのかが一目でわからんて話でしょ

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

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

btnStart だと、タイプ数が減る代わりに覚えることが増える。
今の主流が省略した名前をつけるのではなく、その場に明確に
書きましょうって流れなだけ。

0182仕様書無しさん

2015/12/26(土) 13:06:27.46

>>179
だったらintAbc、doubleDefなら一目瞭然だろ、と言ってるのと同じ
というかlistだのsだの付けるよりこの方がもっと正確に一発でわかるわな

0183仕様書無しさん

2015/12/26(土) 13:12:42.11

>>181
それはC#のように全てをクラスとして考えてる言語の場合だろ
C言語だったらdoubleを使わずに浮動小数点クラスを使えって話

0184仕様書無しさん

2015/12/26(土) 13:13:00.20

>>182
それが一目瞭然に見えるのは、

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

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

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

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

だから、正しい名前として、StartButtonとつけるのが今は主流だが
それを btnStart とつけるのは、名前の付け方の好みの違いなだけ。

0185仕様書無しさん

2015/12/26(土) 13:13:43.52

>>182
データ型を変換するところではそれやる。
double型のAなのか、int型のAなのか示したいってとき。
オーバーフローを気にしたいときはint32_valueとかね。

0186仕様書無しさん

2015/12/26(土) 13:16:36.71

MSが間違って解釈した「間違いハンガリアン」は
データ型を含めるもの。

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

データ型は名前の一部ではないが、Buttonというのは
名前の一部であるから、正しい名前をつける一貫として
Buttonという単語を含めるのは至極当然の話である。

0187仕様書無しさん

2015/12/26(土) 13:18:31.92

>>186
だからそれは全てがクラスだからだろ

0188仕様書無しさん

2015/12/26(土) 13:19:33.86

一応補足しておく。

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

この２つの言い方は紛らわしいので、ハンガリアンの名誉回復と
頭に接頭語をつけることが全て間違いだと勘違いしている人のために
俺はあえて「間違いハンガリアン」と言わせてもらうけどなｗ

0189仕様書無しさん

2015/12/26(土) 13:21:32.56

>>184
valueとか型も正しい名前も糞もあったもんじゃねえ名前のオブジェクトもあるわな

0190仕様書無しさん

2015/12/26(土) 13:21:39.02

>>187
> だからそれは全てがクラスだからだろ
関係ねーよ。

たとえクラスがなかったとしても、ボタン（データかポインタか知らんが）に
ボタンという名前を含めるのは何も間違ったことではない。

0191仕様書無しさん

2015/12/26(土) 13:22:44.95

>>190
>>177

0192仕様書無しさん

2015/12/26(土) 13:23:18.64

>>189
それ以外に正確に意味を表せる言葉がないんだろ？
ならvalueでいいだろ。

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

逆に入れたほうがいいだろ。

0193仕様書無しさん

2015/12/26(土) 13:23:49.40

>>191
話を戻すな。>>181でレスしてる。
レスするなら、続きを書け

0194仕様書無しさん

2015/12/26(土) 13:30:28.85

>>192
話が通じねえ、深海と火星の話を思い出した

0195仕様書無しさん

2015/12/26(土) 13:34:11.65

トルネコ「
　　まあまあきみたち。そんなにこうふんしないでください。

お前らはいきり立った。

0196仕様書無しさん

2015/12/26(土) 13:54:56.52

システムハンガリアンのデメリットは、システムハンガリアンがアプリケーションハンガリアンじゃないってことだろ。
つまり、両方使ったら最強。
button_button_agree ←OKボタン
boolean_agree ←OKボタンを押したか

0197仕様書無しさん

2015/12/26(土) 13:58:02.82

ボットンボットンって便所みたいだな

0198仕様書無しさん

2015/12/26(土) 13:59:27.32

日本以外でなんとかハンガリアン使ったら大笑いモノ

0199仕様書無しさん

2015/12/26(土) 14:03:17.71

海外のソース見るとMSハンガリアンとやらを使ってる奴多いわ

0200仕様書無しさん

2015/12/26(土) 23:13:41.63

釣りだろうけど、
Buttonを含めるのが当然とは思えないなあ。

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

じゃ、スーパーのドアなどに「引」と書いてあるけど、
あれは「ドアを引く」と書いてないと意味が通じないのか？
ドアに「引」と書いてあったら、ドアを引くにきまってるじゃん？

0201仕様書無しさん

2015/12/27(日) 04:43:27.61

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

ソースコードにボタンの絵が書いてあるのか？

0202仕様書無しさん

2015/12/27(日) 05:36:50.25

ソースコードにテキストしか使えないのにvisual studioとか言いはる詐欺製品ｗ

0203仕様書無しさん

2015/12/27(日) 07:01:30.79

なんか屁理屈言い出したからどうでもいいや

0204仕様書無しさん

2015/12/27(日) 08:03:22.69

変数は、型と名称でワンセットなんだから名称だけじゃソース的には情報不足
型名の代わりに長ったらしい名前を付ける奴もいるみたいだけど
そんな回りくどく非直感的な変数名など、読む方はたまったもんじゃない

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

MSがなんと言ったのかは知らないけどMSハンガリアンとやらは
シンプルながら可読性を一気に押し上げる良いルールだと思うよ

0205仕様書無しさん

2015/12/27(日) 08:09:44.37

>>199
MSも2003年（もっと前？）からシステムハンガリアンは禁止みたいなことを言い出したが
ドライバー開発のサンプルプログラムから消えたのはWindows8のWDKサンプルからだし
MSが推奨しないので頭にデータ型を書くのは辞めようと決めてもCやC++の開発者の中には、
StartButton_bとしたり、アンダーバーが禁止されるとStartButtonbとかStartButtonBとかで
とにかく変数にデータ型を入れないことに抵抗する輩は必ずいたそうだ。
しかし今残っているのは既存コードの変数名を替える様なこともしていないだけでは？

0206仕様書無しさん

2015/12/27(日) 08:24:00.30

> ドライバー開発のサンプルプログラムから消えたのはWindows8のWDKサンプルからだし

そりゃ互換性を保たないといけないから仕方ない

0207仕様書無しさん

2015/12/27(日) 08:32:30.65

型が変わったから変数名を変えるというのをデメリットと言う奴もいるけど
型を変えるってのはそもそもリスクのある行為だから使用箇所を確実に確認できるメリットもある

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

もちろんハンガリアンに馴染みのない世代がダセェと思うのは当然
俺だって仕事用だったり、公開目的なら言語に合わせて書き方は変えてるけど
便利なものは便利なんだよね

0208仕様書無しさん

2015/12/27(日) 09:09:07.33

>>181
> これをMSが間違いだと認めた時点で、推奨する人はだれもいなくなった。

こういう嘘を恥ずかしげもなく言う馬鹿いるんだｗ
MSは別に間違いだとはまったく認めてないぞ
.Net開発では使わないでくれと言っているだけ
一方で賛否両論があることを認めている

0209仕様書無しさん

2015/12/27(日) 09:45:26.60

ハンガリアン記法に拘る人って時代の変化についていけない人たちだよね～
どっちがいいとか悪いとかの以前の問題で、なんか気持ち悪い～

0210仕様書無しさん

2015/12/27(日) 09:47:01.21

あとWindowsプログラミングしかやったことない人たちだよな～
視野が狭すぎて傍からみてると可哀想ぅ～

0211仕様書無しさん

2015/12/27(日) 09:52:24.43

>>209 >>210
頭の弱い人も可哀想ぅ～w

0212仕様書無しさん

2015/12/27(日) 10:20:01.96

１．変数の頭に型を示す文字を入れる
　bStartButton

２．変数に型を入れる
　boolStartButton

３．型を入れない
　StartButton

４．変数の後ろに型を示す文字を入れる？
　StartButton_b
　

基本は３だが１、４も捨てがたい
２はなんか嫌かも

0213仕様書無しさん

2015/12/27(日) 10:50:40.82

変数名大文字始まりとか嫌だわ

0214仕様書無しさん

2015/12/27(日) 11:18:30.38

booleanのstartButtonって用途が全く分からん変数だな
そこからして全然ダメじゃん

0215仕様書無しさん

2015/12/27(日) 12:51:12.08

そのインスタンスを使う関数の内容次第だろ。
5,6行の関数ならインスタンス名は b とかで十分な時もあるだろうし、
他のボタンも引数で必要なら start_b とかする必要があるだろうし。

0216仕様書無しさん

2015/12/27(日) 13:46:25.57

>>212
3の1択
型変わるときに変数名に型あるとミスリードする可能性がある
昔short使っていてそれをintに変えるからと修正したらとんでもない無駄な工数が発生する
型推論も随分広まってきたから型の判断は統合環境に任せればいい

0217仕様書無しさん

2015/12/27(日) 16:42:12.52

shortからintでどんな名称変更したんだよ
というか型を変えるのに影響箇所いっさい確認しないのか？

0218仕様書無しさん

2015/12/27(日) 16:45:15.36

データ型を変更するくらいなら、変数を新しく作って使った方がいい。

0219仕様書無しさん

2015/12/27(日) 16:55:24.26

いまはIDEのリファクタリング機能で変数の名前変更はサクッと行けちゃうよ

0220仕様書無しさん

2015/12/27(日) 16:57:49.88

>>209
プログラミングってのは書けば書くほど、どんな記法が最良かってのが自然と見えてくる
限られた時間で沢山書いて沢山読むのに、誰だって面倒なのは嫌だからね
他人が作ったルールを馬鹿正直に全て受け入れてるプログラマはまずいないし
A型の融通利かないバカとド素人以外は

メリットがあるからこそ使い続ける人がいる、それだけの話

0221仕様書無しさん

2015/12/27(日) 17:00:56.87

>>218
確かにそうだな
とするとハンガリアンのデメリットは無いね　>>212は1の1択

0222仕様書無しさん

2015/12/27(日) 17:02:51.33

>>217
影響箇所はもちろん確認するが型だけ変えるのと変数も変えるのとでは大きく違う
型なら全置換で終わる場合もあるが変数名となるとマンパワーが欠かせない
また人がやるからヒューマンエラーが入り込んでくる
規模が大きいと些細なことでも山となる
そもそも型程度が可読性に影響するならそれは糞でかメソッドだと思うがな

0223仕様書無しさん

2015/12/27(日) 17:10:52.53

>>214
StartButtonを例えに出すのがそもそも悪い
こんなのボタンコントロールのインスタンス以外の何物でもないわ

たとえばメートル管理、小数点管理ならfMeter
メートル単位の整数管理ならiMeter、nMeter
構造体ならsMeter、クラスインスタンスならcMeter

0224仕様書無しさん

2015/12/27(日) 17:16:57.65

>>222
影響箇所の確認について矛盾したこと思いっきり書いてるぜ

0225仕様書無しさん

2015/12/27(日) 17:26:04.92

>>222
オブジェクト指向言語で、同じ変数名の変数の型を自動的に置換なんて絶対ありえない。

0226仕様書無しさん

2015/12/27(日) 17:36:37.94

>>224
修正は自動でテストは修正箇所全部だ
テストコードあれば工数は極めて小さくできる
>>225
オブジェクト指向なら尚更だが…
抽象化を柱としているのに型に依存するのは本末転倒
符号付きだろうが符号なしだろうが32bitだろうが64bitだろうが関係ない
数値をどう処理するかにだけ依存するべき
型推論使えばあまり型なんて気にせずにすむぞ
インターフェイスが変わっても修正無しで行けることもある

0227仕様書無しさん

2015/12/27(日) 17:45:49.04

今度はマンパワーと自動修正の矛盾

0228仕様書無しさん

2015/12/27(日) 17:51:31.77

具体性のあるコードがあって初めて抽象化ってのができるもんだろ
ゆとりか？

0229仕様書無しさん

2015/12/27(日) 17:59:42.00

>>210
NDKなどLinux系でも使ってるよ

0230仕様書無しさん

2016/02/11(木) 16:05:57.82

age

0231仕様書無しさん

2016/02/17(水) 02:42:20.92

いきなり途絶えてたな。全部自演か。

0232仕様書無しさん

2016/02/17(水) 21:17:35.64

俺は二重人格じゃないよ

0233仕様書無しさん

2016/02/18(木) 00:11:06.79

また俺か…忍びねえな…

0234仕様書無しさん

2016/02/18(木) 01:38:44.87

この板なんか臭い

0235仕様書無しさん

2016/02/18(木) 21:31:26.21

同じコードなのに、人によって、書き方(スタイル)が違うのって嫌だよなぁ

common_method1(a, b, c)

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

こういうのも汚いよね
grepしにくいし、２，３ならまだしも何十もあると、理解するだけで大変

0236仕様書無しさん

2016/02/18(木) 21:31:58.06

例はあんまり突っ込まないで
適当に書いただけ、とくに意味はない

0237仕様書無しさん

2016/02/18(木) 21:44:51.47

わかるよ
１行の文字数は、もちろん長すぎるのも読みにくいけど
一番読みにくいのが１行１文字みたいな使い方。
見易さに気を使ってるのかもしれないけど
見たいのは一つ一つの命令じゃなくて前後を含めた広範囲のロジックだから
スクロールせず１画面でできるだけ多くの情報を見たいわけで

だからってコメントも空行もなしじゃ境がわかりにくいので
何事も程々にだな

0238仕様書無しさん

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文字に収められる。

0239仕様書無しさん

2016/02/18(木) 22:13:16.85

80文字ってMSDOS時代じゃないんだから

なんでも構造体にすりゃいいってもんでもなくて
引数はI/Oを厳密に指定できるメリットがある
不要な引数はデフォルト化したりね

0240仕様書無しさん

2016/02/18(木) 22:25:25.81

>>239
文字数はMSDOS時代とは関係ない。視野の話。

お前だってその文章、たった半角40文字程度で改行入れてるだろ？

0241仕様書無しさん

2016/02/18(木) 22:31:21.97

だってスマホなんだもの

0242仕様書無しさん

2016/02/18(木) 22:34:10.92

> 80文字ってMSDOS時代じゃないんだから

今はスマホ時代ですよ

0243仕様書無しさん

2016/02/18(木) 22:55:09.92

スマホでプログラミングはしないだろ

0244仕様書無しさん

2016/02/18(木) 23:21:41.78

>>235の意味は

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

です

0245仕様書無しさん

2016/02/18(木) 23:29:25.41

80は今の時代にすこし狭く感じる
commit msgとかは80 (76)でいいけど
今は100とかの方がよいと個人的に思う

0246仕様書無しさん

2016/02/18(木) 23:32:48.29

>>244
> 同じ内容の記述なら同じスタイルじゃないとメンテしにくい

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

長いときと短いときで、適切な書き方をするべきである。

0247仕様書無しさん

2016/02/19(金) 07:04:15.83

>>246
"同じ内容の記述"なんだから、長いとき短いときはないのです
はい

0248仕様書無しさん

2016/02/19(金) 09:15:44.40

>>247
意味がわからないなら無理やり参加しなくていいんだよ

0249仕様書無しさん

2016/02/19(金) 13:20:15.91

吉野健太郎の卑怯なTwitterで検索しよう

0250仕様書無しさん

2016/02/19(金) 18:28:14.22

フォーマッター使えばいいやん
メジャーな言語なら大体定義ファイルも特定の箇所だけ除外する仕組みも用意されてるでしょ

0251仕様書無しさん

2016/02/19(金) 18:35:04.78

フォーマッターは見にくいものを直してくれるのと
誤字脱字を発見するためで、見やすくするためのものじゃないよ

0252仕様書無しさん

2016/02/19(金) 21:05:18.75

>>250
なるほど、フォーマッターでスタイルは完全に揃うね
でも、IDE/Vim/Sublimeとか色々あって、１つのformatterを強制できないわ
どしたらいい？

0253仕様書無しさん

2016/02/19(金) 21:09:08.73

「スタイルが統一されていれば見やすい」は間違いだからな。

0254仕様書無しさん

2016/02/19(金) 21:27:53.44

統一されてると、格段に理解しやすいし、修正しやすいよ

0255仕様書無しさん

2016/02/19(金) 21:37:54.83

>>253
スタイルがバラバラなのよりマシ

0256仕様書無しさん

2016/02/20(土) 07:05:41.63

バラバラって、たかが２種類だろ大袈裟な

0257仕様書無しさん

2016/02/20(土) 07:15:47.41

可読性が高いならスタイルの違いなんて些細な問題

0258仕様書無しさん

2016/02/20(土) 09:33:26.59

>>256
そもそもスタイルが存在してない場合もある。

0259仕様書無しさん

2016/02/20(土) 09:56:45.61

初心者はそうだろうな
プログラミングに長けてる奴は適材適所で２、３種類くらいじゃん？

0260仕様書無しさん

2016/02/20(土) 13:55:08.84

【主な偽装請負従犯要員SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てツール]
ノンプログラミングツール
フレームワーク
COBOL
VＢ
.net
Java
Web
DB
ERP
SAP

0261仕様書無しさん

2016/02/20(土) 14:10:36.69

>>256
2種類じゃなくて、７，８種類もあったらどう？

0262仕様書無しさん

2016/02/20(土) 14:11:34.06

>>235は何十って言ってるじゃん
そこを"2つ"と言い切るのは、変ですな

0263仕様書無しさん

2016/02/20(土) 22:18:15.01

>>261
慣れてない奴は間違いなく無限にあるが
７、８種類しかなくて使い分けてるならいいんでない？

0264仕様書無しさん

2016/02/20(土) 22:20:01.55

>>262
まずは何十を挙げてから出直せ、話はそれからだ

0265仕様書無しさん

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/

0266仕様書無しさん

2016/02/24(水) 17:41:07.65

・main()にすべてが詰まってる
・コメントでバージョン管理されている
そんな汚物コードをメンテするんだが
そういうときの精神衛生保全のために皆どんな工夫してる？

0267仕様書無しさん

2016/02/24(水) 18:02:33.66

>>266
1ヶ月くらいならクソコードがどんな悲惨な状況を生み出すか体験するために我慢するけど、長期間になるなら転職する。
そんなコードを生み出す組織は、コードだけではなくソフトウェア開発に関するすべてにおいてレベルが低いに違いないので、
そんな組織で働くことは成長の機会を放棄するのと同じです。

0268仕様書無しさん

2016/02/24(水) 18:08:10.16

吉野健太郎は危険ドラッグ薬事法違反で有罪判決 [転載禁止]･2ch.net
http://potato.2ch.net/test/read.cgi/21oversea/1445778429/

0269仕様書無しさん

2016/02/24(水) 19:49:27.98

>>266
他の会社行こう

0270仕様書無しさん

2016/02/24(水) 19:56:01.86

>>コメントでバージョン管理されている
バージョン管理はファイル名だろ。やり直し

0271仕様書無しさん

2016/02/24(水) 21:36:28.64

>>266
マジレス

・ローカルPCでGitを使って開発する (これ絶対)
・コード整形verと汚物verの両方を、うまく使い分ける
(閲覧・開発は前者、成果物は汚物verへ移植)

0272仕様書無しさん

2016/02/24(水) 21:38:37.45

>>266
移植作業には、WinならWinMergeがよいと思う
編集しながらコード差分、比較可能だから
(そんな知ってるわ!ｗだったらｽﾏｿ)

0273仕様書無しさん

2016/02/24(水) 21:42:02.57

>>266
修正コメント("YYYY/MM/DD 山田太郎追加"みたいなの)は、
自作ツールとかで、さくっと行単位で追加、編集、削除できるようにする
エディタのマクロでもいいし、AutoHotkeyとかのキーバインドツールでもおｋ
(そんな既にやってるよ！だったらｽﾏｿ)

0274仕様書無しさん

2016/02/24(水) 21:42:55.43

色々書いたけど、最終的には転職した方がいいよ
全く希望がないです。そういう企業は

0275仕様書無しさん

2016/02/24(水) 21:49:07.24

>>273
可読性とは言うが、可書性とは言わない。

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

読みにくなる原因の一つである修正コメントを
簡単に増やせるようにしてはいけない。
それは簡単に読みにくくするための道具だ。

0276仕様書無しさん

2016/02/24(水) 22:27:32.57

何をしてるのかをコメントに残して欲しいのに
そういうのは一切書かないで、変数の日本語名を
使用箇所全てにコメントとして書く意味不明さ。

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

変数名自体もわかりにくいし、どの変数も似た名前だし。
これならC#みたいに変数名に日本語使われた方がまだマシ。

0277仕様書無しさん

2016/02/24(水) 22:42:16.43

>>276
そういう名前の変数が出来る本当の原因は
関数が異常に長いから

0278仕様書無しさん

2016/02/24(水) 22:45:50.13

>>277
DB設計

0279仕様書無しさん

2016/02/24(水) 23:10:21.23

今は変数の話をしてる

0280仕様書無しさん

2016/02/25(木) 00:16:50.00

ここで変数の話は終わった

0281仕様書無しさん

2016/02/25(木) 00:39:06.68

>>275

>>273だけ見て脊髄反射やめて
>>266もミテネ！

0282仕様書無しさん

2016/02/25(木) 00:52:48.78

>>276
少し分かる

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

例えば、

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

みたいな奴

0283仕様書無しさん

2016/02/25(木) 11:17:24.47

先日コードが汚ないと注意されたプログラマーが拗ねて退職したw

0284仕様書無しさん

2016/02/25(木) 19:05:27.03

何が汚いかより何が綺麗かでコードを語れよ

0285仕様書無しさん

2016/02/25(木) 20:28:36.79

時給換算5,000円以下のSEの皆様へ

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

発注者より

0286仕様書無しさん

2016/02/25(木) 21:46:20.57

>>284
元ネタは「何が嫌いかより何が好きかで自分を語れよ」だが、
それとは全然意味が違ってる。

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

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

のように汚いコードを言えば、その反対の綺麗なコードがどういうものかわかる。

0287仕様書無しさん

2016/02/25(木) 22:55:32.98

>>286
オブジェクト指向で書かれてて汚い

0288仕様書無しさん

2016/02/25(木) 23:26:21.52

>>287
どういうコードが？

0289仕様書無しさん

2016/02/25(木) 23:36:30.76

>>286
ヒント：それはお前の主観にすぎん

0290仕様書無しさん

2016/02/25(木) 23:38:25.59

>>289
ツール使って解析しているので主観ではない。

0291仕様書無しさん

2016/02/25(木) 23:46:02.92

>>290
客観的な指標があるのならわざわざ反例をあげて回りくどいやり方をする必要はないな。
お前の思う良いコードを例にだせば良いよ、誰も文句は言えんだろ。

0292仕様書無しさん

2016/02/25(木) 23:49:16.27

>>291
仕事で書いたコードなのだから書いたコードは誰でも見れるので例に出すまでもない。
ただし良いコードを見ただけで同じように書けるわけじゃないので
日々コードレビューを行って問題点の指摘とどうすればいいかを教えている。

0293仕様書無しさん

2016/02/25(木) 23:50:15.73

ツールで計測できる客観的な指標というのは、だめであると言う理由だけ
どうすればいいかまでは教えてくれない。もしどうすればいいのかまで
教えるツールが存在するならば、ツールが勝手に修正できるはずだろう。

0294仕様書無しさん

2016/02/25(木) 23:54:30.52

>>292
お前はアホか？俺にはお前のコードか見えんぞ。
それともアホの俺には見えんコードを書いてるのかお前は？

0295仕様書無しさん

2016/02/25(木) 23:57:25.78

>>294
会社のコードなんだから、社外の人間のお前にはみれん。
当たり前だろｗ

0296仕様書無しさん

2016/02/25(木) 23:59:34.44

>>295
お前自分が支離滅裂な事言ってるって分かってる？

0297仕様書無しさん

2016/02/26(金) 00:02:29.89

>>296
どこが？
文章に下線引くなどして、具体的に指摘してみて。

0298仕様書無しさん

2016/02/26(金) 00:04:27.86

>>297
素直に分かってないって言えんのかお前は

0299仕様書無しさん

2016/02/26(金) 00:04:46.74

指摘して見せてって言った後のレスがこれかｗ

0300仕様書無しさん

2016/02/26(金) 06:39:49.50

コードの前に心を綺麗にしなくちゃいけませんね

0301仕様書無しさん

2016/02/26(金) 11:11:45.36

そうですね

0302仕様書無しさん

2016/02/26(金) 13:35:50.03

その前に風呂はいれよ

0303仕様書無しさん

2016/03/02(水) 21:42:56.28

時給換算5,000円以下のSEの皆様へ

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

発注者より

0304仕様書無しさん

2016/03/04(金) 08:12:32.69

犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料)　or 司法書士が代筆（料金は5万円ぐらい）
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付（疎明資料・証拠にはＩＣレコーダー、スマホによる録音が適しています）
↓
審査　→　不受理　→　告訴状再提出または刑法第193条で訴えを起こす
↓
受理　→　告訴事実を認め示談交渉（↓）　→示談成立　　→法廷相場50～100万円の示談金　※示談拒否が良い
↓　　　　　　　　　　　　　　　　↓
事案化　←←←←←←　示談不成立（↓）　→示談外交渉　→犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓　　　　　　　　　　　　　　　　↓
↓　　　　　　　　　　　　　　　起訴　　→公判　　→罰金刑＝前科（起訴事実を認めてるため）→追討ち民事訴訟
↓　　　　　　　　　　　　　　　　　　　　
審査　→　起訴（強制捜査・留置場）→　公判　→　懲役刑などの厳罰（反省が認められないため）→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第３０条（検察審査会へ申し立て）→　起訴　→　起訴後は同上
刑法第193条（公務員職権濫用）で検察事務官を刑事告訴　→　同上

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

注意：告訴が受理されない理由
●３年間（※）の時効が過ぎたもの　※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの　※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。

0305仕様書無しさん

2016/03/06(日) 19:26:02.69

>>300
心の汚い奴が汚いコードを書くんだよ。

0306仕様書無しさん

2016/03/07(月) 09:00:44.47

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［生涯損害助長SI受注SEを追放すべき］
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

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

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死

0307仕様書無しさん

2016/03/07(月) 13:26:53.10

>>305
心が汚い俺は
極力他人に責任を擦り付けるように
簡潔で綺麗なコード書いてるぞ

0308仕様書無しさん

2016/03/12(土) 22:43:39.85

普通そうだよなー

0309仕様書無しさん

2016/03/13(日) 12:10:34.19

オフショアは知らないけどニアショアから返ってきたコードですらまともな物に一度もお目にかかったことないんだけど、そんなもの？

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

本当は内部できっちりレビュー出来ればいいんだけど、そうもいかないこともあって死ぬほどメンテしづらいコードをメンテする羽目になるパターンが結構あって大変なんだ。

0310仕様書無しさん

2016/03/13(日) 12:42:23.26

>>309
コーディング規約キッチリしてないおまいが悪いだけ。

0311仕様書無しさん

2016/03/13(日) 12:52:54.26

規約通りのクソコード書いてやるぜ

0312仕様書無しさん

2016/03/13(日) 13:52:34.61

そもそもメーカー側にスゴい人が居ない件

0313仕様書無しさん

2016/03/13(日) 14:56:20.18

>>309
スゲー人が書いたスゲーコードが
後にダメな奴にメンテされてダメコードになっている
ってものに、お目にかかった事あるぞ

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

でもまあ、どっちにしろ
ダメコーダーが大多数なのは確かだな

0314仕様書無しさん

2016/03/13(日) 16:21:09.90

ダメなオリジナルがダメダメなメンテでボロボロになってるの診てるけど…逃げたい…。

0315仕様書無しさん

2016/03/13(日) 17:41:44.42

>>309
＞本当は内部できっちりレビュー出来ればいいんだけど、そうもいかないこともあって死ぬほどメンテしづらいコードをメンテする羽目になるパターンが結構あって大変なんだ。
レビューとメンテ、どちらが大変か分かっているなら
答えはひとつだろ？
どんな状況であれレビュー工程をすっ飛ばした人が悪い。

つか、要点を押さえたレビューを適切な時期に軽く実施するだけで、随分と仕上がりは良くなる。

0316仕様書無しさん

2016/03/13(日) 22:27:33.16

>>313
スゲー人が書いたスゲーコードを別のスゲー人がメンテしてスゲーコードを書いたら
結果スゲーメンテしづらいコードになる事象が世に溢れている

0317仕様書無しさん

2016/03/13(日) 22:39:39.12

>>316
だからレビューしろって。

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

コードを書くっていうのは設計をやってるんだぞ。

0318仕様書無しさん

2016/03/13(日) 23:28:07.58

>>317
それじゃない

0319仕様書無しさん

2016/03/13(日) 23:29:38.24

> スゲー人が書いたスゲーコードを別のスゲー人がメンテしてスゲーコードを書いたら
> 結果スゲーメンテしづらいコードになる事象が世に溢れている

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

なんなら君、書いてくんない？ｗ

0320仕様書無しさん

2016/03/14(月) 00:34:26.77

まあ、スゲーの方向性にもよるな
スゲー人力オプティマイズしたアセンブラとか

でもまあ、話の流れとか行間くらい読んでくれとは思う

0321仕様書無しさん

2016/03/17(木) 00:49:29.74

>>319
お前がメンテしたコードにもあったと思うよ
自分が当事者だと気が付かないのかやっぱり

0322仕様書無しさん

2016/03/17(木) 01:10:41.52

>>321
そのレスは間違いだね。
なんで言い訳するの？

0323仕様書無しさん

2016/03/17(木) 03:39:40.60

綺麗とか汚いとか、定量化出来ない話で盛り上がれるのは技術者じゃ無い。

0324仕様書無しさん

2016/03/17(木) 12:20:35.01

>>322
なに言ってんだお前

0325仕様書無しさん

2016/03/17(木) 15:41:25.87

俺が思う、メンテできない酷いコード(パート1)

・タブ、空白のインデントがあちこちで乱れている
とにかく汚ねえ！

0326仕様書無しさん

2016/03/17(木) 16:29:01.26

コードの見た目に関しては
わりと、どうでもいい。
フォーマッタで解決。

0327仕様書無しさん

2016/03/18(金) 20:27:55.03

余計なこといろいろ書いていたらフォーマッタでも解決できない。

0328仕様書無しさん

2016/03/18(金) 20:42:55.79

フォーマッタで整形出来ないってw
それ、コンパイルは通るのか？

0329仕様書無しさん

2016/03/18(金) 20:58:40.22

引数やローカル変数がたくさん並んでるコードは、バグもたくさん並ぶ

0330仕様書無しさん

2016/03/18(金) 21:01:25.43

>>327はどういうケースなんだろうか
具体例が知りたい
草生やしてもなんにもならんし

0331仕様書無しさん

2016/03/18(金) 21:04:27.78

>>329
個人的には、引数やローカル変数は4つ以上だと臭うなぁ
10以上とかはもう見るのも嫌

0332仕様書無しさん

2016/03/18(金) 21:07:14.94

>>331
引数は少ないに越した事は無いが、ローカル変数はむしろ多い方がいいぞ。
いっそ引数以外は全部ローカル変数にしなさい。

0333仕様書無しさん

2016/03/18(金) 21:30:50.90

ローカルがやたら多いのは機能をうまく整理・分割できてなくて、
関数内がコボル状態だろう？

0334仕様書無しさん

2016/03/18(金) 21:36:56.26

グローバル変数が多いよりよっぽどまし。

0335仕様書無しさん

2016/03/18(金) 22:26:09.43

参照可能な変数がたくさん並んでるコード(ry

メソッドの頭からお尻が巨大なtryで囲まれたコードは、人力トライ&エラーの無限ループに陥る

0336仕様書無しさん

2016/03/18(金) 22:59:20.09

local variablesにはimmutable、mutableがあるよね

mutableなのはなるべく少ない方がいいと思う
でも、なるべく少なくする為に、むやみにmethod分割するのはｱﾝﾁﾊﾟﾀｰﾝが多い気がする
関数型なlibraryや、block scopeを上手く使えば、自然と減ってくる

一方、immutableの方は、多少多くても、
それが適切なﾓﾉなら、まいっかって感じ

0337仕様書無しさん

2016/03/18(金) 23:02:00.00

>>333
コボル状態って・・・
それが何か分かってしまう俺がもう嫌

コボラーの人の書いた別の言語のコードって、それが特徴的なんだよなぁ

0338仕様書無しさん

2016/03/18(金) 23:05:27.31

>>336
youはlocal variablesよりもtoo manyなenglish wordsをsomehowした方がbetterかと

0339仕様書無しさん

2016/03/19(土) 00:47:32.92

>>338
youはsomehowという間違った英語をsomehowした方がいいと思う

0340仕様書無しさん

2016/03/19(土) 11:07:36.28

>>337
なるほどあれはコボル由来の書き方だったのか

0341仕様書無しさん

2016/03/19(土) 11:34:35.89

ZEROとかONEとかの定数が並ぶコードを書く奴は業界から追放すべき

0342仕様書無しさん

2016/03/19(土) 15:20:40.58

リファクタリングにもローカル変数が増えてきたらメソッド分ける指標って書いてあったな。

短いスコープならローカル変数はあまり気にならないけど、スクロール必要なスコープで宣言されてるとレビューしててイラっとくる。

0343仕様書無しさん

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;
}

0344仕様書無しさん

2016/03/22(火) 16:34:15.62

【偽装請負搾取盗難】

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

盗難被害者の例
発注者支払 140万円 1億円の大儲け
1次受注者報酬 120万円 20万円の盗難被害額
2次受注者報酬 80万円 60万円の盗難被害額
3次受注者報酬 60万円 80万円の盗難被害額

0345仕様書無しさん

2016/03/24(木) 01:27:24.98

吉野健太郎の卑怯なTwitterで検索しよう

0346仕様書無しさん

2016/04/13(水) 21:26:36.02

動きゃいいんだろ動きゃ

0347仕様書無しさん

2016/04/24(日) 13:09:04.87

工数見積りの海を彷徨う
http://hidekatsu-izuno.hatenablog.com/entry/2016/04/24/035446

この手の工数、工期という話題の時、役に立つのは次の資料だ。
IPA ソフトウェア開発データ白書
JUAS ソフトウェアメトリックス調査
素晴らしいことにどちらも PDF 版は無料で配布されているので、ダウンロードして見ることができる。
システム開発サイドだけでなく、エンドユーザ側でも有用な資料だと思う。

0348仕様書無しさん

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法は、機能ごとの見積りではないため、機能数の削減が工数に与える影響を見積るのが極めて困難である。
この機能を削るからいくら安くします、などという交渉が難しくなる。

0349仕様書無しさん

2016/05/03(火) 15:35:39.88

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrent（Covenant）が活発な情報交換・交流コミュニティでオープンソース開発されています（プログラマー募集中）

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

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

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

通話料が激安になるブラステル（050 Free）で、かなり遅延や音声途切れが発生する方は、以下の設定を試してください
○ Wifiと３Ｇのコーデックは２つ（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の起動もしくは発着信が２週間以上ないとプッシュサーバー期限切れでプッシュ着信が出来なくなるので、Llama Location Profilesで１週間に一度050Freeを自動起動するように設定すると、２週間以上経過してもプッシュ着信できます

最後にロケットストーブの焚き口へ超省電力なDC扇風機で風を送ると、横引き煙突が12ｍ以上あっても煙が逆流してきません。
よって、横引き煙突で超高効率な熱回収ができるので薪が少量で済みます
あと、燃焼室の大きさは『無煙竹ボイラMBG150』で検索して参考にして下さい
コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net ->画像>15枚

ｙ

0350仕様書無しさん

2017/06/08(木) 21:17:42.88

素晴らしいね

0351仕様書無しさん

2017/12/29(金) 22:14:01.49

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

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

ZTZH3R583H

0352仕様書無しさん

2018/04/17(火) 07:26:56.74

>>343
ごめんなさい、一カ所変えれば連動させたい部分の調整中にたまにやる

0353仕様書無しさん

2018/05/22(火) 13:04:42.81

とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

W3427

0354仕様書無しさん

2019/01/21(月) 18:36:08.72

具体的にどのように数字を出したのか
論文にして

0355仕様書無しさん

2019/01/21(月) 20:54:47.75

スキルと時間

0356仕様書無しさん

2019/01/21(月) 21:18:46.86

汚い方ときれいな方を同時に同じ技術力のプログラマがやって試したの？

0357仕様書無しさん

2019/01/21(月) 21:22:27.47

あたりまえだのくらっかー
コード酷いと機能拡張に耐えられなくて下手すりゃ作り直しだからな

0358仕様書無しさん

2019/01/21(月) 21:46:39.50

試したの？

0359仕様書無しさん

2019/01/22(火) 00:00:57.98

競技プログラミングは害悪ってことかい？

0360仕様書無しさん

2019/06/19(水) 12:40:56.24

きれいなコードより単純なコード
必然的にコード量は少なくなり生産性が向上する。

0361仕様書無しさん

2019/08/08(木) 20:42:47.58

下手すりゃ、リファクタリングという言葉を知らないプログラマーもいそうだよな

0362仕様書無しさん

2019/08/08(木) 20:59:03.45

働かない死んでるコードを大量に残してる奴とかな

0363仕様書無しさん

2019/08/09(金) 07:30:12.28

コードの汚さって、ゴミが残されてるのも一つだけど、設計的な意味で中身が汚い。
実際リファクタリングの必要性を感じるコードというのは初心者に多く
そもそもの作り方に難があり、作成者本人でさえ仕様変更に耐えない
SEの要望を満たせないなど、主に保守性に致命的な問題があると
判断されたコードを直す場合がほとんどだね。
作成者を含み誰かしらサラサラっと難なく対応できるなら保守性の高いコード。

0364仕様書無しさん

2019/08/22(木) 01:17:42.38

同僚が、1人で1から書いたプログラムを実行しようとしたら、うまく動かなくてソース見たら、
1つの変数の中でキャメルケースとスネークケースと、ローマ字変数名と英語変数名が混ざった上に、ログの出力時刻を固定値代入して、ずっとその時刻使ってログを吐くように書いてあった

他にも色々酷い有様

基地外なのか！？

0365仕様書無しさん

2020/01/30(木) 07:56:58.80

【犯罪】無能時間外労働違反SEの追放【損害】
☆不利益で迷惑だから料金増やすか生産減らせ☆
【契約料金や知的財産の生涯損害促進者ばかり】
［偽装請負多重派遣の従犯SEを追放すべき］
偽装請負多重派遣SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者
偽装請負多重派遣SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死
偽装請負多重派遣SEの代償
低収入低技術
非婚離婚
鬱病早死

0366仕様書無しさん

2020/02/03(月) 20:55:09.15

競技プログラミングでシンプルなコーディングを身に着けよう！