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

関数の長さ 上級者10行後、中級者100行前後

1 :仕様書無しさん:2014/10/12(日) 04:11:10.31
初心者、数百行〜数千行

(コメント行、空行、括弧だけの行除く)

これ、だいたいあってる

2 :仕様書無しさん:2014/10/12(日) 05:58:02.93
マジか?初心者が数百行も書けるのか

3 :仕様書無しさん:2014/10/12(日) 06:20:04.68
>>2
時間をかけて少しずつ長くしていくんだよ。
どんどん複雑になって破綻する。

それでも、うんうん唸りながら
長いコードを眺めてるw

4 :仕様書無しさん:2014/10/12(日) 06:24:52.39
初心者なら100行に達する前にプログラミングを諦めそうな気がするがな

5 :仕様書無しさん:2014/10/12(日) 06:38:48.33
>>4
それは初心者未満だね。

6 :仕様書無しさん:2014/10/12(日) 06:42:48.08
こんな話が出るってことは、OOでも地獄は変わってないのか

7 :仕様書無しさん:2014/10/12(日) 06:59:32.98
そりゃ変わるわけ無いだろ。

OOっていうのは上級者が使ってこそ便利な道具で
初心者はその便利な機能を使いこなせない。

8 :仕様書無しさん:2014/10/12(日) 08:14:14.85
結局はgoto大量ソースの保守を経験して、構造化プログラミングの有り難味を知り、
グローバル変数の害を知り・・・とやってかないと理解できないんだろう、この手のバカは

9 :仕様書無しさん:2014/10/12(日) 09:54:18.85
 かなりOOを極めないと10行ぐらいにはならない感じ。
で、相当優秀な人でもOOをマスターしている人はそんなにいない(言語やジャンルによる?)
ちなみにJDKやAndroidのソースコードもメソッド200行とかあるよ。

10 :仕様書無しさん:2014/10/12(日) 10:47:57.90
そら、別に1つ2つ極端に長いのがあっても不思議ではないでしょ

大量の条件分岐があったりとか嫌でも長くなる。
でも最低処理単位がそれならば仕方がないこと。

11 :仕様書無しさん:2014/10/12(日) 16:32:17.68
>>10
> 大量の条件分岐があったりとか

大量の条件分岐が発生する場合で、
関数テーブルに置き換えられないことなんてないでしょ。

12 :仕様書無しさん:2014/10/12(日) 17:19:43.33
コード記述の話題は一般化し過ぎる傾向にあるよね。
目的と状況に応じた長さ、粒度に設計できるのが中級者だべ

13 :仕様書無しさん:2014/10/12(日) 17:59:06.68
コードの長さっていうか複雑度のほうが重要かな。

長くても条件分岐やループがなければ全然構わない。
処理が上から下に流れただけだから。

大量の条件分岐などがはいるとだめ。

14 :仕様書無しさん:2014/10/12(日) 20:58:34.22
>>13
しかも条件が相互に絡み合うケースは最悪ね
ま、これが大体業務系では現れるわけだがw

15 :仕様書無しさん:2014/10/12(日) 21:03:10.54
>>14
作ってる本人が、そういう書き方しかできないと思い込んでるのか
シンプルに書くことができない。

なんでなんだろうな。

動くコードを書くことで、いっぱいおっぱいか?

16 :仕様書無しさん:2014/10/13(月) 01:32:13.59
>>15
プログラムに対する哲学や美的センスがなく、コーディング規約という名の糞宗教を頑なに信仰しているから。

17 :仕様書無しさん:2014/10/13(月) 02:02:33.20
初心者はこういうかんじ
http://ideone.com/P06RoT

18 :仕様書無しさん:2014/10/13(月) 02:16:29.52
>>17
ひどすぎワロタw

まず読む前に改行を直すな。

19 :仕様書無しさん:2014/10/13(月) 02:56:21.69
改行を直すだけで、コードが半分以下になるなw

20 :仕様書無しさん:2014/10/13(月) 08:31:52.59
>>17
だれに習ったんだろう?
この改行センスはw

でも、ifも深いわぁ・・・俺の知っているプログラムで最高の深度は23w
肯定ifしか書けない人だったわぁ・・・
否定で考えればスッキリするのに・・・。。

21 :仕様書無しさん:2014/10/13(月) 14:38:33.43
>>4
それ初心者にすらなれなかった人だろ

>>17
とてつもない個性的なコードだな
ある意味一貫していて美しい
しかし、とんでもなく読みにくい

>>20
深度23・・・凄すぎる
俺はifの深度が3になると気分悪くなるから最悪でも2に抑えたい

22 :仕様書無しさん:2014/10/13(月) 15:03:07.54
正しい形になっているか、というチェックでやろうとすると深くなるんだよな
全体から正しくない形を除いて行って、残ったのは正しい形というチェック方法にするだけで、浅く。しかも漏れなく作れるのに。

