パスワードを忘れた? アカウント作成
14202475 story
プログラミング

Linuxカーネルのコーディング規約、1行80桁の制限を撤廃 86

ストーリー by hylom
最近は自動折り返ししてくれるエディタもありますし 部門より

headless曰く、

Linuxカーネルのコーディング規約から、1行を80桁以内とする制限が撤廃された(Linus Torvalds氏のメーリングリスト投稿checkpatchのコミットメッセージPhoronixThe Register)。

Linus Torvalds氏によれば、多くの人が80桁のターミナルを使わなくなって久しく、1行80桁制限は合理的でないという。桁数制限は必要以上の改行を生み、さまざまな問題を引き起こす。中には小さなターミナルウインドウを使用している人もいるという主張もみられるが、何を使うのもその人の選択だ。そのハードウェアの制限を全員が共有する必要はない。長い行は単純に有用であり、どこかで改行が必要になるにしても80桁に制限する理由はまったくないとのこと。

これに伴ってcheckpatchでも80桁を超える行に対する警告表示が廃止されている。1行を80桁以内に収めることは現在でも望ましいが、checkpatchがわざわざ警告を表示するほど明確な制限ではない。デフォルトでは制限値が100文字まで増加しているが、こちらも明確な制限に基づくものではなく、行が若干長めになっても警告なしで収まる程度の文字数が選択されているようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2020年06月04日 13時59分 (#3827263)

    1カラム目 : 「C」を書いたらその行はコメント
    2~5カラム目 : 行番号を書く
    6カラム目 : このカラムが空白以外の場合前行から継続
    7~72カラム目 : 本文
    73~80カラム目 : システム予約(シーケンシャル番号)

    本文として記述できるのは66桁分。
    #なんとかなるもんだ

    • by Anonymous Coward
      そう言えば、電子メールの1行は72文字までダァー! っていつ頃までだっけ?
      「PCメーラーで見やすい」と「スマホメーラーで見やすい」は違うんだよねえ。
      • by Anonymous Coward

        スマホちょっと傾けるだけで画面回転出来るんだから、横画面で読めばいいじゃない

    • by Anonymous Coward

      66桁ならFORTRAN77と同じなので、十分なのは当然でしょう

  • by Anonymous Coward on 2020年06月04日 13時01分 (#3827222)

    パンチカードの幅から来ているという話を聞いたことがあります
    # 自分はBASICでwidth 80,25から

    • by Anonymous Coward on 2020年06月04日 13時54分 (#3827259)

      ># 自分はBASICでwidth 80,25から
      自分もそっちだな。
      解像度の問題で100文字がかなりきつい時代もあったから、
      80文字が少ないと言えるようになったのはわりと最近の話だと想う。

      増やすにしても一行80文字が100~120文字になるくらいだし、
      その場合でも多くの行が80文字に収まるんだろうけど。

      一行300~500文字なんてソースは、もう二度とメンテしたくない。
      #ステップ実行で動作確認。
      #ずっと同じ行じゃねーかーーー!

      親コメント
    • by Anonymous Coward

      まあどうでもいいというか、ではなぜパンチカードは80文字なんだ?

      • by Anonymous Coward on 2020年06月04日 13時11分 (#3827235)

        コンピュータ用パンチカードを1ドル紙幣サイズで定義して
        パンチカードの穴を丸から長方形に変更して拡張したときの桁数が80だったらしい。

        親コメント
      • パンチカードとどちらが先か調べていませんが

        FORTRANの固定形式だと72桁までしか有効じゃなくて
        あと8桁は、エディターが管理用にしていました。

        時々長すぎる行を作るとエラーになって、なんでと
        悩むことが時々ありました。

        --
        maruken
        親コメント
      • by Anonymous Coward

        機械の精度とか、人間の見やすさとか色々あると思うが、現代人も割となじみのあるマークシートで考えれば分かると思う。

      • by Anonymous Coward
        その頃はそれで足りたんだよ
        古い言語で変数が2文字までとかで
    • by Anonymous Coward

      そーいや、昔80桁のプリンターとかあったなぁ。
      今でもピンフィード式の(ドットインパクト)プリンターはあるが、80桁幅のモデルはほぼなくなった筈。

  • by Anonymous Coward on 2020年06月04日 13時02分 (#3827224)

    パッと目の前のソースコードを見ると長い行では200列程度だった。
    うちスペースインデントが30列程度で、80列表示にしたらほとんどの行が見切れる。
    以前は画面分割で120列程度で書くことが多かったが、120列もちょいきつい。
    一応Visual StudioでのC#開発、しかも自分のコードだから比較的冗長で列が長くても分かるという条件だからC++とは話が変わってくると思う。

    ところで割と話題になってるのに定量的な議論が欠けてる気がする。
    GitHubでホストされてるC++のオープンソースプロジェクトでは~行が~%で、みたいないつもの数字はないのかしら?

    • by Anonymous Coward

      たてよこ

    • by Anonymous Coward

      そこまで深いインデントになるような処理は、関数化するなりして分離したほうがいいと思うぞ。

      • by minet (45149) on 2020年06月04日 17時15分 (#3827383) 日記

        下請けから20段以上ifやforがネストしたコードが納品されてきたことならあったなあ(さすがに書き直させた)
        インデント=4文字幅の規約だったから、インデントだけで80桁超えてたのか。

        親コメント
        • by Anonymous Coward

          書き直させるのは合法だったんでしょうか?
          あらかじめコーディング規約などでネストを制限していたとかならともかく、
          業務委託でかつ仕様を満たしていたとすれば、書き直させるのは、
          わりと違法性が高いのでは(特に下請法とか)?

          • by minet (45149) on 2020年06月04日 20時43分 (#3827544) 日記

            コーディング規約はあって、受け入れのレビューをしたのが自分でした。
            下請けとどういう契約だったのかは当時の自分には分かりませんが(昔の職場での話)、グレーだったのかもなぁ…

            親コメント
            • by Anonymous Coward

              規約に反してたなら要求仕様を満たしていないわけで受け取り拒否でしょ。
              結果として描き直しになるのは違法でもなんでもない。
              反してなければいちゃもんですなぁ。
              インデントが80桁超えるコードを許容するコーディング規約ってのがあるとも思えないけど。

              • by Anonymous Coward

                ネストは何層までとかいう規約がある方が普通ではないのでは?
                目安として「いくら程度まで」というのは可能かもしれないけど、
                それを律儀に守ろうとしてかえって意味不明なコードになることもありそう。

                特に最近は C++ ですら初期化リストみたいな物ができたきたから、
                複雑なオブジェクトの初期化なんかで一気に4,5層くらいのネストは発生しうるから、
                変に制限がぎりぎりだと、チマチマ関数で初期化するわかりにくいコードになってしまう。

                かといってゆるゆるにすればあまり意味がないし。

                あと、C# の using 構文みたいな

                using (...)
                using (...)
                using (...)
                using (...)
                {
                   ...
                }

                のはネストに含むのか含まないのか(ぶら下がり文絶対禁止教の方はどうするんだろう?)。

      • by Anonymous Coward

        最近は関数型言語でクロージャとか使ってインラインに書くのがかっこいいと思ってるからインデント深くなっていくんじゃないのか。
        120カラムで足りないというのはちょっとやりすぎな気もする。
        # クラス名が30文字くらいあることはまれによくある。

        • by Anonymous Coward
          格好つけてるわけじゃねーよ
          いちいち名前つけて遠くに定義するより中身の見える短いコードが近くにあった方が読みやすいからだよ
          変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
          • by Anonymous Coward

            中身のわかる短いコードが近くにあるほうが見通しがいいのはわかるけど、
            インデントだけで30桁(4桁インデント想定だと8個ぐらい?)にまで深くなるようなのは、明かに見通しが悪くなってる例だから、ちゃんと名前つけるなりして外に出したほうがいいぞ。

            ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。
            見通しが悪くなるのは、唯一名前が変なときだけだ。

            > 変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ

            そういう組織がある(関わったことないけど)だけで、そんな時代は存在しない。

            • by Anonymous Coward

              それ難読化して元のコードを失くしちゃったから、みたいなシチュー?

            • by Anonymous Coward

              宣言するたびにというのは嘘だろうが、台帳に記入して連番で意味わからん名前を割り振ってた時代は確かにあるぞ
              ABENDするたびにCBL00235やらJCL0AC6やら、紙の台帳ひっくり返していたものじゃよ

            • by Anonymous Coward

              > ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。

              C++でメンバ関数増やすことになるとヘッダに書くやん?
              そしたらいろいろコンパイルしなおしになるし、クラス内で再利用されたりするかもしれんやん?
              関数内関数とかラムダならそこ考えなくていいしコンパイル遅くならないしつい使っちゃう

              • by Anonymous Coward

                関数の再利用を嫌うならいわゆる関数内関数は対策足り得ません。
                関数内関数は定義された関数内なら再利用できますからね。

              • by Anonymous Coward

                pimpl とか抽象クラスとか知らないパターンですか?

            • by Anonymous Coward

              namespace+class+関数だけで3個、for+if+try{}catch{}で3個、変数スコープの為の{}、ラムダ式やら使うと8段くらいは割と行く。
              ラムダ式があるのだってわざわざ関数にしたくない需要があるからだし、ネスト深いなら関数分けろって考えも古いのかもね。
              一度しか使わないようなprivate関数がたくさんあるのも混乱するし。

              • by Anonymous Coward

                >ネスト深いなら関数分けろって考えも古いのかもね。
                ネスト深いなら、ラムダ式使って分ればいいじゃん。ラムダ式って所詮、関数だろ。

          • by Anonymous Coward

            あほくさ
            連番で名前を付けるとかいうのを引き合いに出すとか

            人間はいろいろな物や概念・事象に名前を付けることによって、この世界を理解し
            人間同士でコミュニケーションをとってきて、ここまで進歩してきたのに、
            無名の処理の方がわかりやすいとか。単に自分の語彙が貧弱なだけじゃねーの?

            • by Anonymous Coward
              こういう人間がJavaみたいなウンコ言語を設計してsetXXX()とgetXXX()を大量に実装させるわけだ
              • by Anonymous Coward

                こういう人間が長い関数を馬鹿みたいに量産してバグを大量に発生させるわけだ

  • by Anonymous Coward on 2020年06月04日 13時32分 (#3827247)

    ソースコードを80字以内にしても、アセンブルリストでは行番号、アドレス、アセンブルされた機械語を印字し、各々スペースも入れるから80字/行のプリンタでは足りなかったな。あと、大型機(汎用機)は15インチ×11インチの連続LP用紙が標準だったね。

    • by Anonymous Coward

      15インチ幅の用紙だと136桁ですね。
      用紙長が11インチの連続紙だと、スプロケットホールは22穴/頁で、66行/頁が一般的。
      スプロケットホール間は0.5インチなんて事を覚えておくと、何かの役に立つ時が来るカモ。

  • by Anonymous Coward on 2020年06月04日 14時05分 (#3827269)

    主観だけど、JavaやC#は横に長くなるイメージ

    やたら横に長くて可読性悪いコード書く人いるよね。
    そういう人はバグ多そうだなって思う。

    • by Anonymous Coward

      野坂昭如センセーみたいなプログラマがいたっていいじゃない

      # ただし、俺の業務や職場には関係ないところに

    • by Anonymous Coward

      変数名を30文字ぐらいの長さにする人はif文で4つand条件を取るだけで1行100文字越えとか簡単に行くよな。あとはtab=8でインデントする人のソースコードも無駄に横に伸びる。昔は行が長くなるといえばマルチステートメントが原因な事も多かったけど、最近は以前ほど多用(悪用)する人は減ったような気がする。

      で、誰だよ、無駄に横に長く書くのは。

      • Re:主観 (スコア:2, おもしろおかしい)

        by Anonymous Coward on 2020年06月04日 19時37分 (#3827497)

        > で、誰だよ、無駄に横に長く書くのは。

        お前だよお前
        少しは改行しろよ

        親コメント
      • by Anonymous Coward

        > if文で4つand条件を取るだけで

        そもそも if (A && B && C && D) なんてコードを書いてる時点で駄目ですよ

        • by Anonymous Coward

          FPGA屋だとLCやLEのLUTのbit数からif文の条件数を考える、
          というバッドノウハウが今でも一部で残ってますね。

          いつまでも20年以上前の設計手法はどうかと思うけど
          実際小さくて実行が早い合成がしやすいし…

    • by Anonymous Coward

      変数名が長くなると、ソースコードの行幅も、
      どうしても長くなってしまいますね。

  • by Anonymous Coward on 2020年06月04日 18時30分 (#3827444)

    行数が少なくなって値切られるだろ!

  • by Anonymous Coward on 2020年06月04日 18時59分 (#3827465)

    10年前でも最小値は120カラムぐらい

  • by Anonymous Coward on 2020年06月04日 19時36分 (#3827496)

    ちょっと思いついたが、コンピューター言語向けにルールを作った
    テキストラッパーをつくって表示改行すれば、論理改行を文字数で
    決めようなんて必要はなくなるんじゃない?

    • by Anonymous Coward on 2020年06月04日 20時02分 (#3827518)

      改行だけじゃもったいないよ
      特別なキーワードに色付けをする機能もつけたら
      表示がすごく見やすくなりそう

      親コメント
      • by Anonymous Coward

        それはもうあるだろ。
        プログラム言語用のテキストラッパーもあるのか?

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...