これからコードを書く人に絶対やって欲しいこと★2

1 ：2013/04/07 〜 最終レス ：2013/05/13

もしくはやって欲しくないこと
先輩方のアドバイスをください
前スレ
これからコードを書く人に絶対やって欲しいこと
http://kohada.2ch.net/test/read.cgi/prog/1362887297/

2 ：

宗教論争が激化する傾向にあります．ご注意ください．
http://www.bugbearr.jp/?プログラミング言語%2F宗教論争

3 ：

糞スレになっちゃったしどうでもいいわー

4 ：

スレタイが漠然としてて論争になりがちだよな

5 ：

馬鹿が馬鹿な論争しかしないスレをまた立てたんか。
おまいら、このスレに専念していろよな。
隔離スレ決定

6 ：

以下の三冊は必読。
『コードコンプリート』
『リーダブルコード』
『達人プログラマ』

7 ：

また1文字変数の話題で1000目指すの？

8 ：

三項演算子って書き方で随分とみやすさが変わるよな。
みんなどんな書き方をしてる？

9 ：

よくある三項演算子の書き方例
スタンダード
value = cond1 ? value1 : value2

value = cond1 ? value1 :
　 　　 　cond2 ? value2 :
　 　　 　cond3 ? value3 :
　　　　　　　　　　value4

10 ：

条件や値が長くなった場合
value = condcondcondcondcondcond1
　? valuevaluevaluevaluevaluevalue1
　: valuevaluevaluevaluevaluevalue2

11 ：

ただ問題は、三項演算子は見やすい書き方があるが
これに対応したフォーマッターがないということ。
カスタマイズも難しい。

12 ：

>>9の二つ目は分かるけど>>10みたいに三項のうち一つでも改行するなら俺はifを使うなぁ

13 ：

またフォーマッタの話題か。
スレ立ててやったからこっちでやれ
フォーマッターを使う人と使わない人の違い
http://toro.2ch.net/test/read.cgi/tech/1365304270/

14 ：

value = if cond1 then value1 else value2

15 ：

>>12
こう書くって話？
int value;
if(condcondcondcondcondcond1) {
　value = valuevaluevaluevaluevaluevalue1
} else {
　value = valuevaluevaluevaluevaluevalue2
}
「変数の再代入は禁止」という考え方には反してるな。

16 ：

>>14
ifが戻り値を返す言語だね。
その書き方は、三項演算子と同じだよ。

17 ：

>>15
宣言しなければよくね？って言語によるのか俺がアホなのか

18 ：

つーか再代入禁止するとi++とかどうすんだよｗ
って思う俺はやっぱりアホなのか

19 ：

>>13
いちいちクソスレ立てんなカス

20 ：

>>6
リーダブルコード以外読んで無いからよんでみようかな

21 ：

変数名つけるときの単語力が乏しいんだけど
実際に命名された変数名まとめみたいなのないのかな

22 ：

俺もそういうの欲しい
hoge1
hoge2
fuga
とかになる

23 ：

『アプリケーションを作る英語』という本がお薦め。
もともと、ローカライズするときのUIとかメッセージに使う英語の話題を扱ったものなんだけど、シンボルの名前を決めるときの参考にも十分なるよ。

24 ：

>>23
早速買ってみる

25 ：

変数名こそググってコピペろよ。

26 ：

良し悪しが判断できないのよ...
もっと良い表現があるのではないかと

27 ：

変数名なんて適当でいいんだよ、コードが分かりにくいのは名前のせいじゃない。

28 ：

>>27
名前は大事

29 ：

変数名に限らず関数名やマクロ定義もそうだけど、リテラルの名前付けは重要。
無駄にコメントの量ばっか増やさなくても、読んで理解しやすいリテラル名を考えろ。

30 ：

リテラル名てお前

31 ：

今思えばCの関数とかきもい名前ばっかりだ

32 ：

UNIXのシステムコールと連携してるからな。
昔のFORTRAN時代は、パンチカードの制限からラベルは6文字以内の制限が有った。
creat(2)は何とかして欲しかった。

33 ：

あえていうが（プレフィックス抜きにして）Win32APIの命名は好き

34 ：

あれは半分Smalltalkだ。

35 ：

対抗してBigMouth

36 ：