23 :仕様書無しさん:2014/10/13(月) 17:00:52.70
>>22
おれは、複雑なやつはそのロジックだな。
ちなみに勝手にその手法を「フィルタif」と呼んでいるww

24 :仕様書無しさん:2014/10/13(月) 17:46:50.02
速度を優先する場合、500行くらいになることない?

25 :仕様書無しさん:2014/10/13(月) 17:51:51.49
>>24
ない。

それは速度を優先してる気になっているだけのコードだろう。
つまりベンチマーク(比較)すらしてない。

26 :仕様書無しさん:2014/10/13(月) 18:03:41.79
>>22
業務系保守やってるから激しく同意。
あと、やたら同じような条件分岐があるような処理とかは、分岐したい状態を前提に持ったクラス設計にしてればインスタンス生成のタイミングに集約できることもしばしば

27 :仕様書無しさん:2014/10/13(月) 18:15:03.82
お前らみんな頭良さそう

28 :仕様書無しさん:2014/10/13(月) 22:29:05.70
無名クラス使いまくると破綻するよソレ

29 :仕様書無しさん:2014/10/13(月) 22:39:53.78
無名クラス、無名関数は、その場限りでは便利そうだが、保守性は低そう

30 :仕様書無しさん:2014/10/13(月) 22:40:18.83
○ 無名クラス使いまくると破綻するよ、馬鹿がやると

まあ、馬鹿がやれば何使っても
破綻してますわw

31 :仕様書無しさん:2014/10/13(月) 22:40:55.55
>>29
お前が、使い方をしらんだけ。

32 :仕様書無しさん:2014/10/13(月) 22:45:54.66
Java8のラムダなんて使い方わからんし

33 :仕様書無しさん:2014/10/13(月) 22:47:20.91
わからんで終わってるあたりが無能っぽい

34 :仕様書無しさん:2014/10/13(月) 22:48:37.69
わからんのは難しいということ
難しい物は、だめ。
シンプルに使えない道具は役に立たない。
スイッチひとつで飛行機も空を飛ぶ

35 :仕様書無しさん:2014/10/13(月) 22:51:25.02
ゆとりは我慢することを知らない。
すぐに道具に頼ろうとする。

プロはつまらない仕事でも同じことをずっと繰り返しできる。
ループなんか使わない。同じことを間違わずに何十回
何百回、何千回と繰り返せるのがプロ。

LSIに半田付けをする職人を見習え

36 :仕様書無しさん:2014/10/13(月) 22:52:53.87
何の分野でも何の業界でも一部の有能しか扱えないものなんて一部の有能しか使ってないやろ
世の中、何の分野でも何の業界でも無能が8割以上で構成されてんだから

37 :仕様書無しさん:2014/10/13(月) 22:53:46.89
パイロットも自分で運転できないのが8割なんだぞ。

38 :仕様書無しさん:2014/10/13(月) 22:56:39.96
お前らみんな有能そう

39 :仕様書無しさん:2014/10/13(月) 22:57:02.96
>>34
ラムダ式に関しては食わず嫌いじゃないかな
どう考えてもラムダ式の方がシンプルだよ

List<Integer> list = new ArrayList<>();

// 無名内部クラス
list.sort(new Comparator<Integer>() {
 @Override
 public int compare(Integer a, Integer b) {
  return a.compareTo(b);
 }
});

// ラムダ式
list.sort((a, b) -> {
 return a.compareTo(b);
});

40 :仕様書無しさん:2014/10/13(月) 22:59:13.98
>>39
複雑じゃないか。

そんな機能を学習する時間のほうがかかる。

41 :仕様書無しさん:2014/10/13(月) 22:59:59.62
>>40
じゃあしょうがない

42 :仕様書無しさん:2014/10/13(月) 23:00:53.19
面白いのが客先に開発メンバー全員で挨拶に行くとき。

ここにいるのが熟練したプロの技術者ですって
紹介するんだが、実際はプログラムできない奴が8割www

43 :仕様書無しさん:2014/10/13(月) 23:01:27.90
開発メンバーの8割が無能って事実は
客には言えないなwww

44 :仕様書無しさん:2014/10/13(月) 23:01:53.74
ラムダ式のaとbのクラスはListのジェネリクスに従うのか?

45 :仕様書無しさん:2014/10/13(月) 23:02:23.12
>>43
客の会社も8割が無能だから

46 :仕様書無しさん:2014/10/13(月) 23:03:18.63
体感的にまともなコンビニ店員とか1割もいない気がするが

47 :仕様書無しさん:2014/10/13(月) 23:04:09.64
類は友を呼ぶってやつだな。

48 :仕様書無しさん:2014/10/13(月) 23:06:52.79
数列・行列、逆・裏・対偶、集合のキソ概念を一切使わず
ひたすらIF文を言われるがままベタ打ちする40代のオヤヂ
を想像して寒気がした

49 :仕様書無しさん:2014/10/13(月) 23:09:16.44
40代って独学の時代の世代?

