X

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

■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
2015/01/30(金) 21:36:52.73
納期に苦しんでいるSEさま必見の情報です。
今すぐコードが綺麗か汚いかを
ツールを使って調査してみましょう
0002仕様書無しさん
垢版 |
2015/01/30(金) 23:53:54.99
リア充のイメージ
http://blog-imgs-35.fc2.com/s/u/i/suiseisekisuisui/1299679717yaoi-d.jpg
http://blog-imgs-35.fc2.com/s/u/i/suiseisekisuisui/i0259307-1299670757.jpg
http://1kuchi.way-nifty.com/photos/uncategorized/2011/08/11/000a.jpg
http://gazou.blueneo.jp/img/parody/1298293798.jpg
http://livedoor.blogimg.jp/rjc/imgs/d/2/d2123a71.jpg
http://1kuchi.way-nifty.com/photos/uncategorized/2011/08/11/000d.jpg
http://nukoup.nukos.net/img/110950.jpg
http://livedoor.blogimg.jp/karapaia_zaeega/imgs/5/1/519a0032.jpg
http://image.space.rakuten.co.jp/lg01/23/0000254323/57/img7affbb8azikbzj.jpeg
>>1のイメージ
http://livedoor.blogimg.jp/nomadsokuhou/imgs/5/9/59e9c81f.jpg
http://i.imgur.com/oAhGbRR.png
http://pds.exblog.jp/pds/1/201112/29/15/d0130115_22105645.jpg
0003仕様書無しさん
垢版 |
2015/01/31(土) 00:10:43.49
>>1
コードがクソなのは設計がクソなのはだからな。
0005仕様書無しさん
垢版 |
2015/01/31(土) 08:03:48.11
それっぽく見えるけど、あれあれってのもあるかもね
0006仕様書無しさん
垢版 |
2015/01/31(土) 08:32:19.44
>>3
設計通りに書くのは無能のコーダー
バイト君レベル
設計通りだと汚くなりそうなら提案する
実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ
設計の早期修正は他メンバーを楽にさせる点(1人のコストで10人のコスト削減)で重要
勿論その実績をまとめておいて後で賞与面接とかでアピールするんだぞ
0009仕様書無しさん
垢版 |
2015/01/31(土) 10:23:47.52
>>6
>設計通りだと汚くなりそうなら提案する
>実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ

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

>>1の根拠になるソースはどこ？体感（）？
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
わりとどうでもいい事の例えかな？
最近のコンパイラに掛かれば同じコードに変換されてるみたいな。
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
プログラミング初心者がよくやる。
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
アドレスだけ足りてればメモリはどっかから取ってくるよ。
仮想記憶を勉強してからまたおいで。
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
デスマにしないとホクホクできないブラックさんが・・・
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
おまえマネジメントも上流工程もやったことないだろ？
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
うん。だから最初から余計なミーティングが問題だって言ってる。

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

そういう余計な会議で時間を無駄にしてるんだよ。
0053仕様書無しさん
垢版 |
2015/02/08(日) 23:31:45.37
SEというのは血の巡りが悪いんだから、
プログラマからみれば会議していてもむだ