前スレまとめ
11 ：仕様書無しさん [↓] ：2013/03/10(日) 16:43:56.60
短いコードであってもパッと見て意味がわからないのなら
関数（メソッド）を作れ。
コメントを書くぐらいなら
適切な名前の関数を作ったほうが良い。
例えば、正規表現を書くよりも、その正規表現で
やりたいことを意味する関数を作ったほうがいい。

12 ：仕様書無しさん [↓] ：2013/03/10(日) 16:47:33.91
動的型付け言語なら高機能なテキストエディタを使え
静的型付け言語ならIDEを使え。
なぜなら、動的型付け言語ではIDEのサポートが十分に得られない。重いだけ。
静的型付け言語はコード自体は冗長になるが、IDEのサポートで大幅に生産性が上がる。

13 ：仕様書無しさん [↓] ：2013/03/10(日) 16:49:32.42
人力テストは極力なくせ。
人力テストとは、ブラウザを開いてフォームに値を入れてクリックするとか
アプリを起動してメニューを選んでクリックするとか、
出力ファイルを眺めておかしい所がないかチェックするとか、
そういうことを人間が毎回操作してテストすることだ。

37 ：

14 ：仕様書無しさん [↓] ：2013/03/10(日) 16:53:02.79
理由が書いてない（納得出来ない）
コーディング規約はゴミだ。作るな。従うな。
初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。
糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。
15 ：仕様書無しさん [↓] ：2013/03/10(日) 16:55:11.95
コードは書くことよりも、読む時のことを考えろ。
短く書いたとしても、読みにくければそれは駄目なコードだ。
コーディングにかける時間の8割は、コードを読むことに使わている。
18 ：仕様書無しさん [↓] ：2013/03/10(日) 17:01:08.92
循環的複雑度。これを早い段階で計測できるようにしろ。
客観的にコードの汚さ、目安が計測できる。
これは各言語ごとにツールが有るはずだ。
19 ：仕様書無しさん [↓] ：2013/03/10(日) 17:05:02.98
警告は有効にし、警告レベルは最大にしろ。
エラーはログに表示させ、そのログを見ることを覚えろ。
場合によっては、それができる仕組みを作れ。
あれ？ なぜか動かない？原因がよくわからない。などという時
実はちゃんと設定やコードを書けば、起きてるエラーが取得できる事が多い。
余談だが、データベースの設定に警告レベルがあったりもする。

38 ：

860+1 ：仕様書無しさん [↓] ：2013/04/06(土) 10:28:35.30
1. ifとforを多用したコードを書くのはやめよう。よく使う処理は既に汎用的なものがないか調べよう。
　判定や繰り返しは別の解決法がないかを考えよう。
　ただし再帰はバグの温床だから、ループの変わりに使うのだけは気をつけて。
2. 重複コードを書くのはやめよう。
　同じような処理をする場合共通化を図ろう。
　最初から完璧に共通化を図る必要はないが、汎用的に使える処理かは常に検討しながら書こう。
3. 重複コードを減らすためにリファクタリングは必ずやろう。
　ちなみに、リファクタリングは多少時間を置いてから見たほうが捗ることもある。
　実装直後だと、まだ覚えてるから簡単に読み解ける処理がある。
　後からみても仕様がすぐ頭に入るようなコードを心がけておくと、後の修正量が少なくてすむよ。
4. リファクタリングのために単体テストの設計、実装はやろう。
　単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。
動いてるコードを修正するなっていう老害が多い業界だけど、
UTがきちんと実装できていない、書いたコードは読み直せないほど汚いってのが理由だから、
これからコード書く人は、同じ轍は踏まないように、そういった馬鹿発言が飛び出すことのないようなコードを書けるようになろう。

39 ：

循環的複雑度ってやつ気になる
やってみよ

40 ：

これ、ちょっと極端な部分も多いけど、なかなかよかった
ttp://www.slideshare.net/MoriharuOhzu/ss-14083300
実務だと色々な制約からもう少し大きいクラスになりがちだけど。

41 ：

>>15
俺ならその判定処理をメソッドにして、代入ではなくreturnするな。

42 ：

>>40
内容もだけどスライドのセンスが素晴らしい...

43 ：

>>40
1クラス状態変数2つまでってのは守れそうもないわｗ

44 ：

スライドは綺麗だけど、内容はコピペじゃね？

45 ：