50 :仕様書無しさん:2014/10/13(月) 23:10:42.97
ネットが普及した今は簡単に色々調べられるけど
ネット普及前のプログラミング世代は大変だったろうな

51 :仕様書無しさん:2014/10/14(火) 02:47:31.21
>>44
見てくださいこれが世に言われる無能です。

52 :仕様書無しさん:2014/10/14(火) 22:38:46.67
【速報/プロレス】長州力 自己破産していたかも 負債総額4億円 [東スポweb]
http://kanae.2ch.net/test/read.cgi/wr%65s/1409028427/

53 :仕様書無しさん:2014/10/15(水) 04:20:18.53
10行後なんなの

54 :仕様書無しさん:2014/10/15(水) 04:51:46.16
爆発する

55 :仕様書無しさん:2014/10/16(木) 19:56:35.60
>>48
業界によるけども
リフレクション使いまくれてスタックトレース見ないと呼び出し元分からないようなものを作られると困る(立場なんで)
3ヶ月後に作った本人が分かってりゃいいが

56 :仕様書無しさん:2014/10/17(金) 00:14:06.87
>>17

http://ideone.com/wfU0tA

57 :仕様書無しさん:2014/10/18(土) 00:15:16.26
ひねりが足らんな

58 :仕様書無しさん:2014/10/18(土) 10:29:06.61
ひねれないのは初心者
ひねって有害なのは中級者
ひねって有益なのは上級者

59 :仕様書無しさん:2014/10/18(土) 15:10:14.85
>>56
C言語をdefineで別の言語風に仕立て上げてて笑った
それはCOBOL風なのかな?

60 :仕様書無しさん:2014/10/18(土) 23:13:05.55
普段からメソッドを短くするぞ!するぞ!って特別意識はしないなぁ
xUnit系でtestableなコードを意識すると自然と短くなるって感じ
あと、メソッドの役割そのものズバリの命名をつけるようすると、
自然とシンプルになるって感じ

61 :仕様書無しさん:2014/10/18(土) 23:17:37.85
しまった
「命名をつける」って何か変だw

62 :仕様書無しさん:2014/10/18(土) 23:26:27.18
オブジェクティブ思考でやればよろし

63 :仕様書無しさん:2014/10/19(日) 11:37:33.77
>>17を最低限インデントと改行、悪魔のstd省略とかだけ直した
改行は宗教的色合いが濃そうだ
http://ideone.com/Q8pLau

64 :仕様書無しさん:2014/10/19(日) 11:58:40.99
関数の長さじゃー行数か関数名かわかんねーだろ、この初心者が!!
関数の行数と言え

65 :仕様書無しさん:2014/10/19(日) 12:02:21.52
いやいや関数名100行前後とかだったら
萎えるわwww

66 :仕様書無しさん:2014/10/19(日) 15:38:55.93
あんなもん適当なフォーマッタにぶっこめば一発で直るやろ

67 :仕様書無しさん:2014/10/27(月) 07:14:46.13
switch文がめちゃくちゃ長くて
コンパイラがバグったの見たことある

68 :仕様書無しさん:2014/10/30(木) 07:43:17.89
2000行くらいcase文書いた初心者見たときはある意味すげーと思った

69 :仕様書無しさん:2014/10/30(木) 09:14:24.20
caseって規格上は上限があったような気がする
gccではいくつ書いても平気だった、みたいな実験結果をみたような

70 :仕様書無しさん:2014/10/30(木) 22:55:35.26
>>68
我慢強い奴はプログラマーに向いてないよな

71 :仕様書無しさん:2014/10/30(木) 23:11:57.02
いかに楽して作るか、いかに楽して目的を達成するか、
何の業種・職種においても要領の良さってのは大事

72 :仕様書無しさん:2014/10/31(金) 01:18:33.64
ファイルの行数ってどのくらいまで許されるのかな。
うちのばあい7000行とかざらにあるけど。 ちなみに、C言語です。

73 :仕様書無しさん:2014/10/31(金) 01:20:10.00
エディタなりIDEなりがうまく見やすく表示してくれりゃ行数なんて問題ないんじゃねえの?

74 :仕様書無しさん:2014/10/31(金) 09:08:14.02
Cだと関数が300行ほどあってちとなげーなと思ったら、途中に何カ所もincludeがあるのをメンテしたことが。

75 :仕様書無しさん:2014/11/01(土) 12:54:26.62
循環的複雑度
上級者、10未満
中級者、数十
初心者、数百

76 :仕様書無しさん:2014/11/02(日) 23:58:14.70
>>70 コード以外のドキュメント書かせても誰も読まないと思う。

77 :仕様書無しさん:2014/11/12(水) 04:19:49.01
>>75
わかる…

78 :仕様書無しさん:2014/11/16(日) 15:37:26.12
オブジェクト指向エクササイズは毛嫌いせずにやった方がいいな。

79 :仕様書無しさん:2014/11/16(日) 23:10:26.77
>>78
あんなのやらないとコツつかめない時点で適性ない

80 :仕様書無しさん:2014/11/17(月) 00:21:01.08
>>79
何やればコツをつかめる?