プログラマの頭の血のめぐりが悪いときは会議でなく散歩だね
会議でじっとしていることが、血行をわるくさせる
会議なんてものはSEの責任逃れ
0056仕様書無しさん
垢版 |
2015/02/09(月) 01:18:46.40
頭にアホ置いた時点で確定するから始まった瞬間に運命決まってるようなもんだ
0058仕様書無しさん
垢版 |
2015/02/09(月) 11:35:22.99
>>36,40
スタック領域 自動拡張
でググったらすぐでるじゃん。
まさか検索もしないでそんな投稿するなんて思いもしないから、英語で検索しないと出ないのかと思っちゃったよ。
すぐに手を動かさない奴は伸びないよ。
0060仕様書無しさん
垢版 |
2015/02/10(火) 19:25:54.41
無能残業者へ
SEの職務は、手入力を減らす事だと
わかってますか？
0061仕様書無しさん
垢版 |
2015/02/10(火) 21:29:57.40
1行目と2行目がまるで噛み合ってない
本人は言いたいこと言えたと思ってるんだろうけど、伝えたいことがまるで伝わらない典型例みたいな文章だな
0064仕様書無しさん
垢版 |
2015/02/11(水) 00:51:02.84
一行目は二行目以降のメッセージを伝えたい相手を特定してるだけだから
噛み合うとか噛み合わないの問題ではない。
0066仕様書無しさん
垢版 |
2015/02/24(火) 14:11:40.91
コードが汚くてもコストは変わらん
人月契約の作業者が疲弊するだけ
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行の中から該当箇所を探し出します。

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

それを理解して、ステップ数を数えてこの人は行数が多い！
たったこれだけの機能をこんなに時間かけて作るんじゃねーよ
大赤字じゃねーか。っていう判断に使うのなら問題ない。
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
異常系からのリカバリーを要求されるシステムだって世の中にごまんとあんのにな
0083仕様書無しさん
垢版 |
2015/04/25(土) 22:25:29.99
リカバリ出来るのは正常系やで
それを異常系と呼んで場当たり的な対処で済まそうとするから
見るもおぞましいソースコードが出来上がるんや
0084仕様書無しさん
垢版 |
2015/04/25(土) 22:58:35.57
>>79
> 異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。

わかってるねｗ

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

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

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

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

やり方が正反対なんだよな。
0087仕様書無しさん
垢版 |
2015/04/26(日) 07:50:30.00
どんなエラーも再起動が唯一の復帰手段、アホか
0090仕様書無しさん
垢版 |
2015/04/26(日) 13:18:51.35
俺わわかってる。

要はエンジョイコーディングってことだろ？
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
昔関数作ったら関数仕様書を作るプロジェクトがあった
その場合人は関数を作らないようにするためその関数の中で修正してしまう
こうして数千行の関数が量産されていく
そこで新たに関数を作ろうものなら空気が読めない人間になる
生きて行くって難しい
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
結構、年齢の高い奴の発言に聞こえるぞ。
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
何の教科書なのか全然わからんが、
良い教科書のやり方に統一すればいいだけじゃん。
どの教科書もたいして変わらんだろうし。

なんで、統一 と 教科書 を別のものって考えてるの？
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
俺がプログラム作ると
いっつも名前がぐしゃぐしゃになるんだが

誰かどうすればいいか教えてくれ
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はすばらしい。
0152仕様書無しさん
垢版 |
2015/12/26(土) 11:44:46.31
>>148
ｓで終わらない複数形はどうするの？
0153仕様書無しさん
垢版 |
2015/12/26(土) 12:03:47.30
>>150
言いたい事は分かるんだが、
enumarableなモノを使わずに、レガシーなlistや配列を多用してるから
そういうワケの分からない自体に陥る
enumarableを使え
listや配列とか古臭い概念からオサラバですわ
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なのか整数なのか文字列なのかクラスなのかが一目でわからんて話でしょ
0179仕様書無しさん
垢版 |
2015/12/26(土) 12:57:53.41
>>178
省略すると基本的に可読性は悪くなるんだぞ？

必要となる情報が、すぐ近くに揃っていることが重要。
あちらこちらを見ないとわからないものは可読性が低い
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という単語を含めるのは至極当然の話である。
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
> だからそれは全てがクラスだからだろ
関係ねーよ。

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

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

逆に入れたほうがいいだろ。
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とか言いはる詐欺製品ｗ
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プログラミングしかやったことない人たちだよな〜
視野が狭すぎて傍からみてると可哀想ぅ〜
0212仕様書無しさん
垢版 |
2015/12/27(日) 10:20:01.96
１．変数の頭に型を示す文字を入れる
　bStartButton


