アカウント名:
パスワード:
パッと目の前のソースコードを見ると長い行では200列程度だった。うちスペースインデントが30列程度で、80列表示にしたらほとんどの行が見切れる。以前は画面分割で120列程度で書くことが多かったが、120列もちょいきつい。一応Visual StudioでのC#開発、しかも自分のコードだから比較的冗長で列が長くても分かるという条件だからC++とは話が変わってくると思う。
ところで割と話題になってるのに定量的な議論が欠けてる気がする。GitHubでホストされてるC++のオープンソースプロジェクトでは～行が～%で、みたいないつもの数字はないのかしら？
たてよこ
そこまで深いインデントになるような処理は、関数化するなりして分離したほうがいいと思うぞ。
下請けから20段以上ifやforがネストしたコードが納品されてきたことならあったなあ（さすがに書き直させた）インデント=4文字幅の規約だったから、インデントだけで80桁超えてたのか。
書き直させるのは合法だったんでしょうか？あらかじめコーディング規約などでネストを制限していたとかならともかく、業務委託でかつ仕様を満たしていたとすれば、書き直させるのは、わりと違法性が高いのでは（特に下請法とか）？
コーディング規約はあって、受け入れのレビューをしたのが自分でした。下請けとどういう契約だったのかは当時の自分には分かりませんが（昔の職場での話）、グレーだったのかもなぁ…
規約に反してたなら要求仕様を満たしていないわけで受け取り拒否でしょ。結果として描き直しになるのは違法でもなんでもない。反してなければいちゃもんですなぁ。インデントが80桁超えるコードを許容するコーディング規約ってのがあるとも思えないけど。
ネストは何層までとかいう規約がある方が普通ではないのでは？目安として「いくら程度まで」というのは可能かもしれないけど、それを律儀に守ろうとしてかえって意味不明なコードになることもありそう。
特に最近は C++ ですら初期化リストみたいな物ができたきたから、複雑なオブジェクトの初期化なんかで一気に4，5層くらいのネストは発生しうるから、変に制限がぎりぎりだと、チマチマ関数で初期化するわかりにくいコードになってしまう。
かといってゆるゆるにすればあまり意味がないし。
あと、C# の using 構文みたいな
using (...)using (...)using (...)using (...){ ...}
のはネストに含むのか含まないのか（ぶら下がり文絶対禁止教の方はどうするんだろう？）。
> インデントが80桁超えるコードを許容するコーディング規約ってのがあるとも思えないけど。
しちゃいけない、って明記してあればいいけど。常識で考えてダメじゃん、ってあとから言われるケースが多そう。(個人の感想です)
using構文は確実に解放されるわけでないからtry-finallyを使えとかいう謎規約があったけどこれが原因か？
それはコーディング規約に「ブロックは {} 必須」が欲しいところですね。階層が分からなくなり過ぎる。
まあ、今のC#にはusing var構文 [ufcpp.net]があるんでもうusingはネスト要らないですけど。
・ジェネリックメソッド+型パラメータでコードクローン書かない・LINQでデータ一個見つけるようなループ無くす
ようにしたら全部for&if〜else延々書き連ねるコピペコードに直されたことは有るなぁ。。
そんなのC#じゃねぇ！読めない！だったかな？#ケンカして抜けた
最近は関数型言語でクロージャとか使ってインラインに書くのがかっこいいと思ってるからインデント深くなっていくんじゃないのか。120カラムで足りないというのはちょっとやりすぎな気もする。# クラス名が３０文字くらいあることはまれによくある。
中身のわかる短いコードが近くにあるほうが見通しがいいのはわかるけど、インデントだけで30桁(4桁インデント想定だと8個ぐらい？)にまで深くなるようなのは、明かに見通しが悪くなってる例だから、ちゃんと名前つけるなりして外に出したほうがいいぞ。
ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。見通しが悪くなるのは、唯一名前が変なときだけだ。
> 変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
そういう組織がある(関わったことないけど)だけで、そんな時代は存在しない。
それ難読化して元のコードを失くしちゃったから、みたいなシチュー?
宣言するたびにというのは嘘だろうが、台帳に記入して連番で意味わからん名前を割り振ってた時代は確かにあるぞABENDするたびにCBL00235やらJCL0AC6やら、紙の台帳ひっくり返していたものじゃよ
銀行の情報系会社の仕事がそれでしたね。○○さんが溢れてるから助けてやってくれ言われて不思議に思ったらそれだった。出現順(基準が分からんかった)で連番とか、そりゃどこの何か分からなくなるからそりゃそうだろと。#こうやって出来る人が消えて行く…
> ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。
C++でメンバ関数増やすことになるとヘッダに書くやん?そしたらいろいろコンパイルしなおしになるし、クラス内で再利用されたりするかもしれんやん?関数内関数とかラムダならそこ考えなくていいしコンパイル遅くならないしつい使っちゃう
関数の再利用を嫌うならいわゆる関数内関数は対策足り得ません。関数内関数は定義された関数内なら再利用できますからね。
pimpl とか抽象クラスとか知らないパターンですか？
namespace+class+関数だけで3個、for+if+try{}catch{}で3個、変数スコープの為の{}、ラムダ式やら使うと8段くらいは割と行く。ラムダ式があるのだってわざわざ関数にしたくない需要があるからだし、ネスト深いなら関数分けろって考えも古いのかもね。一度しか使わないようなprivate関数がたくさんあるのも混乱するし。
>ネスト深いなら関数分けろって考えも古いのかもね。ネスト深いなら、ラムダ式使って分ればいいじゃん。ラムダ式って所詮、関数だろ。
あほくさ連番で名前を付けるとかいうのを引き合いに出すとか
人間はいろいろな物や概念・事象に名前を付けることによって、この世界を理解し人間同士でコミュニケーションをとってきて、ここまで進歩してきたのに、無名の処理の方がわかりやすいとか。単に自分の語彙が貧弱なだけじゃねーの？
こういう人間が長い関数を馬鹿みたいに量産してバグを大量に発生させるわけだ
パワーシェル「」
人間ねえ。
きみの家では子供が料理に失敗して二度と見たくないオブジェを作ってしまった時、「黒焦げになった元食品だった塊なので、コゲコゲ元食品塊と命名します。コゲコゲ元食品塊を捨てて鍋からコゲコゲ元食品塊のクズを洗い落としておいてね」と変数名をわざわざ宣言するのかな。うちなら「それ捨てて、鍋は洗っておいてね」と匿名レファレンスで処理してしまうが、それは語彙が貧弱などと蔑まれるような事案なのかな。
馬鹿には話が通じないのがよくわかった。
酷いソースを 知ってるか汚いソースを 知ってるか数えろいまが その時だインデントスペース 30列コーディング規約は 80列インデントスペース 30列コーディング規約は 80列リファクタGO! リファクタGO!
一行抜けた
画面を見ろ for文5行後
最後の一行(≒曲タイトル)も抜けてると思う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
200列ぐらい (スコア:0)
パッと目の前のソースコードを見ると長い行では200列程度だった。
うちスペースインデントが30列程度で、80列表示にしたらほとんどの行が見切れる。
以前は画面分割で120列程度で書くことが多かったが、120列もちょいきつい。
一応Visual StudioでのC#開発、しかも自分のコードだから比較的冗長で列が長くても分かるという条件だからC++とは話が変わってくると思う。
ところで割と話題になってるのに定量的な議論が欠けてる気がする。
GitHubでホストされてるC++のオープンソースプロジェクトでは～行が～%で、みたいないつもの数字はないのかしら？
Re: (スコア:0)
たてよこ
Re: (スコア:0)
そこまで深いインデントになるような処理は、関数化するなりして分離したほうがいいと思うぞ。
Re:200列ぐらい (スコア:1)
下請けから20段以上ifやforがネストしたコードが納品されてきたことならあったなあ（さすがに書き直させた）
インデント=4文字幅の規約だったから、インデントだけで80桁超えてたのか。
Re: (スコア:0)
書き直させるのは合法だったんでしょうか？
あらかじめコーディング規約などでネストを制限していたとかならともかく、
業務委託でかつ仕様を満たしていたとすれば、書き直させるのは、
わりと違法性が高いのでは（特に下請法とか）？
Re:200列ぐらい (スコア:1)
コーディング規約はあって、受け入れのレビューをしたのが自分でした。
下請けとどういう契約だったのかは当時の自分には分かりませんが（昔の職場での話）、グレーだったのかもなぁ…
Re: (スコア:0)
規約に反してたなら要求仕様を満たしていないわけで受け取り拒否でしょ。
結果として描き直しになるのは違法でもなんでもない。
反してなければいちゃもんですなぁ。
インデントが80桁超えるコードを許容するコーディング規約ってのがあるとも思えないけど。
Re: (スコア:0)
ネストは何層までとかいう規約がある方が普通ではないのでは？
目安として「いくら程度まで」というのは可能かもしれないけど、
それを律儀に守ろうとしてかえって意味不明なコードになることもありそう。
特に最近は C++ ですら初期化リストみたいな物ができたきたから、
複雑なオブジェクトの初期化なんかで一気に4，5層くらいのネストは発生しうるから、
変に制限がぎりぎりだと、チマチマ関数で初期化するわかりにくいコードになってしまう。
かといってゆるゆるにすればあまり意味がないし。
あと、C# の using 構文みたいな
using (...)
using (...)
using (...)
using (...)
{
...
}
のはネストに含むのか含まないのか（ぶら下がり文絶対禁止教の方はどうするんだろう？）。
Re: (スコア:0)
> インデントが80桁超えるコードを許容するコーディング規約ってのがあるとも思えないけど。
しちゃいけない、って明記してあればいいけど。
常識で考えてダメじゃん、ってあとから言われるケースが多そう。(個人の感想です)
Re: (スコア:0)
using構文は確実に解放されるわけでないから
try-finallyを使えとかいう謎規約があったけど
これが原因か？
Re: (スコア:0)
それはコーディング規約に「ブロックは {} 必須」が欲しいところですね。階層が分からなくなり過ぎる。
まあ、今のC#にはusing var構文 [ufcpp.net]があるんでもうusingはネスト要らないですけど。
Re: (スコア:0)
・ジェネリックメソッド+型パラメータでコードクローン書かない
・LINQでデータ一個見つけるようなループ無くす
ようにしたら全部for&if〜else延々書き連ねるコピペコードに直されたことは有るなぁ。。
そんなのC#じゃねぇ！読めない！だったかな？
#ケンカして抜けた
Re: (スコア:0)
最近は関数型言語でクロージャとか使ってインラインに書くのがかっこいいと思ってるからインデント深くなっていくんじゃないのか。
120カラムで足りないというのはちょっとやりすぎな気もする。
# クラス名が３０文字くらいあることはまれによくある。
Re: (スコア:0)
いちいち名前つけて遠くに定義するより中身の見える短いコードが近くにあった方が読みやすいからだよ
変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
Re: (スコア: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)
>ネスト深いなら関数分けろって考えも古いのかもね。
ネスト深いなら、ラムダ式使って分ればいいじゃん。ラムダ式って所詮、関数だろ。
Re: (スコア:0)
あほくさ
連番で名前を付けるとかいうのを引き合いに出すとか
人間はいろいろな物や概念・事象に名前を付けることによって、この世界を理解し
人間同士でコミュニケーションをとってきて、ここまで進歩してきたのに、
無名の処理の方がわかりやすいとか。単に自分の語彙が貧弱なだけじゃねーの？
Re: (スコア:0)
Re: (スコア:0)
こういう人間が長い関数を馬鹿みたいに量産してバグを大量に発生させるわけだ
Re: (スコア:0)
パワーシェル「」
Re: (スコア:0)
人間ねえ。
きみの家では子供が料理に失敗して二度と見たくないオブジェを作ってしまった時、「黒焦げになった元食品だった塊なので、コゲコゲ元食品塊と命名します。コゲコゲ元食品塊を捨てて鍋からコゲコゲ元食品塊のクズを洗い落としておいてね」と変数名をわざわざ宣言するのかな。うちなら「それ捨てて、鍋は洗っておいてね」と匿名レファレンスで処理してしまうが、それは語彙が貧弱などと蔑まれるような事案なのかな。
Re: (スコア:0)
馬鹿には話が通じないのがよくわかった。
Re: (スコア:0)
酷いソースを 知ってるか
汚いソースを 知ってるか
数えろいまが その時だ
インデントスペース 30列
コーディング規約は 80列
インデントスペース 30列
コーディング規約は 80列
リファクタGO! リファクタGO!
Re: (スコア:0)
一行抜けた
画面を見ろ for文5行後
Re: (スコア:0)
最後の一行(≒曲タイトル)も抜けてると思う