81 :仕様書無しさん:2014/11/17(月) 00:28:31.07
http://d.hatena.ne.jp/asakichy/20090612/1244769857

これか、筆者が実際のプロジェクトにも使ってるというけど、何を作るか次第だよな

82 :仕様書無しさん:2014/11/17(月) 00:46:17.79
>>81
 業界で有名な方々のBlogや記事をいろいろ読んだけど、オブジェクト指向に習熟していくと自然
とそういう書き方になるみたいね。俺も最近そういう書き方になってきている。

 後、クラス分割の粒度が細かくなると、ソースコードは自然とオブジェクト間のメッセージ
パッシングを表現するようになるからな。

83 :仕様書無しさん:2014/11/17(月) 01:05:59.61
>>81
ルール1〜5はオブジェクト指向と関係なくね?

84 :仕様書無しさん:2014/11/17(月) 01:10:47.08
> インスタンス変数は2つまで

Map<String, Object> hensuu

hensuu.get("value1")
hensuu.get("value2")
hensuu.get("value3")

とかやれば
1変数で複数の値が持てるし簡単に突破できるな

85 :仕様書無しさん:2014/11/17(月) 01:15:26.50
目的が変わってしまっているじゃないかw

86 :仕様書無しさん:2014/11/17(月) 01:25:39.72
http://www.oreilly.co.jp/books/9784873113890/

この本だな
サンプルコードはロハでゲットできるのか

87 :仕様書無しさん:2014/11/17(月) 01:28:34.99
> 1 行につきドットは1 つまでにすること

これも一時変数量産するだけで突破できちゃうな


こりゃちゃんと本に書いてある解説を読まず
このルール項目だけを見てエクササイズするととんでもないことになりそうだな

88 :仕様書無しさん:2014/11/17(月) 01:33:20.02
50行までってのも
改行文字が空白文字同等の言語だと複数行を1行に並べるだけにするとかしたり

89 :仕様書無しさん:2014/11/17(月) 01:42:31.73
オブジェクト指向うんぬんってより
ただ単に読みやすいコードの書き方の指南って感じじゃね

オブジェクト指向は実コーディングではなく設計思想だと思うのだが

90 :仕様書無しさん:2014/11/17(月) 02:01:19.60
>>84
ゲッターとコレクションクラスを直接使うのは禁止項目になっている。

>>87
リファクタリングもそうだけど、原本の趣旨を理解せずに行うととんでもないことになるな。

91 :仕様書無しさん:2014/11/17(月) 02:06:12.25
JavaScriptならどんなコードも1行にできるしな
これで上級者の仲間入りだ

92 :仕様書無しさん:2014/11/17(月) 02:14:04.01
それを言ったらSmalltalkは。。。

93 :仕様書無しさん:2014/11/17(月) 04:49:08.64
>>81 >>86
GJ

これ面白いね

既に会得してるものだと、読んでる最中に「あ〜これ、知らない間に俺やってるわw」ってなる
また、その概念に名前付けして整理できるからなお嬉しい

非言語依存なのもいい

原書読んでみようかしら

94 :仕様書無しさん:2014/11/17(月) 07:03:56.28
>>89
 データ変換を行うプログラムにこれを適用するには辛いかな。
逆にいうそれ以外は、いろいろ勉強すれば、この形に自然に準
拠するように書けるようになる。

95 :仕様書無しさん:2014/11/17(月) 07:05:36.69
>>89
>>81

96 :仕様書無しさん:2014/11/17(月) 09:15:48.90
>>92
参考までに調べてみた。

Smalltalk(の特に、VisualWorks とか Squeak/Pharo などの Smalltalk-80 直系子孫)は
35年近く蓄積されたコードで動いているんだけど、メソッドの多くは実際に短く書かれていて
たとえば、手元の Pharo Smalltalk http://pharo.org/ の最新リリース
(のIDEを記述した全ソース)について集計した場合、

(CompiledMethod allInstances collect: [:method | method getSource lineCount]) average asFloat
"=> 7.12162415603901 "

…とコメントを込みでも平均で7行程度しかなかった。

97 :仕様書無しさん:2014/11/18(火) 00:05:18.46
>>81
このエクササイズ程、やった事ない人とやった人の間で評価がわかるものはないな。
前者はいろいろdisりまくり、後者は2度と以前のやり方に戻れないと言う。

98 :仕様書無しさん:2014/11/18(火) 01:26:01.93
とりあえずc#には適用できないな。
形式上の問題だろうが、linqが使えないwww

99 :仕様書無しさん:2014/11/18(火) 03:33:32.86
>>81やると階層深いところを修正するのめんどくさそうな気がするな
単純な関数やクラスを何個もたどることになって、開いたタブが何個も・・・
さっき開いてたクラスの前に修正してたのどのファイルだったっけってなりそう。
仕様が固まってるシステムなら良さそうだけど。

100 :仕様書無しさん:2014/11/18(火) 06:49:27.52
else禁止ってエラー処理はどうすんの?

