パスワードを忘れた? アカウント作成
14420083 journal
日記

yaegakiの日記: 字下げの記憶 15

日記 by yaegaki

hogefunc(arg1,
     arg2,
     arg3)
ある時からこういう字下げはやらなくなった。

確かきっかけはコーディング規約の字下げルールをどう記述するか考えたとき
・1つの文を複数行に分ける場合は1タブ字下げする
こうすると上の例は規約違反になる。ムリに適用するとこうなる。
hogefunc(arg1,
        arg2,
        arg3)
これが気持ち悪いからarg2の前にスペースを入れて調整するというのもわかる。
しかしそのために規約を増やすとしても簡明なルール記述がむずかしい。

そもそも最初の字下げは筋悪に感じる。字下げ幅が関数名に依存している。
なので以下のようにしている
hogefunc(
        arg1,
        arg2,
        arg3)

最近の人とか新しい現場だと、もうこういう細かいことは気にしないのでしょうね。IDEで整形してくれるし

  • by nemui4 (20313) on 2020年09月25日 15時24分 (#3894990) 日記

    一行にしたらあきまへんか

    hogefunc(arg1,arg2,arg3)

    要素が沢山あったら見にくくなりますね。

    ここに返信
  • by Anonymous Coward on 2020年09月25日 12時23分 (#3894827)

    Pythonにするのはやめよう。

    ここに返信
  • by Anonymous Coward on 2020年09月25日 14時13分 (#3894943)

    引数とカンマの間にもスペースとか。

    規約自体は(左揃えの場合)「複数の引数は改行する」「引数の頭を揃える」でシンプルに指定できる。
    VisualStudioやReSharperなんかにもあるんじゃないかな。

    ここに返信
    • by yaegaki (47415) on 2020年09月25日 16時11分 (#3895021) 日記

      引数が複数の場合に、改行を強制したくはないです。
      んー、例えばこうなるかな。イマイチだけど。
      ・1つの文を複数行に分ける場合は1タブ字下げする
      ・このとき、関数引数を含む場合は、1行に1つの引数とする

      • by Anonymous Coward

        どちらかというと複数行に分ける場合を制御した方が良い。
        「『本文中で』1つの文を複数行に分ける場合は1タブ字下げする」とかね。
        クラス定義では~とか関数定義では~とか細かく制御できる。

        引数が複数の場合も、単に例示が強制改行なだけで「引数の定義が○文字目にかかる場合」などでも良い。

        • by Anonymous Coward

          自然言語で書かれている(人間が読んで手動で適用する前提の)時点で駄目

          • by Anonymous Coward

            実際にIDEなどでも行えるリファクタリングの例ですが?
            今時のIDEはコンテキストも把握しているんですよ。

  • by Anonymous Coward on 2020年09月25日 22時19分 (#3895276)

    関数や条件式の開き括弧の後ろ, 同閉じ括弧の前, カンマの後ろ, ぐらいには空白があると見易いけど、
    そういう意味以上に規約で見かけをがんじがらめにするのは労ばっかりで益は乏しいんじゃないかな?
    そんなのより、どういう単位で機能を分担させるか、外部変数の持ち方、変数やオブジェクトの寿命を見えるようにするとか、思想や方針を縛ったほうがいいと思うんだけどな。
    # コメント行中に開き括弧だけとか,パターンマッチ演算子のデリミタに#を使うとか、エディタが混乱するようなのは避けるようにするけど。

    ここに返信
    • 機能の分割、変数スコープなどの方が大切なのはそうだと思います。

      規約を作ったのは経験の浅いのメンバーが入ってしばらくした頃で、
      自由に書いてもらうとやっぱり読みづらかったんですよね(C言語だったし)
      守破離というわけでもないが、はじめは(厳しめの)規約に従って書くのが学習の近道かと思いまして……

      • by Anonymous Coward

        車輪の再発明するより、有力どころをいくつか見繕って、その中から一番妥当だと思うのを選ぶのがいいかとおもいます。
        そして実情にあわないところだけ補正すると。
        私なら Linux kernel coding styleをベースにしたいですね。

    • by Anonymous Coward

      見やすさ=チェックしやすさですよ。
      究極的にはブロックなど存在せずすべて関数に投げればいいのですが、
      関数ごとにテストが必要なんて規約だったりするとテスト量が増えます。
      見かけの規約というのはどこにバランスを取るかの指針であり重要な項目です。
      つまり

      どういう単位で機能を分担させるか、外部変数の持ち方、変数やオブジェクトの寿命を見えるようにするとか、思想や方針を縛ったほうがいい

      というのを「見かけ」という項目で誘導しているのです。

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...