好ましい関数/メソッドの行数
| 64 票 / 9% |
| 94 票 / 14% |
| 113 票 / 16% |
| 60 票 / 9% |
| 90 票 / 13% |
| 21 票 / 3% |
| 34 票 / 5% |
| 189 票 / 28% |
投票所 | 他の国民投票
- 選択肢が少なくても文句禁止。だって、そもそもがジョークだし、場所は有限だし、選択肢を決めるのに事前投票なんてできないから。
- なんか良い投票ネタがあったら是非タレコんでくれ(国民投票用と明記)。毎回かなり悩みまくりなんだな、これが。ぶつぶつ言わずに助けてくれよぅ。
- この投票はとってもテキトーだ。四捨五入の誤差、投票マニア、ダイナミックなIP、 システムのバグ、プロキシーやファイヤウォールなんて考慮しちゃいない。統計だと思って このデータを大事な事に流用しようと思うなら小学校からやり直しましょう。
この議論は賞味期限が切れたので、アーカイブ化されています。
新たにコメントを付けることはできません。
多けりゃ多いだけ良い仕事 (スコア:2)
by ステップ数至上主義者
Re: (スコア:0)
へーへーへー
switch(num){
case 1: hogehoge;
case 2 : hogehoge;
-中略-
case 999 : hogehoge;
-もっかい中略-
case 9999 : hogehoge;
}
Re: (スコア:0)
for (int i = 0; i 10; i++){
count++;
}
より、
count++;
count++;
count++;
count++;
count++;
count++;
count++;
count++;
count++;
count++;
の方が早いと強弁!
Re: (スコア:0)
どっちもコンパイラがcount+=10に最適化してくれそう
Re: (スコア:0)
依頼元はバイナリのサイズでカネ払うわけじゃないからそれはどうでもいい。
Re: (スコア:0)
>for (int i = 0; i 10; i++){
メジャーなコンパイラ言語だとコンパイルできない気がするのは気せい?
Re: (スコア:0)
不等号が投稿時のタグ除去に引っかかったんだろう
そこは察してあげて
70行程度の行数じゃないと耐えられないのか (スコア:2)
さすがにこれは甘えでしかない。
そんなもんで収まるのはしょーもないプログラムぐらいのもの。
Re:70行程度の行数じゃないと耐えられないのか (スコア:1)
複雑だからこそ、一つの関数の処理が単機能に収まるように分割しないとダメです。
単体テストも書きやすいし、スタックトレース出して追いかけやすい。
長々書いてどうにかなるのはしょーもないプログラム。
# 複雑なコードはどうにもならないorz
# PHP3時代からいい感じに醸されたコード・・・うっ頭が(ry
Re: (スコア:0)
宣言的に、単機能な関数の組み合わせで書かれ、再帰を多用するプログラムは、正しく動く限りでは理解しやすい(したつもりになりやすい)が、
他人の書いたこの手のコードのバグ取りは死ぬる
他人の書いた単機能な関数に適切な名前がついていることはまれなので、関数の中身がある程度は展開されているほうが理解しやすく、
なによりコードをみてフローをなるべく簡単に理解できることが望ましい
つまりオブジェクト指向プログラミングは望ましくはない(とjane streetの連中などは言っている)
理想と現実 (スコア:2)
本当は 20 行以下に抑えたいところだけど、現実には 30 以上のも書いてしまう。
ごめんなさい嘘つきました。
たまに 70~80 くらいのも書いてます。
修行が足りない。
時と場合による (スコア:2)
原理主義に走るのは危険だと思うの。
べつやくメソッドなら (スコア:1)
一行で十分!
#しかし円グラフが必要になる
ψアレゲな事を真面目にやることこそアレゲだと思う。
Re:べつやくメソッドなら (スコア:1)
「高橋メソッド」という言葉が思い浮かんだものの、プログラムだと無理な気も。
行数の少ない関数が好ましい (スコア:1)
「10行以下」に投票したけど、もし「3行以下」の選択肢があればそれに投票したところ。もちろんベストは「1行」。
しかしあくまで「好ましい」というだけかな。絶対的な行数を減らすことを目標にはしない。
「一つの事を上手くやる」設計を心がけてりゃ自然に関数は短くなるし(複数の役目を持つ関数を書きたくなくなる)、処理内容によっては長い関数をゴリゴリ書いちゃうのが「上手くやる」方法だったりもするし、必要なら何百行でもこだわらない。
Re:行数の少ない関数が好ましい (スコア:2)
Re: (スコア:0)
1行ってreturnだけ?
それとも1行が3000文字?
Re:行数の少ない関数が好ましい (スコア:1)
前者です。
とはいえ、関数型的に書いたりメソッドチェーンしたりすれば「1行」でいくらでも長いのを書けて後者に陥ってしまうわけで、
そういうときは単に数行にするか、ものによってはさらに小さい複数の1行関数に分割します。
分岐とネストだっつーの (スコア:1)
行数減らすことに意識持ってくより
分岐とネストを減らすことに血眼になればいいのに
あと妙な分岐条件とかな
Re: (スコア:0)
それには賛成できません
適切な分割ができない場合、プログラマの能力であれ問題の本質であれですが、せめて一か所にまとまっているほうが読解しやすいですよ
Re: (スコア:0)
>せめて一か所にまとまっているほうが読解しやすいですよ
そういう話をしてんじゃないよ。複雑度を増やすなっていってんの
下のMSの例はまだ簡単な方だけど
https://msdn.microsoft.com/ja-jp/library/ms182212.aspx [microsoft.com]
スパゲッティなネストの例だと二次元のフィールドを扱うとき
for( 前){}
for(中){
{前端}
for(中々){ たまに特殊処理でのbreak;}
{たまに特殊処理から抜けたときの後処理break;だったりcontiueだったり}
{後端}
}
for(最後){}
とか強引に解決してるとかな。素直にそれぞれの点の状態情報だけ持つ別配列を持てばいいのに
あと
Re: (スコア:0)
> とか強引に解決してるとかな。素直にそれぞれの点の状態情報だけ持つ別配列を持てばいいのに
素直にそれぞれの点の状態情報だけを持つ別配列を素直に書いてくださると議論しやすいのですが、breakしたりcontinueしたりするのでたぶん素直には書けないんでしょう
ましてや素直に読めはしない
アドホックなデータ構造が多いとプログラムはかなり読みづらくなりますので、どうしても行数を減らしたいのなら
最上辺(...);
for(中){
{左端}
int n = 中身(...);
if (n == 最下辺までスキップ) break;
else if (n == 次の行までスキップ) con
Re: (スコア:0)
女性声優のCDである || 女性アイドルのCDである、という式にこれ以上簡潔な名前をつけることは不可能です
!持っている || 握手券入り、という式について考えますと、「持っている」「握手券入り」というのはプログラマに与えられたただの事実です
しかしこの式にたとえば「欲しいCD」という名前を付けることはできません
なぜなら「欲しいCD」というのはあくまで女性声優かアイドルのCDについての文脈においてのみ意味を持つ命題だからです
無意味な命題のために名前をつけるとプログラムに混乱を招きます
Re: (スコア:0)
if( (女性声優 || 女性アイドル) && (!すでに持っている || 握手券入り) ) { CDを購入 }
こういうことですね。
とても分かりやすいです。感動しました。
師匠と呼ばせてください。
Re: (スコア:0)
>if( (女性声優 || 女性アイドル) && (!すでに持っている || 握手券入り) ) { CDを購入 }
cond1という名前にこだわってる割にそもそもその全体の分岐条件に名前をつけない時点でセンスがないから
お前はプログラマ名乗るの辞めろ
そういう奴はクライアントのいうままCDを購入の中に女性で握手券入りだけど欲しくない人は除外ってのを加え始めて
最期に誰も保守できないクズを量産する羽目になんだよ
Re: (スコア:0)
> cond1という名前にこだわってる割にそもそもその全体の分岐条件に名前をつけない時点でセンスがないから
cond1という名前に文句をつけたのはわたしですが
> 女性声優か女性アイドルのCDで、かつ、まだ持っていないか握手券入りなら、CDを買う
と、わざわざ日本語で書きましたが、気づかなかったのでしょうか
あなたもそう愚かな人間ではないでしょうに、先入観というのは恐ろしいですね
SPARC向けのソフト (スコア:1)
とあるシステムで1関数が1000~2000行とかがゴロゴロしていたのだが、どうやら関数呼び出しの階層を極力減らしたかったように思える。
確かにレジスタウィンドウ方式だとレジスタファイルが溢れると大きなオーバーヘッドが掛かるみたいだが、そんなに性能が低下するものだったのかちょっと疑問。
Re:SPARC向けのソフト (スコア:1)
しっかり何重ものループで結構同じ処理が何ヶ所もあったような。
インデントが崩れているところもあったり、とても見にくいソースだった。
でも改造すべき箇所は数行なのでテスト数不足と判定されてしまった。
(計算式おかしいだろう…)
10行以下 (スコア:0)
1行の文字数制も欲しい
Re: (スコア:0)
なのか
なのか、それでも全然密度変わってくるからなぁ
# 言語にもよる・・・そういう意味では割と誰が書いても同じ長さになるVB.NETはアリなのか?
Re: (スコア:0)
関数型言語とくにHaskellでは改行をいれずに一行に書くことが好まれ、それ以外の言語でも最近はローカル識別子以外は長いものが好まれますので、pythonなどが推奨する横80文字はもはや非現実的と言えましょう
Re: (スコア:0)
COBOLer「・・・」
Re: (スコア:0)
前者が主流のJavaやらPHPなら20行以下派だけど、後者のC#やなんかでは40行ぐらいまでは許せるな。
あと、関数と言っても、1行がフルに活用されているようなコードと、DBから読み込んではパラメータ詰め替え、ひたすら各パラメータのバリデーションが続く、みたいな定型的な処理が並んでるだけのコードかでも、だいぶ印象が違ってくる。
後者なら、それこそ60行とかでもまあ何とか許容範囲と言えなくもない。コメントとかも駆使して整理はしててほしいけど。
情報量の密度によるって感じかなー。
だが「いくら長くてもOK」な奴ら。お前らにはちょっと話がある。
# 大昔に触ったVB6コードでは、引数定義だけで60行みたいな子も…(涙
Re: (スコア:0)
VisualStudioのデフォルトがAllmanに変わった時には目の前が暗くなった。
昔はK&Rスタイルだったのに。
Re: (スコア:0)
その次はタブサイズ(2、4、8、etc)かな
Re: (スコア:0)
ハードタブ・ソフトタブも
理想と現実 (スコア:0)
現実には全ての関数を20〜30行以内にするなんて不可能でしょう。
最初は短かかった関数も、クライアントからの度重なる仕様変更でいつの間にか・・・ということになる。
そんな時、関数の構造を再設計するよりも、とりあえず動けばいいということになるわな。
個人的には、スクロールさせなくてもディスプレイに収まる長さがベストです。
Re: (スコア:0)
スクロールさせなくてもディスプレイに収まる長さがベストです。
160行くらいかな(4K100%スケール。周りからキチガイ扱いされる)
多分縦画面化すれば300行も可
Re:理想と現実 (スコア:2)
人間が視線を移動させずに文字を読めるのは、頑張って10度位が限界。普通は数度程度。
視力1.0だと600ドットの隙間が見える程度が上限だね。
少なめに見積もって、480ドットに16ドットフォントで表示させて30行が一度に見える限界かと。
これ以上は、視線移動と云う擬似スクロールが必須になる。
//尤も、横方向も限界は同じだから、結局、視線移動が複合するか否かの問題になるな
実際にスクロールすると動体視力が必要になる上に、視線移動よりも遅くなるから、一度に見えた方が便利ではある。
関数の前後関係を把握し易いと云う意味で、60行程度表示されると多分便利。でも、一目で全部見るのは人間技じゃないと思う。
160行だと、視線移動と合焦距離変更を同時に行う必要が有る筈。
或いは、近点視力が凄く良いのかな?
でも、300行だと、多分合焦距離変更が耐えられなくなると思う。湾曲モニタの出番かも。
-- Buy It When You Found It --
Re: (スコア:0)
4K100%スケールつっても
何インチディスプレイなのかで
見やすさはまるで別物ですね
40インチなら4K100%スケールは
20インチFull HDの100%スケール4枚と同等ですので
普通に見やすいですよ
# 110ppiくらいかな
Re: (スコア:0)
40インチのディスプレイを20インチのディスプレイと同じ距離で見るとか視野角が変わらないという前提がおかしい。
Re: (スコア:0)
想像するとおかしく感じるだけですよ
実際に使ってみれば
想像の仕方がおかしかったと気付けるはずです
Re: (スコア:0)
まあ、私はP2415Qですがね(スケーリング100%)
……常人の使うPCの2倍細かい。見えるけど。
Re: (スコア:0)
rubyのプロジェクトで全部のメソッドを基本的に5行以内で作ったという話がありますよ。
ttps://robots.thoughtbot.com/sandi-metz-rules-for-developers
環境依存 (スコア:0)
紙カード時代 : B5 のノートの1ページに収まるぐらい(30行程度、もちろん手書き)
ダムターミナル時代 : 画面1枚に入るぐらい(20行程度、スクロールが遅かったのでページをまたぐのはストレス)
ワークステーション時代 : emacs の2~3画面程度(100行程度、マシンを占有出来るとページスクロールが早い早い)
PC時代 : いろいろ(仕事でまともな長さのプログラムを組まなくなったので気にしなくなった)
なんちゃってプログラマなので5ページにも及ぶDO loop [genpaku.org]なんて書きたいとも思わなかった :)
Re:環境依存 (スコア:1)
このころはLP用紙1枚に入る66行だった.
Re:環境依存 (スコア:1)
横幅はパンチカードのカラム数で72ってのも付けといて
C ダム端末になっても同じ桁数
ワンライナー大勝利 (スコア:0)
っておもったけどそういう場合はそもそも関数化しないか
30行計画 (スコア:0)
25行と言いたいところだけど、30行までは頑張れば表示できたからギリギリ1画面。
行数は構わない (スコア:0)
一行の文字数は80文字まで。異論は認めない。