101 :仕様書無しさん:2014/11/18(火) 07:12:15.81
if{}の外がelseってことでしょ。そこに例外でも処理でもかけばいいんでない?

102 :仕様書無しさん:2014/11/18(火) 07:19:39.10
>>99
 他のIDEはしらんけど、Xcodeならフィルターや検索窓からクラス名やメソッド名で絞り込めば余裕。
ただし、オブジェクト指向設計ができてないとそのクラス名やメソッド名すら思いつかない。

 むしろ仕様が固まってない、途中で何度も修正が入るシステムこそ、このやり方を進めたい。
頭の使い方が根本的に変わるというか。完全なオブジェクト脳になるな。

もちろん、9のルールに厳密に従うわけじゃない。

103 :仕様書無しさん:2014/11/18(火) 18:04:43.60
>>102
深い階層のメソッドなんて隠蔽されてるから予想のしようがなくね?
順番にたどっていくならeclipseもCtrl+クリックで簡単に開けるけど、
そもそもこのやり方に従っていなかったらその場でソースが見れるわけで・・・

一度に把握するソース量が少ないからバグが起きにくいんだろうけど、
一度に把握する量が少なすぎて効率悪そうな感じがするけど、そこらへんどうでしょう?

104 :仕様書無しさん:2014/11/18(火) 20:23:27.11
じゃあそのエクササイズ成果でオブジェクト指向で2chブラウザ作れば2chの仕様変更にも即座対応できるようになるか

105 :仕様書無しさん:2014/11/18(火) 21:59:55.78
>>99
最近はIDEやエディタの拡張機能として"go to everything"的な
モノが大抵あるから、困らないような気がする

106 :仕様書無しさん:2014/11/18(火) 23:19:10.54
APIとかフレームワークに値渡す時ってどうしてもgetter必要になっちゃうんだけど、うまいやり方あるの?

自前のオブジェクトまる渡ししても、フレームワーク側で処理できるわけじゃないし...

setterはなくても全然問題ないね

107 :仕様書無しさん:2014/11/18(火) 23:49:39.36
>>106
 フレームワーク側のオブジェクトを引数にとるメソッドを定義して、その中でインスタ
ンス変数を直接渡せばgetterを使わなく済むな。レイヤー階層は崩れるけど。
 言語によってはメソッド拡張を使えばレイヤーは揃えられる。

108 :仕様書無しさん:2014/11/18(火) 23:57:30.14
APIやフレームワークをラッパーするオブジェクトを作ればよい

109 :仕様書無しさん:2014/11/19(水) 00:42:01.03
医療プログラマーが超高難易度の免許制に / フリーソフトやオープンソースの無作為配布も全面禁止
http://fox.2ch.net/test/read.cgi/poverty/1416286592/

110 :仕様書無しさん:2014/11/19(水) 06:55:13.05
>>107
その手があったかありがとう

不必要にAPI側知ることになっちゃうから、現実だとその辺はトレードオフなのかな

確かに、そもそも既存のクラスオープンできたりダックタイピングな言語ならスムーズにできますね

111 :仕様書無しさん:2014/11/19(水) 06:57:17.97
>>108
それだと、ラップしたクラスの中で結局getter使わないといけなくない?

112 :仕様書無しさん:2014/11/19(水) 07:22:18.36
>>110
仲介クラスを作って、そこに仕事をさせるというやり方もある。エクササイズ
から外れるが。その辺はいろいろネットで調べればいろんな流派のやり方が出
てくる。

113 :仕様書無しさん:2014/11/19(水) 14:04:06.56
他者の作ったライブラリやフレームワークにまでエクササイズの考え方を強制することは出来んからな
難しい問題だ

114 :仕様書無しさん:2014/11/19(水) 14:29:06.76
エクササイズの意味もわからないバカばかり

115 :仕様書無しさん:2014/11/19(水) 14:36:01.63
2chは上級者のフリをした初級者ばかり

116 :仕様書無しさん:2014/11/19(水) 18:08:17.53
他人の作った粉々のメソッド見る気にならん

117 :仕様書無しさん:2014/11/20(木) 09:25:35.81
>>115
じゃあお手本見せて

118 :仕様書無しさん:2014/11/22(土) 13:44:45.24
こういうスレがあったんやな。関数=メソッドの長さはクラス構成と密接に関わるしな。

http://kanae.2ch.net/test/read.cgi/prog/1351405185/l50

119 :仕様書無しさん:2014/11/24(月) 19:16:46.70
Rubyには一関数5行って規約があったりもする

120 :仕様書無しさん:2014/11/24(月) 19:42:57.54
mjd?

121 :仕様書無しさん:2014/11/25(火) 00:36:29.35
とか言ってどこの規約かわすれた...
けど、一番一般的だろうスタイルチェッカーのrubocopのデフォルトは10行ですます

122 :仕様書無しさん:2015/04/03(金) 06:56:01.67
>>37
いやまて、だめだろそれは