２．変数に型を入れる
　boolStartButton

３．型を入れない
　StartButton


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

基本は３だが１、４も捨てがたい
２はなんか嫌かも
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型の融通利かないバカとド素人以外は

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

たとえばメートル管理、小数点管理ならfMeter
メートル単位の整数管理ならiMeter、nMeter
構造体ならsMeter、クラスインスタンスならcMeter
0225仕様書無しさん
垢版 |
2015/12/27(日) 17:26:04.92
>>222
オブジェクト指向言語で、同じ変数名の変数の型を自動的に置換なんて絶対ありえない。
0226仕様書無しさん
垢版 |
2015/12/27(日) 17:36:37.94
>>224
修正は自動でテストは修正箇所全部だ
テストコードあれば工数は極めて小さくできる
>>225
オブジェクト指向なら尚更だが…
抽象化を柱としているのに型に依存するのは本末転倒
符号付きだろうが符号なしだろうが32bitだろうが64bitだろうが関係ない
数値をどう処理するかにだけ依存するべき
型推論使えばあまり型なんて気にせずにすむぞ
インターフェイスが変わっても修正無しで行けることもある
0228仕様書無しさん
垢版 |
2015/12/27(日) 17:51:31.77
具体性のあるコードがあって初めて抽象化ってのができるもんだろ
ゆとりか？
0233仕様書無しさん
垢版 |
2016/02/18(木) 00:11:06.79
また俺か…忍びねえな…
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文字程度で改行入れてるだろ？
0242仕様書無しさん
垢版 |
2016/02/18(木) 22:34:10.92
> 80文字ってMSDOS時代じゃないんだから

今はスマホ時代ですよ
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
"同じ内容の記述"なんだから、長いとき短いときはないのです
はい
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
統一されてると、格段に理解しやすいし、修正しやすいよ
0257仕様書無しさん
垢版 |
2016/02/20(土) 07:15:47.41
可読性が高いならスタイルの違いなんて些細な問題
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
慣れてない奴は間違いなく無限にあるが
７、８種類しかなくて使い分けてるならいいんでない？
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ヶ月くらいならクソコードがどんな悲惨な状況を生み出すか体験するために我慢するけど、長期間になるなら転職する。
そんなコードを生み出す組織は、コードだけではなくソフトウェア開発に関するすべてにおいてレベルが低いに違いないので、
そんな組織で働くことは成長の機会を放棄するのと同じです。
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
そういう名前の変数が出来る本当の原因は
関数が異常に長いから
0280仕様書無しさん
垢版 |
2016/02/25(木) 00:16:50.00
ここで変数の話は終わった
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
元ネタは「何が嫌いかより 何が好きかで自分を語れよ」だが、
それとは全然意味が違ってる。

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

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

のように汚いコードを言えば、その反対の綺麗なコードがどういうものかわかる。
0289仕様書無しさん
垢版 |
2016/02/25(木) 23:36:30.76
>>286
ヒント：それはお前の主観にすぎん
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
お前自分が支離滅裂な事言ってるって分かってる？
0298仕様書無しさん
垢版 |
2016/02/26(金) 00:04:27.86
>>297
素直に分かってないって言えんのかお前は
0300仕様書無しさん
垢版 |
2016/02/26(金) 06:39:49.50
コードの前に心を綺麗にしなくちゃいけませんね
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項）も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

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

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

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

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

本当は内部できっちりレビュー出来ればいいんだけど、そうもいかないこともあって死ぬほどメンテしづらいコードをメンテする羽目になるパターンが結構あって大変なんだ。
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
お前がメンテしたコードにもあったと思うよ
自分が当事者だと気が付かないのかやっぱり
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かと
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で検索しよう
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』で検索して参考にして下さい
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
ｙ
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
具体的にどのように数字を出したのか
論文にして
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
競技プログラミングでシンプルなコーディングを身に着けよう！
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況