処理が長くなったからと言って、無闇に関数化するのは問題があるだろう。
関数分割の基本は変数に着目し、
そのスコープか最小になるように分割する事だか、
分割した関数の引数が多くなってしまっては、
スコープかが小さくなったとは言えない。
通常はあくまでも基本を優先すべきだろう。

46 ：

JUnitのような物は注意がひつようだ。
本当に単体試験の代わりに使うと、開発コストが3倍になる。
あれは機能変更後のデグレ確認用の結合試験を自動化しているのを見て、
単体試験をしていないどこかのバカが、単体試験用に適用した物だ。
もし使えと要求があらなら、単体試験は通常に実施し、デグレ確認用に軽く作る程度がいいだろう。

47 ：

JUnitはJavaが言語的にウンコすぎて
超絶的に使いにくく冗長になってるんだよね
SmalltalkのSUnitから輸入したけど、JavaはSmalltalkじゃないから
だからxUnitは悪くない。悪いのはウンコすぎるJava

48 ：

コーディング規約は仕様だ。
納得いかなければ、コーディング規約を変更すべきである。
変更出来なけれは従うしかない。
勝手に無視して作り直しを要求されても、文句は言えない。

49 ：

>>40
いいねこれ、特に次の二つ。
・省略したいほど長い名前がつく原因を考える
・複雑度 １０ まで
実業務でも数％程度の例外を除けば、十分達成出来る目標だ。

50 ：

>>40
いやあ、見応えあった
凄いね
紹介ありがとう

51 ：

>40
それまさに今日業務中にみたスライドだ
神クラスで検索したら出てきた

52 ：

単体試験を行う上で最低でも3種類の試験が必要になる。
1.ルート試験：全ての分岐、繰り返しに想定した条件で入るか確認する。
2.入出力試験：想定した条件の時、リターン値、出力パラメータ、データベース等に想定した値が出力されるか確認する。
3.メッセージ、ログ試験：画面、ログ等に出力されたメッセージが正しいか確認する。また、ログに不要なメッセージが出力されていないか確認する。
重要度は記載順だか、たまに2しか実施しない者がいる。
最近はさらに2すら実施しない者がいる。

53 ：

カチカチの命令型脳だなw

54 ：

JUnitは基本的に2を自動化するツールで、
簡単に1を試験出来ない以上、
中途半端と言わざるを得ない。
まあ、単体試験を実施しない人が使えば、
何もしないよりはマシだが。

55 ：

JUnitみたいな劣化コピーを基準にして何がうれしいのだろう？

56 ：

>>55
SUnitはルート試験を簡単に出来るのか？

57 ：

>>52
1.2.の違いが分かんねー
2って全部の結果を試すことじゃないの？

58 ：

>>57
一般的なソフトウェア工学の用語に当てはめれば，
　1.ルート試験がホワイトボックス試験で、
　2.入出力試験がブラックボックス試験
ではないかと思われ

59 ：

xUnitを使わないで単体テストしてる人ってどうやってるのか興味ある。
今まで聞いたのは、IDEでステップ実行してますとかで話にならない。
UIがない場合はコードで呼び出す必要があるんだが、だったら例外を発生するテストができたり、管理機能があったり、結果出力機能があったり、豊富なアサーションが用意されてるxUnitを使うのがいいと思うんだけど。

60 ：

>>58
なるほど、納得です！

61 ：

>>59
デバッガでステップ実行だ。
それ以前にルート試験の試験項目表を手動で作る。
これが重要で、この時に半分以上のバグが取れる。

62 ：

>>61
それ、バグ修正したりリファクタリングしたらまたやり直すの？
仕様変更があったら、また項目表から作り直す？
それと、テストがOKだったかどうかの確認はどうやるの？

63 ：

ステップ実行するにしても、xUnitでテストコード書いてから実行した方が楽だと思うんだけど、どうかな。

64 ：

皆さんがxUnitの入門に使われた文献を知りたいです

65 ：

xUnixに見えて仕方が無い。

66 ：

『JUnitでテストしています!』　の実態が、
JUnitをランチャーがわりにステップ実行し、
結果を目視確認することだった時の衝撃は大きかった。

67 ：

>>66
あるあるｗｗｗｗｗｗｗ


あるある・・・
いくら提案しても頭の硬いジジイどもが
最終的には人間がその目で確認しないとダメだとか抜かしやがる畜生め

68 ：

>>67
人間がｗその目でｗｗヒューマンエラーｗｗｗ

