2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

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

1 :
2015/01/30(金) 21:36:52.73
納期に苦しんでいるSEさま必見の情報です。
今すぐコードが綺麗か汚いかを
ツールを使って調査してみましょう
2 :
2015/01/30(金) 23:53:54.99
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
http://blog-imgs-35.fc2.com/s/u/i/suiseisekisuisui/1299679717yaoi-d.jpg


これエロすぎだろ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
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
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』で検索して参考にして下さい
http://i.imgur.com/iVuglg9.jpg 
http://jp.misumi-ec.com/material/mech/KRT1/PHOTO/KRT1_221004926837.jpg
http://livedoor.blogimg.jp/zoukibayashinokai/imgs/2/a/2a3c6dc0.jpg
111KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: