アカウント名:
パスワード:
パッと目の前のソースコードを見ると長い行では200列程度だった。うちスペースインデントが30列程度で、80列表示にしたらほとんどの行が見切れる。以前は画面分割で120列程度で書くことが多かったが、120列もちょいきつい。一応Visual StudioでのC#開発、しかも自分のコードだから比較的冗長で列が長くても分かるという条件だからC++とは話が変わってくると思う。
ところで割と話題になってるのに定量的な議論が欠けてる気がする。GitHubでホストされてるC++のオープンソースプロジェクトでは~行が~%で、みたいないつもの数字はないのかしら?
そこまで深いインデントになるような処理は、関数化するなりして分離したほうがいいと思うぞ。
最近は関数型言語でクロージャとか使ってインラインに書くのがかっこいいと思ってるからインデント深くなっていくんじゃないのか。120カラムで足りないというのはちょっとやりすぎな気もする。# クラス名が30文字くらいあることはまれによくある。
中身のわかる短いコードが近くにあるほうが見通しがいいのはわかるけど、インデントだけで30桁(4桁インデント想定だと8個ぐらい?)にまで深くなるようなのは、明かに見通しが悪くなってる例だから、ちゃんと名前つけるなりして外に出したほうがいいぞ。
ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。見通しが悪くなるのは、唯一名前が変なときだけだ。
> 変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
そういう組織がある(関わったことないけど)だけで、そんな時代は存在しない。
それ難読化して元のコードを失くしちゃったから、みたいなシチュー?
宣言するたびにというのは嘘だろうが、台帳に記入して連番で意味わからん名前を割り振ってた時代は確かにあるぞABENDするたびにCBL00235やらJCL0AC6やら、紙の台帳ひっくり返していたものじゃよ
銀行の情報系会社の仕事がそれでしたね。○○さんが溢れてるから助けてやってくれ言われて不思議に思ったらそれだった。出現順(基準が分からんかった)で連番とか、そりゃどこの何か分からなくなるからそりゃそうだろと。#こうやって出来る人が消えて行く…
> ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。
C++でメンバ関数増やすことになるとヘッダに書くやん?そしたらいろいろコンパイルしなおしになるし、クラス内で再利用されたりするかもしれんやん?関数内関数とかラムダならそこ考えなくていいしコンパイル遅くならないしつい使っちゃう
関数の再利用を嫌うならいわゆる関数内関数は対策足り得ません。関数内関数は定義された関数内なら再利用できますからね。
pimpl とか抽象クラスとか知らないパターンですか?
namespace+class+関数だけで3個、for+if+try{}catch{}で3個、変数スコープの為の{}、ラムダ式やら使うと8段くらいは割と行く。ラムダ式があるのだってわざわざ関数にしたくない需要があるからだし、ネスト深いなら関数分けろって考えも古いのかもね。一度しか使わないようなprivate関数がたくさんあるのも混乱するし。
>ネスト深いなら関数分けろって考えも古いのかもね。ネスト深いなら、ラムダ式使って分ればいいじゃん。ラムダ式って所詮、関数だろ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
200列ぐらい (スコア:0)
パッと目の前のソースコードを見ると長い行では200列程度だった。
うちスペースインデントが30列程度で、80列表示にしたらほとんどの行が見切れる。
以前は画面分割で120列程度で書くことが多かったが、120列もちょいきつい。
一応Visual StudioでのC#開発、しかも自分のコードだから比較的冗長で列が長くても分かるという条件だからC++とは話が変わってくると思う。
ところで割と話題になってるのに定量的な議論が欠けてる気がする。
GitHubでホストされてるC++のオープンソースプロジェクトでは~行が~%で、みたいないつもの数字はないのかしら?
Re: (スコア:0)
そこまで深いインデントになるような処理は、関数化するなりして分離したほうがいいと思うぞ。
Re: (スコア:0)
最近は関数型言語でクロージャとか使ってインラインに書くのがかっこいいと思ってるからインデント深くなっていくんじゃないのか。
120カラムで足りないというのはちょっとやりすぎな気もする。
# クラス名が30文字くらいあることはまれによくある。
Re: (スコア:0)
いちいち名前つけて遠くに定義するより中身の見える短いコードが近くにあった方が読みやすいからだよ
変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
Re:200列ぐらい (スコア:0)
中身のわかる短いコードが近くにあるほうが見通しがいいのはわかるけど、
インデントだけで30桁(4桁インデント想定だと8個ぐらい?)にまで深くなるようなのは、明かに見通しが悪くなってる例だから、ちゃんと名前つけるなりして外に出したほうがいいぞ。
ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。
見通しが悪くなるのは、唯一名前が変なときだけだ。
> 変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
そういう組織がある(関わったことないけど)だけで、そんな時代は存在しない。
Re: (スコア:0)
それ難読化して元のコードを失くしちゃったから、みたいなシチュー?
Re: (スコア:0)
宣言するたびにというのは嘘だろうが、台帳に記入して連番で意味わからん名前を割り振ってた時代は確かにあるぞ
ABENDするたびにCBL00235やらJCL0AC6やら、紙の台帳ひっくり返していたものじゃよ
Re: (スコア:0)
銀行の情報系会社の仕事がそれでしたね。
○○さんが溢れてるから助けてやってくれ言われて不思議に思ったらそれだった。
出現順(基準が分からんかった)で連番とか、そりゃどこの何か分からなくなるからそりゃそうだろと。
#こうやって出来る人が消えて行く…
Re: (スコア:0)
> ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。
C++でメンバ関数増やすことになるとヘッダに書くやん?
そしたらいろいろコンパイルしなおしになるし、クラス内で再利用されたりするかもしれんやん?
関数内関数とかラムダならそこ考えなくていいしコンパイル遅くならないしつい使っちゃう
Re: (スコア:0)
関数の再利用を嫌うならいわゆる関数内関数は対策足り得ません。
関数内関数は定義された関数内なら再利用できますからね。
Re: (スコア:0)
pimpl とか抽象クラスとか知らないパターンですか?
Re: (スコア:0)
namespace+class+関数だけで3個、for+if+try{}catch{}で3個、変数スコープの為の{}、ラムダ式やら使うと8段くらいは割と行く。
ラムダ式があるのだってわざわざ関数にしたくない需要があるからだし、ネスト深いなら関数分けろって考えも古いのかもね。
一度しか使わないようなprivate関数がたくさんあるのも混乱するし。
Re: (スコア:0)
>ネスト深いなら関数分けろって考えも古いのかもね。
ネスト深いなら、ラムダ式使って分ればいいじゃん。ラムダ式って所詮、関数だろ。