アカウント名:
パスワード:
1はlambda式とかfluent interfaceとかずらずら書く方式を使ってるとキツイね。まあ適当に改行入れれば回避できる。それで行数が極端に増えるってことはないだろう。2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。機能を詰め込むとテストしづらくなってバグの温床となる。
2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。
そういう哲学以前に、ソースコードを紙に印刷する因習を引きずってるだけなのでは?
関数に分けることの最大の目的は、処理に名前を付けること。
例えば、池袋から梅田に行く方法を説明するのに、
JRの○○改札を抜けと20メートルほど先に進み、右に曲がったあと7番ホームへの階段を上り(中略)新幹線を降りたら、右手に進んで階段を降り、まっすぐ進むと右手に京都線ホームへの階段がある喉(以下略)
みたいな説明されるより、
1. 山手線で品川まで行く。2. 品川で東海道新幹線に乗る。3. 新大阪で京都線に乗り換える。4. 大阪駅で降りる。
山手線で品川まで行く方法は...
のように説明される方がわかりやすい。一回しか使わないから関数化する必要ないなんて馬鹿はこのことを理解していない。意味のない関数名を付ける奴も同様。
名前をつける効果よりローカル変数のスコープを最小限にするためとか使用する変数を最小限に絞る効果のほうが大きそう。
Cloud9+Lambda なので「ファイル」がありません……
画面が640*480時代とかcobol時代の悪い面がレガシーで残ってるような規約だね
5千行のメソッドなら作られてしまったことあった。超う○こだった。
①1行は80桁に収めろ
普段から何となく感じているのだが、これは人間が頭を使ってやる作業ではないと思うし、80桁強制は可読性でデメリットがある(ケースがある)。
桁は制限せず、ビュー側のツールで何とかするとかが良い気がする。整形表示モードを切り替えられるとか、マウスオーバーなりのアクションで展開表示されるとか。
カードリーダーの頃は、80桁越えは、物理的に不可だった、、。
一体、いつの時代だ?
①②は(この規則を破る例外が許容されているならば)まあ分かるけど、③はないわ。少なすぎ。
1関数1ファイルなら守れるだろうけど、ファイル数が増えてかえって視認性が悪くなりそう
③は明らかにおかしいコーディング規約だなぁ。下手するとヘッダファイルのJavaDocコメントと#define定義や型定義で200行が終わって、クラス定義書けないわな。むしろ、コメント書くなって規約かな、これ。
200行は少なすぎだよね…ファイル数が膨大になるのはいいのだろうか…
”1行は80桁に収める”については、会社の規約では120行以内にしてるが、オレは自分のプログラムは必ず1行80桁にしてるし、別に困ったことはないかな。
オレが1行80桁に抑えてるのは、エディタがどんなにリッチになってPCの画面が大きくなろうと、プログラムの開発環境はIDEだし、IDEにはエディタWindow以外にも沢山のWindowがひしめいてるから、エディタWindowの桁数を80桁に制限しないと、デバック時に横スクロールが発生して、デバックが物凄く煩わしくなるからなんだよね。そういう面から、むしろオレは今だからこそ80桁に制限したいかなぁ。
80はいやだなぁ今見ると横180文字ぐらいのエディタウィンドウが横に3つ並んでもまだ画面余ってるし、画面買えば解決できる話かなと
今はライブラリの関数名とか異様に長いの多いですから、さすがに80桁は辛いですねぇ。ただ広すぎるのも、左右への首もしくは眼球の動きが激しくなるので疲れる。
仕事柄、移動してデバックが多くて、開発PCはノートPCだったりするんで、デカい画面で固定位置で開発/デバックにはならないんだよね。ついでに、老眼が始まると解像度の高い画面で小さい字だと読めないし。
オレ自身は、1行80桁で困ったことが無いから、どういう時に困るのかがよく分からん。
いつもノートだから狭いんだよと言われると仕方ない感ありますね80桁でに横2画面ぐらいになっちゃうし
老眼についてはわかり味が深いですが、自分はメガネを画面の方にチューニングしてます
どんな時に困るかって言うとオブジェクト3段ぐらい辿る時とかですね変数名が長く取れるのも好み
ハイビジョン見ると昔のテレビが汚く見えるようなもんで広いのに慣れると狭いのは勘弁してもらいたくなります
テレビと同じでしばらくたてば馴れるのかもしれないけど
オレ環境のオレルールが悪いコーディング規約
一度に表示できればいいってもんじゃないからな。視線移動は最小にすべき。
文字数に意識が向かうと極端に短名な変数名とか関数出てきて…
識別子を短くしたり、コメント削ったり逆に品質の低下を招きそう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
見直してよ・・・ (スコア:4, 興味深い)
②1関数は50行に収めろ
③1ファイルは200行に収めろ
②③で超えさせたい場合は理由を添えて申請しろ
※どんな言語でもこれ適用
Re:見直してよ・・・ (スコア:1)
1はlambda式とかfluent interfaceとかずらずら書く方式を使ってるとキツイね。
まあ適当に改行入れれば回避できる。それで行数が極端に増えるってことはないだろう。
2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。
機能を詰め込むとテストしづらくなってバグの温床となる。
Re: (スコア:0)
2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。
そういう哲学以前に、ソースコードを紙に印刷する因習を引きずってるだけなのでは?
Re:見直してよ・・・ (スコア:1)
関数に分けることの最大の目的は、処理に名前を付けること。
例えば、池袋から梅田に行く方法を説明するのに、
JRの○○改札を抜けと20メートルほど先に進み、右に曲がったあと7番ホームへの
階段を上り(中略)新幹線を降りたら、右手に進んで階段を降り、まっすぐ進むと
右手に京都線ホームへの階段がある喉(以下略)
みたいな説明されるより、
1. 山手線で品川まで行く。
2. 品川で東海道新幹線に乗る。
3. 新大阪で京都線に乗り換える。
4. 大阪駅で降りる。
山手線で品川まで行く方法は...
のように説明される方がわかりやすい。一回しか使わないから関数化
する必要ないなんて馬鹿はこのことを理解していない。意味のない
関数名を付ける奴も同様。
Re:見直してよ・・・ (スコア:2)
名前をつける効果より
ローカル変数のスコープを最小限にするためとか
使用する変数を最小限に絞る効果のほうが大きそう。
Re:見直してよ・・・ (スコア:1)
Cloud9+Lambda なので「ファイル」がありません……
Re: (スコア:0)
画面が640*480時代とかcobol時代の悪い面がレガシーで残ってるような規約だね
Re: (スコア:0, 荒らし)
Re: (スコア:0)
5千行のメソッドなら作られてしまったことあった。超う○こだった。
Re: (スコア:0)
①1行は80桁に収めろ
普段から何となく感じているのだが、これは人間が頭を使ってやる作業ではないと思うし、
80桁強制は可読性でデメリットがある(ケースがある)。
桁は制限せず、ビュー側のツールで何とかするとかが良い気がする。
整形表示モードを切り替えられるとか、マウスオーバーなりのアクションで展開表示されるとか。
Re: (スコア:0)
カードリーダーの頃は、80桁越えは、物理的に不可だった、、。
一体、いつの時代だ?
Re: (スコア:0)
①②は(この規則を破る例外が許容されているならば)まあ分かるけど、
③はないわ。少なすぎ。
Re: (スコア:0)
1関数1ファイルなら守れるだろうけど、ファイル数が増えてかえって視認性が悪くなりそう
Re: (スコア:0)
③は明らかにおかしいコーディング規約だなぁ。
下手するとヘッダファイルのJavaDocコメントと#define定義や型定義
で200行が終わって、クラス定義書けないわな。
むしろ、コメント書くなって規約かな、これ。
Re: (スコア:0)
200行は少なすぎだよね…
ファイル数が膨大になるのはいいのだろうか…
Re: (スコア:0)
”1行は80桁に収める”については、会社の規約では120行以内にしてるが、
オレは自分のプログラムは必ず1行80桁にしてるし、別に困ったことはないかな。
オレが1行80桁に抑えてるのは、エディタがどんなにリッチになってPCの画面が大きくなろうと、
プログラムの開発環境はIDEだし、IDEにはエディタWindow以外にも沢山のWindowがひしめいてるから、
エディタWindowの桁数を80桁に制限しないと、デバック時に横スクロールが発生して、
デバックが物凄く煩わしくなるからなんだよね。
そういう面から、むしろオレは今だからこそ80桁に制限したいかなぁ。
Re:見直してよ・・・ (スコア:2)
80はいやだなぁ
今見ると横180文字ぐらいのエディタウィンドウが横に3つ並んでもまだ画面余ってるし、
画面買えば解決できる話かなと
Re: (スコア:0)
今はライブラリの関数名とか異様に長いの多いですから、さすがに80桁は辛いですねぇ。
ただ広すぎるのも、左右への首もしくは眼球の動きが激しくなるので疲れる。
Re: (スコア:0)
仕事柄、移動してデバックが多くて、開発PCはノートPCだったりするんで、
デカい画面で固定位置で開発/デバックにはならないんだよね。
ついでに、老眼が始まると解像度の高い画面で小さい字だと読めないし。
オレ自身は、1行80桁で困ったことが無いから、どういう時に困るのかがよく分からん。
Re:見直してよ・・・ (スコア:2)
いつもノートだから狭いんだよと言われると仕方ない感ありますね
80桁でに横2画面ぐらいになっちゃうし
老眼についてはわかり味が深いですが、自分はメガネを画面の方にチューニングしてます
どんな時に困るかって言うとオブジェクト3段ぐらい辿る時とかですね
変数名が長く取れるのも好み
ハイビジョン見ると昔のテレビが汚く見えるようなもんで
広いのに慣れると狭いのは勘弁してもらいたくなります
テレビと同じでしばらくたてば馴れるのかもしれないけど
Re: (スコア:0)
オレ環境のオレルールが悪いコーディング規約
Re: (スコア:0)
一度に表示できればいいってもんじゃないからな。
視線移動は最小にすべき。
Re: (スコア:0)
文字数に意識が向かうと極端に短名な変数名とか関数出てきて…
Re: (スコア:0)
識別子を短くしたり、コメント削ったり
逆に品質の低下を招きそう。