69 ：

そんな人はさすがに見たことないが、IN/OUTデータをハードコードする人多すぎる
お願いだから外部リソースにしてくれ

70 ：

>>69
どういうこと？
ハードコードするから良いんだと思ってるけど。

71 ：

xUnitは各コードが単独で完結していることが大事。
当然データはハードコードするべきだな。

72 ：

おじゃばはじゃば名乗ってる割に未だにじゃばに向いてない考え方通してるよな

73 ：

仕様書をハードコードしたのがテストコードだと思うよ
仕様が変わったらテストも変わる

74 ：

>>59
Web系だと、単体とか言いながら結合して画面ポチポチして単体テストしました！とか未だに言ってる職場多いよ
猿かよ

75 ：

>>45
どこに向けたレスかわからんので気になったんだけど、「無闇な関数化」ってどこに向かって言ってるの？
そういう話題が出てきた箇所はないような気がするんだけど、単なる主張？

76 ：

>>62
バグ修正はバグ票で修正確認まで対応。
修正が多い場合や仕様変更は、修正箇所分のみ試験仕様書を新規作成。
基本的に単体試験仕様書は使い捨てで、変更があった場合は追加する。
そうしないと進捗管理が困難になる。
テストのOKは目視で確認。

77 ：

JUnitがホワイトボックスに使えないわけないよ。
ケース作成が大変だっていうなら、それはテスト対象のメソッドが冗長すぎるだけだと思う。
IOしかみないブラックボックステストを後付けで作るならそうなるんだろうけど、別にそれだけしかできないツールじゃなかろう。
なんとかと鋏は、みたいな話。

78 ：

>>64
Javaがメインのプログラマだけど、
JUnitでぐぐっていくつか拾い読みしたくらいだ。
あとは使ってみて、自分なりに効率よくテストできる方法を構築してく感じ。
参考にならなくてスマソ

79 ：

ここも結構よかった
http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf/view
がちがちにTDDする必要はないと思うけど、
テスティングペアを使ってメソッド単位で動確とりながら実装するのは品質上がるから
これからコード書く人にもお勧め

80 ：

>>63
66の言うように紛らわしくなるから止めた方がいいだろう。
>>68
JUnit使っても1回目はヒューマンエラーは起きる。
起きないのは同コードの2回目以降。
>>72
俺はJUnitの犠牲者だ。
俗に言う人柱だな。
>>74
確かに多い。
つーか、試験仕様書書かずに試験完了って何だよ。

81 ：

>>78
自分もそんな感じ
あとは実際に使われてるソースみたりとか、くらい
っていうかネットで何でも調べれる今日日、技術書買う必要性感じてないな
技術書を否定するわけじゃないけど、本は閉じられた情報だから、
間違いや過去の情報が更新されることもないってデメリットもあるしね
あと本買うとそれで満足しちゃいそうだからってのもあって、自分はめったに技術書自体を買ってない
英語苦手だから英語サイトにしか情報がないとしんどいけど、
技術系文章なら用語が多いから機械翻訳でも割と何とかなるぜ

82 ：

>>75
40のスライドとか、一文字変数の所で、行数が多いなら分割しろと出てた。

83 ：

>>82
なる
確かに意味のない単位での分割はダメだと思う
だけど、さすがにそんな単位で分割する人はいないと思うし、書き忘れなだけな気はする
20行ずつとか適当な単位でメソッド分けて
処理1();
処理2();
処理3();
とかやられてたらブチきれかねない

84 ：

>>80
たしかにJUnitでもヒューマンエラーは起きる
テストの方の数字間違えてたりするし

85 ：

>>45
そうじゃなくて、冗長になるような実装そのものがおかしいってこと。
そもそもそういう「大きな」処理が出てきた時点で
処理全体の捉え方がオブジェクト間の連携じゃなくて
手続き中心になってんじゃないの、って話な。

86 ：

GUIのテストってどーすんの
マウス動作の自動化ツールとか使うんか

87 ：

>>77
ホワイトボックスに使うとひどい目にあう。
だから使う時は、結合試験のデグレ確認用に使っている。
>>79
これからコードを書く人にはお勧めできない。
まず基本のルート試験（ホワイトボックス試験）、入出力試験（ブラックボックス試験）を、
試験項目表を書いて実施するのを覚えて欲しい。
大手企業なら通常は単体試験実施要項と言う資料があり、
最低でも上記2種は行う事になっているだろう。
ただ、結構無視して以前の試験項目表をサンプルにして実施される事も多いが、
一度は目を通しておいても損はないだろう。