123 :仕様書無しさん:2015/04/03(金) 12:32:52.09
なんちゃって上級者は関数は短い方がいいなどといい、switchで済むものもなんでもかんでも別オブジェクトにしてしまったり、脳みそに欠陥がある

124 :仕様書無しさん:2015/04/03(金) 12:39:22.00
「オブジェクトにすると分岐がなくなります」←は?

…って思ってる人なんか?

125 :仕様書無しさん:2015/04/04(土) 23:07:35.40
>>123
長くてもいいのだけど

何やってるのかバカでもわかるくらいに
簡単にして
難しい内部の挙動は外部モジュールに
押し込めて欲しい

126 :仕様書無しさん:2015/04/05(日) 00:18:57.28
>>119
> Rubyには一関数5行って規約があったりもする

自分のこと頭がいいと思ってる馬鹿は
そういう規約つくるよね。

127 :仕様書無しさん:2015/04/05(日) 00:25:42.17
行数じゃなくて、複雑度、
具体的に言えば、ifやループなんかの
数を制限した方がいいだろうな。
ツールを使わないと数えるのが面倒になるけど。

128 :仕様書無しさん:2015/04/05(日) 10:02:03.77
改行しなければいいやん

129 :仕様書無しさん:2015/04/23(木) 00:43:58.09
どんどん分割して短くしていくっていうのはプログラミングの理想ではあるけど、クラスやメソッドの名前付けが下手な人がやるとすごい残念なことになる
まあ俺のことだけど\(^o^)/

というかエクササイズ何度かトライしてみたけど毎回パッケージ名どうすりゃいいんだろってとこで詰まる
閉鎖性共通の原則とか意識するとどんどんネストが深くなったりするし

130 :仕様書無しさん:2015/04/25(土) 12:24:40.95
ひとつ気づいたことがある。

長い関数を小さな関数に分ける時、
同じファイル(クラス)で分けるのは
だいたいNGである。

131 :仕様書無しさん:2015/04/25(土) 14:24:46.35
関数が長いという理由で、手続きを関数化するのは悪手
c#ならregionとかで囲む

132 :仕様書無しさん:2015/04/25(土) 21:01:42.21
関数って長いと、ローカル変数が増えるから嫌なんだよね
関数全体で有効なローカル変数ってせいぜい2つが限界
多すぎると、俺の頭では処理できない

133 :仕様書無しさん:2015/04/26(日) 00:24:44.71
{}でスコープ定義すりゃいいだけじゃん

134 :仕様書無しさん:2015/04/26(日) 00:27:58.49
>>1
デバッグしろと言われてCのソースを見てるけど、
内容が1行だけの関数ばかり沢山ある。

ほんとに見るのが大変なソースなんだ

これは上級者に見せかけたヘタレのソースだと言いたい!

135 :仕様書無しさん:2015/04/26(日) 09:08:33.31
処理の単位を考慮せずやみくもに関数ばかり増やすのはgoto使ってるのと変わんないもんな

136 :仕様書無しさん:2015/04/26(日) 09:26:39.12
保守する経験があればわかるんだけど、行数が短いのは楽
関数が長くても読めるが、楽かどうかだな

たとえばこの掲示板の300のスレッドなんか平気で、苦にならない、
俺は新着レスの表示、
掲示板に戻る、全部、前100、次100、最新50のところで
全部をクリックして最初から読む。
活字中毒というほどではないが、活字はすきだ

ただ、保守するときの場合だ、関数の短いのが疲れない、
そこが大事だな。

バグを出さない書き方あるという。それは、五時に帰ることだと言う人がいた
へとへとでは、いいコードにならないよ

137 :仕様書無しさん:2015/04/26(日) 10:19:45.95
>>133
関数全体のスコープって前提

138 :仕様書無しさん:2015/04/26(日) 10:24:56.26
行数とかより、関数型的か否かが気になる

139 :仕様書無しさん:2015/04/26(日) 10:41:18.81
>>132
中括弧の使い方勉強しろ

140 :仕様書無しさん:2015/04/26(日) 11:54:08.96
新入社員が先輩社員に何か嬉しそうに話してる構図

「先輩、すごい機能を発見しましたよ! ほら{}の間に変数定義すると・・・」
「あ・・・ああ、すごいな(こいつも成長したな)」

141 :仕様書無しさん:2015/04/26(日) 12:16:14.70
ああそう言うことか

142 :仕様書無しさん:2015/04/26(日) 12:17:47.78
どういうこと?
自作自演してないで説明してよ

143 :仕様書無しさん:2015/04/26(日) 13:37:58.43
この流れでわからんとかどんだけ頭悪いんだ

144 :仕様書無しさん:2015/04/26(日) 14:16:57.43
わかるかわからんかじゃなくて、
説明しろってこと。

説明できないことが
答えになっちゃってるじゃんw
誰もわからない。

145 :仕様書無しさん:2015/04/26(日) 14:43:22.23
あらあら、心に闇を抱えているようですね

