Linuxカーネルのコーディング規約、1行80桁の制限を撤廃 86
ストーリー by hylom
最近は自動折り返ししてくれるエディタもありますし 部門より
最近は自動折り返ししてくれるエディタもありますし 部門より
headless曰く、
Linuxカーネルのコーディング規約から、1行を80桁以内とする制限が撤廃された（Linus Torvalds氏のメーリングリスト投稿、checkpatchのコミットメッセージ、Phoronix、The Register）。
Linus Torvalds氏によれば、多くの人が80桁のターミナルを使わなくなって久しく、1行80桁制限は合理的でないという。桁数制限は必要以上の改行を生み、さまざまな問題を引き起こす。中には小さなターミナルウインドウを使用している人もいるという主張もみられるが、何を使うのもその人の選択だ。そのハードウェアの制限を全員が共有する必要はない。長い行は単純に有用であり、どこかで改行が必要になるにしても80桁に制限する理由はまったくないとのこと。
これに伴ってcheckpatchでも80桁を超える行に対する警告表示が廃止されている。1行を80桁以内に収めることは現在でも望ましいが、checkpatchがわざわざ警告を表示するほど明確な制限ではない。デフォルトでは制限値が100文字まで増加しているが、こちらも明確な制限に基づくものではなく、行が若干長めになっても警告なしで収まる程度の文字数が選択されているようだ。
80桁もある自由 (スコア:1)
1カラム目 : 「C」を書いたらその行はコメント
2～5カラム目 : 行番号を書く
6カラム目 : このカラムが空白以外の場合前行から継続
7～72カラム目 : 本文
73～80カラム目 : システム予約(シーケンシャル番号)
本文として記述できるのは66桁分。
＃なんとかなるもんだ
Re: (スコア:0)
「PCメーラーで見やすい」と「スマホメーラーで見やすい」は違うんだよねえ。
Re: (スコア:0)
スマホちょっと傾けるだけで画面回転出来るんだから、横画面で読めばいいじゃない
Re: (スコア:0)
66桁ならFORTRAN77と同じなので、十分なのは当然でしょう
そもそもなぜ80文字か (スコア:0)
パンチカードの幅から来ているという話を聞いたことがあります
# 自分はBASICでwidth 80,25から
Re:そもそもなぜ80文字か (スコア:1)
＞# 自分はBASICでwidth 80,25から
自分もそっちだな。
解像度の問題で100文字がかなりきつい時代もあったから、
80文字が少ないと言えるようになったのはわりと最近の話だと想う。
増やすにしても一行80文字が100～120文字になるくらいだし、
その場合でも多くの行が80文字に収まるんだろうけど。
一行300～500文字なんてソースは、もう二度とメンテしたくない。
＃ステップ実行で動作確認。
＃ずっと同じ行じゃねーかーーー！
Re: (スコア:0)
まあどうでもいいというか、ではなぜパンチカードは80文字なんだ？
Re:そもそもなぜ80文字か (スコア:3, 興味深い)
コンピュータ用パンチカードを1ドル紙幣サイズで定義して
パンチカードの穴を丸から長方形に変更して拡張したときの桁数が80だったらしい。
Re:そもそもなぜ80文字か (スコア:1)
パンチカードとどちらが先か調べていませんが
FORTRANの固定形式だと72桁までしか有効じゃなくて
あと8桁は、エディターが管理用にしていました。
時々長すぎる行を作るとエラーになって、なんでと
悩むことが時々ありました。
maruken
Re: (スコア:0)
機械の精度とか、人間の見やすさとか色々あると思うが、現代人も割となじみのあるマークシートで考えれば分かると思う。
Re: (スコア:0)
古い言語で変数が2文字までとかで
Re: (スコア:0)
そーいや、昔80桁のプリンターとかあったなぁ。
今でもピンフィード式の（ドットインパクト）プリンターはあるが、80桁幅のモデルはほぼなくなった筈。
Re:そもそもなぜ80文字か (スコア:2)
136桁が主流ですが80桁もそれなりにありますよ [epson.jp]
それにしても、80桁と136桁は昔ながらの印刷幅ですが、106桁ってなんだろう…
Re:そもそもなぜ80文字か (スコア:1)
推測ですが、アメリカ政府の旧レターサイズが8x10.5インチだったからじゃないかと。
（プリンタの1桁は0.1インチ換算）
80桁ならポートレート、106桁ならランドスケープで紙が置けるので。
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)
最近は関数型言語でクロージャとか使ってインラインに書くのがかっこいいと思ってるからインデント深くなっていくんじゃないのか。
120カラムで足りないというのはちょっとやりすぎな気もする。
# クラス名が３０文字くらいあることはまれによくある。
Re: (スコア:0)
いちいち名前つけて遠くに定義するより中身の見える短いコードが近くにあった方が読みやすいからだよ
変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
Re: (スコア:0)
中身のわかる短いコードが近くにあるほうが見通しがいいのはわかるけど、
インデントだけで30桁(4桁インデント想定だと8個ぐらい？)にまで深くなるようなのは、明かに見通しが悪くなってる例だから、ちゃんと名前つけるなりして外に出したほうがいいぞ。
ちなみに処理内容そのものがそこにあるより、名前つけて外に出したほうが一般的には見通しがいい。
見通しが悪くなるのは、唯一名前が変なときだけだ。
> 変数や関数を宣言するたびに台帳に記入して連番で意味わからん名前を割り振ってた時代に戻りたいのかよ
そういう組織がある(関わったことないけど)だけで、そんな時代は存在しない。
Re: (スコア:0)
それ難読化して元のコードを失くしちゃったから、みたいなシチュー?
Re: (スコア:0)
宣言するたびにというのは嘘だろうが、台帳に記入して連番で意味わからん名前を割り振ってた時代は確かにあるぞ
ABENDするたびにCBL00235やらJCL0AC6やら、紙の台帳ひっくり返していたものじゃよ
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)
こういう人間が長い関数を馬鹿みたいに量産してバグを大量に発生させるわけだ
ラインプリンタは136文字（だったかな？） (スコア:0)
ソースコードを80字以内にしても、アセンブルリストでは行番号、アドレス、アセンブルされた機械語を印字し、各々スペースも入れるから80字/行のプリンタでは足りなかったな。あと、大型機（汎用機）は15インチ×11インチの連続LP用紙が標準だったね。
Re: (スコア:0)
15インチ幅の用紙だと136桁ですね。
用紙長が11インチの連続紙だと、スプロケットホールは22穴/頁で、66行/頁が一般的。
スプロケットホール間は0.5インチなんて事を覚えておくと、何かの役に立つ時が来るカモ。
主観 (スコア:0)
主観だけど、JavaやC#は横に長くなるイメージ
やたら横に長くて可読性悪いコード書く人いるよね。
そういう人はバグ多そうだなって思う。
Re: (スコア:0)
野坂昭如センセーみたいなプログラマがいたっていいじゃない
＃ ただし、俺の業務や職場には関係ないところに
Re: (スコア:0)
変数名を30文字ぐらいの長さにする人はif文で4つand条件を取るだけで1行100文字越えとか簡単に行くよな。あとはtab=8でインデントする人のソースコードも無駄に横に伸びる。昔は行が長くなるといえばマルチステートメントが原因な事も多かったけど、最近は以前ほど多用(悪用)する人は減ったような気がする。
で、誰だよ、無駄に横に長く書くのは。
Re:主観 (スコア:2, おもしろおかしい)
> で、誰だよ、無駄に横に長く書くのは。
お前だよお前
少しは改行しろよ
Re: (スコア:0)
> if文で4つand条件を取るだけで
そもそも if (A && B && C && D) なんてコードを書いてる時点で駄目ですよ
Re: (スコア:0)
FPGA屋だとLCやLEのLUTのbit数からif文の条件数を考える、
というバッドノウハウが今でも一部で残ってますね。
いつまでも20年以上前の設計手法はどうかと思うけど
実際小さくて実行が早い合成がしやすいし…
Re:主観 (スコア:2)
ちなみにオレならこう。
差分がとりやすいから。
if (true &&
A &&
B &&
C &&
D &&
true) {
/* ... */
}
Re: (スコア:0)
変数名が長くなると、ソースコードの行幅も、
どうしても長くなってしまいますね。
桁数を増やすな！ (スコア:0)
行数が少なくなって値切られるだろ！
遅すぎでしょ (スコア:0)
10年前でも最小値は120カラムぐらい
wrapper (スコア:0)
ちょっと思いついたが、コンピューター言語向けにルールを作った
テキストラッパーをつくって表示改行すれば、論理改行を文字数で
決めようなんて必要はなくなるんじゃない?
Re:wrapper (スコア:1)
改行だけじゃもったいないよ
特別なキーワードに色付けをする機能もつけたら
表示がすごく見やすくなりそう
Re: (スコア:0)
それはもうあるだろ。
プログラム言語用のテキストラッパーもあるのか?