88 ：

>>85
前にも書いたが、入力チェックや、項目の多いDBテーブルの登録更新処理、帳票出力処理などは、長くなる事が多い。

89 ：

>>88
入力チェックがアホみたいに長くなるのは
全部の項目を一括してチェックしてるからだろ

90 ：

内部処理用のメソッドのテストを対象にしてxUnit使ってるからホワイトボックスのほうがコストかからん
むしろブラックボックスにxUnitって、業務系だとテスト対象メソッドの機能が重くなりすぎてテストケースろくに作れんやん

91 ：

>>90
ちなみに、コード修正したらテストコードも修正だよな。

92 ：

老害から悪習を引き継ぐオッサンになってしまったら、いつまで経っても環境は良くならん。
Excelベースの試験仕様書とか作るような全時代の手法は、少しずつでも改善していくべき。
めんどくさい作業を簡単にするための道具は次々に発明されてるんだし、学ぶことを辞めたらマは終わりだと思うわ。
ttp://www2.ocn.ne.jp/~cheerful/develop/waterdev/test_diff_UT_FT.html
A〜E全てのモジュールで全ケース網羅できるテストをJUnitなりで作るのは容易い。
それができないようなら、メソッドなりクラスなりがピザすぎるのが原因だろう。
おじゃばがJUnitを使って作成してるテストケースは、上記サイトでいうとこのXの単体テストを作ろうとしてるんじゃね。
そんなんやったら下の図のようになって自滅もするだろう。
機能テストに単体テストツールを使うのが間違いだったってことだろう。

93 ：

>>91
その質問は、コード修正したらテストするよな？って聞いてるのと同じレベルだと思う

94 ：

>>93
メンテナンスの放棄された大量のテストケースコードがあるのだか、
どうすればいいんだ、これは。

95 ：

おじゃばの言う単体テストって、対象はどの単位で考えてるの？
それと、テストは具体的にはどうやってるの？対象をステップ実行するためには、それ呼び出す何かが必要だよね。
あと、IDEがない言語の場合は単体テストはどうやるの？goとか。

96 ：

そうそう、おじゃばはTEST PRESSとか読む？
NTTDみたいな大手もJUnit使ってるよ。

97 ：

>>92
単体試験ツールが出る度に期待して試すが、デバッガ以降に期待に応えてくれた物はない。
残念ながら現在、俺の知る限りExcelの手書き試験項目表に代わるものはない。
JUnitはガキのオモチャ。

98 ：

テスト設計と管理は別にExcelでやってもいいが、実装でxUnitを避ける意味がわからない

99 ：

11

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【Android】デベロッパーの集うスレPart18 (236)
[徹底的]ﾌﾟﾛｸﾞﾗﾏｰが語るWindows,Linux,Unix[ﾊﾞﾄﾙ] 2 (335)
【Android】デベロッパーの集うスレPart18 (236)
おもしろいコピペがあったら貼るスレinマ板part35 (705)
【Android】デベロッパーの集うスレPart18 (236)
おもしろいコピペがあったら貼るスレinマ板part35 (705)
--log9.info------------------
AS400って何？？ (298)
何でもかんでもExcelで資料作る奴 (774)
★★★　弥生人事給与　★★★ (437)
軽い表計算ソフト (238)
MicrosoftOfficeXP承認制限外し (590)
生産管理ソフトはどうしています？ (415)
表つくるならWord と Excel　どっち使う？ (357)
OutlookExpress (468)
●使用権は著作権法並びに独禁法違反だ！● (809)
本日発売！　Adobe Illustrator10.0 (279)
シェアウェアの金払ってる？ (285)
サイボウズoffice４の使いかってはどうでしょうか？ (712)
ナレッジマネジメントってどうなる？ (208)
■ きれいなテキストファイルの書き方 (210)
ARCserveってどう？ (284)
ATOK15に関するスレッド (546)
--log55.com------------------
(´-ω-｀)のまのまぃぇぃ
Supreme
Supreme
Supreme 12
visvim
体位
■何で女はダウン着てる奴ばかりなの？■
春２００６☆ファッション！？〜高校生〜