146 :仕様書無しさん:2015/04/26(日) 15:04:11.74
{}でスコープ指定できない言語もあるんじゃない?

147 :仕様書無しさん:2015/04/26(日) 15:07:07.88
>>145
それ何が目的のレスなん?

148 :仕様書無しさん:2015/05/01(金) 13:51:04.48
>>144
c言語はローカル変数の宣言は
計算処理の前にないとエラーになるんだよ

でも前後を中括弧でくくると
そこで新しいローカルがはじまるから
まるで途中でローカル変数を
定義できてるように見えるわけだ

中括弧は関数や制御文の区切りという
意味ではなくて
もうすこし汎用的な機能があるってこったね

149 :仕様書無しさん:2015/05/01(金) 22:38:45.90
>>148>>140を具現化してくれました!

150 :仕様書無しさん:2015/05/03(日) 12:45:15.65
>>149
バカにしやがって(´Д`)

151 :仕様書無しさん:2015/05/05(火) 04:39:45.23
ここの人はみんな、保守系底辺派遣PGなのかなぁw?
頑張って綺麗なコード書いて!

152 :仕様書無しさん:2015/05/19(火) 00:02:36.32
>>151
うるせえ死ね

153 :仕様書無しさん:2015/08/26(水) 07:07:28.57
>>129
実践するうちにネーミング力=要求分析能力という事がわかってきた。

154 :仕様書無しさん:2015/08/26(水) 07:43:04.13
構造化言語、オブジェクト指向言語と、コンピュータ言語の進歩って、
要するに「ネーミング技術」なんだと思っている。

アセンブラ時代の切れ目の無い長大なフローチャートを機能分割して、一機能に「名前」を付ける。
そうすれば、今度はそれを1個のCPU命令かのように扱えて、上位で扱わないといけない命令数が少なくなる。

そして、構造化言語で関数が大量に増えてくると、ある程度の関連性の有る単位でグループ化して
それを最小単位として「名前」を付けることで、それを最小の命令として上位で扱う命令数が少なくなる。

要するに、同時に扱わないといけないことを少なくするシンプルにする技術なんだな。

155 :仕様書無しさん:2015/10/14(水) 23:35:53.89
なんでこのスレ上がってきたんだろう

156 :仕様書無しさん:2015/11/21(土) 22:07:35.44
>>100
これでelseの代わりになる
if (a)
foo;
if (!a)
bar;

157 :仕様書無しさん:2015/12/06(日) 18:52:10.28
>>155
DDDが流行っているからな。

158 :仕様書無しさん:2016/02/11(木) 20:51:24.80
age

159 :仕様書無しさん:2016/02/12(金) 23:06:22.56
状態遷移管理するコントローラーとか
どうしてもめっちゃ長くなる…

160 :仕様書無しさん:2016/02/13(土) 15:24:01.43
状態遷移表とコントローラが一緒くたにハードコーディングしてるんじゃ無い?
小規模ならそれでも良いけど、ある程度以上にデカくなったらバラした方がいい。
それでもまだデカイ時は、大分類小分類とか多段ステートにして、小規模を維持する工夫をすれば良いよ。

161 :仕様書無しさん:2016/02/14(日) 22:06:31.53
>>159
は?画面遷移じゃなくて、アプリケーションの状態の管理をコントローラーがやってんの?

162 :仕様書無しさん:2016/02/14(日) 23:05:44.23
>>161
画面遷移です。状態ってのは画面のこと

バラして状態遷移のトリガーになるイベントと遷移元と遷移先とかMapに詰め込んで外だししてみたこともあったけど
めっちゃくちゃ見通し悪くなった…

結局Backコマンドとか、普通じゃない画面遷移とか、画面間のパラメータの受け渡しとかややこしくなるから
結局べた書きがいいという結論に達してべた書きしてる

みんなどうやって管理してんの…

163 :仕様書無しさん:2016/03/02(水) 08:28:16.26
>>162
webアプリなら、そもそも複雑な状態遷移を管理しないようにしてるよ。

164 :仕様書無しさん:2016/04/03(日) 12:02:44.58
4月から3年目のペーペーだけど、「単一責務(Single Responsibility)」守ってれば30行以内に収まるだろ?

10行:非常に良い
20行:良い
30行:普通
40行:ちょっと長いけど、まぁ許容範囲
50〜60行:やむを得ない事情があるなら仕方ないけど、極力分割を考えるべき
70〜90行:よほど退っ引きならない事情(数十個のswitch-caseが必要など)があるなら仕方ないけど、それ以外の理由では不可。
そもそも、大量のswitch-caseが必要になるときは、
アルゴリズムよりもデータ構造に問題がある場合が多い。
クラス設計をもう一度見直すべき。

100行以上:如何なる理由があろうと不可。
絶対に1メソッド内で複数の処理をしているはず(単一責務を守ってない)。
こんなん書いて許されるのは1年目だけ。

165 :仕様書無しさん:2016/04/03(日) 13:55:10.43
Javaや.NETのクラスライブラリって1年目のぺーぺーが書いてるんだろうな
100行以上のメソッドあるし

166 :仕様書無しさん:2016/04/03(日) 19:56:19.58
Haskellのソースコードは1メソッドあたり物凄く短いと思った
少ししか見てないけど

167 :仕様書無しさん:2016/04/03(日) 20:33:14.93
>>165
PG自体が技術者のぺーぺーだろ

168 :仕様書無しさん:2016/04/03(日) 22:34:52.91
メソッドの行数が増えることに気をとられて無駄に分割する奴もまたぺーぺーである

169 :仕様書無しさん:2016/04/03(日) 23:01:04.44
意識高い系 vs ペーペー

170 :仕様書無しさん:2016/04/09(土) 20:42:13.40
アクセサ禁止で要素ひとつになるまでクラスにするって不可能じゃない?

171 :仕様書無しさん:2016/04/10(日) 18:19:07.54
>>170
根本的に馬鹿

172 :仕様書無しさん:2016/04/18(月) 02:39:19.17
>>165
> Javaや.NETのクラスライブラリって1年目のぺーぺーが書いてるんだろうな
> 100行以上のメソッドあるし
例えばどれ?

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/96c21f6ea9f2/src

173 :仕様書無しさん:2016/04/18(月) 18:07:55.51
>>81
今日読んだ
オブジェクト指向をきちんとつかいたいあなたへ
って本に同じ話が出てた。有名なんやな

174 :仕様書無しさん:2016/04/18(月) 18:09:50.59
更に言うと実務ではルール通りいかないことも多々あるが、練習くらいはルールを意識して書けと書いてた

175 :仕様書無しさん:2016/04/18(月) 23:38:56.02
練習してない事を実践でいきなりやるのは無理だから練習中からルール通りいかない事を意識しとくべきだな

176 :仕様書無しさん:2016/05/28(土) 18:41:47.83
有志がオブジェクト指向エクササイズ講習会やってたりするんで首都圏の人で興味があれば行ってみれば?

177 :仕様書無しさん:2016/05/29(日) 08:47:34.06
ってか、メンバー変数2つまでって無理じゃね?
Personクラスに
string _name;
int _age;
bool _isMale;
ってすることすら許されないんだろ?

178 :仕様書無しさん:2016/05/29(日) 11:39:06.05
所詮は理想論なんだよね
意識高い系はチームでは和を乱す問題児でしかない
ワンマンのプロジェクトなら好きにしていいけどね
ポリモーフィズムよりスイッチ
オブジェクトより手続き
プライベートよりパブリック
それが社会の出した答えだよ
郷に入りては郷に従えってことさ
給与や昇進にも影響するから気を付けないとね

179 :仕様書無しさん:2016/05/30(月) 00:29:39.77
>>177
isMaleって書いちゃうセンスが既に禁止事項な件・・・
その勢いだと、isFemale、isTransgenderとかも作るのか?

180 :仕様書無しさん:2016/05/30(月) 10:37:09.26
え・・・
trueなら男
falseなら女でしょ
stringで持つわけ?

181 :仕様書無しさん:2016/05/30(月) 12:28:16.20
enumでもてよ

182 :仕様書無しさん:2016/05/30(月) 13:24:46.31
>>179
enumにしたところでメンバー変数2つ以上なんだよなあ

183 :仕様書無しさん:2016/05/30(月) 16:05:32.94
>>180
昨今、trueでもfalseでもないのがいるだろ…

184 :仕様書無しさん:2016/05/30(月) 22:51:34.30
性別をboolにするとかセンス無いというか
常識知らないというか、知識ないというか。

ISO 5218に従えばいいだけだろ
自分で考えるなや

ISO 5218とは、言語に依存しない1桁のコードによるヒトの性別の表記に関する国際規格。
https://ja.wikipedia.org/wiki/ISO_5218

185 :仕様書無しさん:2016/05/30(月) 22:54:47.90
>>184
性別ごときなんでもいいよw

186 :仕様書無しさん:2016/05/31(火) 00:56:19.07
エンティティ系クラスでインスタンス変数を3以下にするのは難しいと思う。

後、性別はGenderクラスを作るかな。Male, Femal, Lesbian, Gay, Bisexual, Transgender

187 :仕様書無しさん:2016/05/31(火) 02:28:31.09
そのISOってどれくらい知られてるの?

188 :仕様書無しさん:2016/05/31(火) 07:37:29.05
lgbtは男女に分類されるべきでlgbtという性別はないのではないか問題

189 :仕様書無しさん:2016/08/22(月) 22:55:52.17
いいかげん、引数をすべてstringにして、会話のようにできないのかい?
もう引数、戻り値、いちいち書くのめんどくせぇ

190 :仕様書無しさん:2016/08/23(火) 01:49:03.97
やればいいじゃん

191 :仕様書無しさん:2016/08/23(火) 06:56:03.79
その結果、COBOLの完成です。

38 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)