yaegakiの日記： 字下げの記憶 15
日記 by
yaegaki
hogefunc(arg1,
arg2,
arg3)
ある時からこういう字下げはやらなくなった。
確かきっかけはコーディング規約の字下げルールをどう記述するか考えたとき
・1つの文を複数行に分ける場合は1タブ字下げする
こうすると上の例は規約違反になる。ムリに適用するとこうなる。
hogefunc(arg1,
arg2,
arg3)
これが気持ち悪いからarg2の前にスペースを入れて調整するというのもわかる。
しかしそのために規約を増やすとしても簡明なルール記述がむずかしい。
そもそも最初の字下げは筋悪に感じる。字下げ幅が関数名に依存している。
なので以下のようにしている
hogefunc(
arg1,
arg2,
arg3)
最近の人とか新しい現場だと、もうこういう細かいことは気にしないのでしょうね。IDEで整形してくれるし
ようしらんけど (スコア:1)
一行にしたらあきまへんか
hogefunc(arg1,arg2,arg3)
要素が沢山あったら見にくくなりますね。
Re:ようしらんけど (スコア:1)
Re:ようしらんけど (スコア:1)
補足感謝です。
この点もどれくらいなら改行するかと判断に迷うことがあるんですよね……
80カラム目までに納めろ、とかいうプロジェクトもあったなあ
Re:ようしらんけど (スコア:1)
80桁未満改行ルールはたまに有りますね。
古いターミナルでの作業とか、パソ通時代が懐かしいです。
だからといって (スコア:0)
Pythonにするのはやめよう。
Re: (スコア:0)
ぢゃ、ABCで頼む。
左揃えと右揃え (スコア:0)
引数とカンマの間にもスペースとか。
規約自体は(左揃えの場合)「複数の引数は改行する」「引数の頭を揃える」でシンプルに指定できる。
VisualStudioやReSharperなんかにもあるんじゃないかな。
Re:左揃えと右揃え (スコア:1)
引数が複数の場合に、改行を強制したくはないです。
んー、例えばこうなるかな。イマイチだけど。
・1つの文を複数行に分ける場合は1タブ字下げする
・このとき、関数引数を含む場合は、1行に1つの引数とする
Re: (スコア:0)
どちらかというと複数行に分ける場合を制御した方が良い。
「『本文中で』1つの文を複数行に分ける場合は1タブ字下げする」とかね。
クラス定義では～とか関数定義では～とか細かく制御できる。
引数が複数の場合も、単に例示が強制改行なだけで「引数の定義が○文字目にかかる場合」などでも良い。
Re: (スコア:0)
自然言語で書かれている(人間が読んで手動で適用する前提の)時点で駄目
Re: (スコア:0)
実際にIDEなどでも行えるリファクタリングの例ですが？
今時のIDEはコンテキストも把握しているんですよ。
枝葉末節にこだわっても (スコア:0)
関数や条件式の開き括弧の後ろ, 同閉じ括弧の前, カンマの後ろ, ぐらいには空白があると見易いけど、
そういう意味以上に規約で見かけをがんじがらめにするのは労ばっかりで益は乏しいんじゃないかな？
そんなのより、どういう単位で機能を分担させるか、外部変数の持ち方、変数やオブジェクトの寿命を見えるようにするとか、思想や方針を縛ったほうがいいと思うんだけどな。
# コメント行中に開き括弧だけとか,パターンマッチ演算子のデリミタに#を使うとか、エディタが混乱するようなのは避けるようにするけど。
Re:枝葉末節にこだわっても (スコア:1)
機能の分割、変数スコープなどの方が大切なのはそうだと思います。
規約を作ったのは経験の浅いのメンバーが入ってしばらくした頃で、
自由に書いてもらうとやっぱり読みづらかったんですよね（C言語だったし）
守破離というわけでもないが、はじめは（厳しめの）規約に従って書くのが学習の近道かと思いまして……
Re: (スコア:0)
車輪の再発明するより、有力どころをいくつか見繕って、その中から一番妥当だと思うのを選ぶのがいいかとおもいます。
そして実情にあわないところだけ補正すると。
私なら Linux kernel coding styleをベースにしたいですね。
Re: (スコア:0)
見やすさ＝チェックしやすさですよ。
究極的にはブロックなど存在せずすべて関数に投げればいいのですが、
関数ごとにテストが必要なんて規約だったりするとテスト量が増えます。
見かけの規約というのはどこにバランスを取るかの指針であり重要な項目です。
つまり
どういう単位で機能を分担させるか、外部変数の持ち方、変数やオブジェクトの寿命を見えるようにするとか、思想や方針を縛ったほうがいい
というのを「見かけ」という項目で誘導しているのです。