if (condition) {
    // 処理
}

if (condition)
{
    // 処理
}

皆さんは波括弧の開始位置、改行する派でしょうか？しない派でしょうか？

自分は最初に読んだコードが改行しないスタイルだったので、そのまま改行しない派になりました。雛鳥の刷り込みと同じで、最初に見たものが正義になってる自覚があります。

そもそもこの論争ってなぜ生まれたんでしょうか。言語やコミュニティごとに主流が分かれているのも不思議で、歴史的な経緯をご存じの方がいれば教えてほしいです。

また、

自分のスタイルを選んだ理由
チームで流派が割れたときどうしてるか

も知りたいです！

回答18件

cametan

総合スコア386

投稿2026/08/20 05:09

改行しない派。
ただし、SpacemacsのC/C++モードではClangのフォーマッタが効いてる為、個人の好みに関係なく改行される。

原則、このテの事に対しての熟考は時間の無駄なんで、(あれば)フォーマッタのデフォルト挙動に任せている。
JavaScriptでもDenoのフォーマッタ任せで、自分じゃ何も考えないし、逆に言うと、フォーマッタが揃ってない言語ないしは実装を使うのはツラい。

Orchard

総合スコア148

投稿2026/08/20 06:48

改行しない派です〜。
大学では教授の思想に学期ごとに振り回されてきたので、もう自由にしてほしいというのが正直なところですね…。
ちょっと趣旨からは外れますが、どちらか派というよりはGoのように特定の書き方を強制するのはやめて欲しいなという気持ちはあります。ただ最近はフォーマッター使ってますし、そもそもあんまり手書きすることがなくなってしまったので以前ほどこだわりはありませんが。
歴史はちょっとしか調べてませんが、C言語の開発者が「プログラミング言語C」で改行しないスタイルを示して、その後10年くらい経って画面が大型化して行数を節約する必要が薄まってきた頃に提唱されたのが改行するスタイルみたいです。

yambejp

総合スコア118632

投稿2026/08/20 07:26

中途半端な回答で微妙ですがなんとなく場合分けをしてます

分岐は入れないけど
クラスや関数の宣言は入れて
アロー構文やコールバック用の無名関数にはいれない

明確な理由はとくにないですが、PHPマニュアルの記載に習っています。

入れない

javascript
1if(条件){
2処理;
3}
4for(let i=0;i<10;i++){
5処理
6}
7while(条件){
8処理
9}
10switch(条件){
11ラベル:
12処理
13}

入れる

javascript
1class hoge
2{
3  myfunc()
4  {
5    処理
6  }
7}
8function fuga()
9{
10  処理
11}

関数だけど入れない

javascript
1const hoge=()=>{
2処理
3}
4document.addEventListener('click',function(){
5処理
6});
7document.addEventListener('click',()=>{
8処理
9});

cametan

総合スコア386

投稿2026/08/20 07:58

多分、「改行する派」としてはGNUのコーディングスタイルの影響が大きいんだろうなぁ。

Formatting Your Source Code

多分この形式に則ってる人は結構いる?Linux(っつーかモロGNUか)のソースコード読むとこの形式で書かれていて、結果、これ読むに慣れると当然この形式で書く事になれちゃうだろうし。

実の事言うと、個人的にはGNUスタイルはあまり好きくないんだけど、一方、「自分で考える」のは面倒くさいし、この辺やっぱ、あまり本質的じゃないし。
結果、なんだかんだ言って、「既成品」に乗っかる、って判断も悪くないよね。「それが正しいから」じゃなくって、単にデファクトスタンダードに則った方がいいでしょ、的な事だね。文書化されていればそれに対抗して新たに何かを文書化すんのもメンドイし。
そう、全ては「面倒くさい」のだ(笑)。考えたくねぇのだ(笑)。

Germaine

総合スコア77

投稿2026/08/20 08:20

まだ不慣れで勉強しながら開発中なのもあって、教材やネットに載っているものを見て改行するものなんだな、という理解で改行してました。
見やすくなるようにかな？と納得してたんですが、改行しない派が多いんですね！改行しない派の方々の理由気になります！

cametan

総合スコア386

投稿2026/08/20 08:51

編集2026/08/20 08:54

改行しない派の方々の理由気になります！

個人的には、改行で縦にソースコードが長くなって、要スクロールになりそうなのが嫌、ってのがあるかな。1関数はスクロールせずに全部視認できるもの、ってのが個人的には望ましいんで・・・・・・。
ただ、この辺はぶっちゃけ、機材によっても印象変わると思うよ。高解像度のバカデカモニタ使ってる人の「スクロールせずに」と言うのと、そうじゃない人、そこそこショボい解像度のノートパソコン使ってる人の「要スクロール」の基準は違うだろうしね。
そもそも、本来やっぱ、こういった話ってのは「個人個人の環境が違えば話が変わる」ってのがフツーだろうし。その辺統一的にやろう、ってのがそもそも無理がある話でさ(笑)。
あと、言語にもよるでしょ。例えばRubyとかいい言語だけど、視認性考えた時、「endで一行取られる」とか我慢できない人も多いんじゃないの(笑)?僕はその辺「だけ」がどうしてもRubyの嫌なトコでさ(笑)。Pythonなんかに較べると同じ内容書いても縦に長くなる、ってのがやだな、とか(笑)。
そういう人も結構いるんじゃなかろうか。

まぁ、これも古い話になるんだけど。もともと、1関数は12〜14行くらいに抑えよ、って言ったのはバーバラ・リスコフって計算機科学者だったみたいなんだけど。
この「基準」ってのは古い時代のモニタ画面に収まる行数とか、あるいはプリンタ・・・多分当時はドットプリンタとかか(笑)、で紙一枚に印字出来る量だったんじゃないかしらん。それを超えると視認性が悪くなる、と。
でもある程度これって現代でも通じる話で。オブジェクト指向でもクラスでの枠組みはさておき、やっぱメソッドが「12行〜14行を超える」となると「なんか余計な事を詰め込んでて切り分けた方が良い」サインだとは思ってる。
ただ、その「12行〜14行で関数を〆たい」って時に改行で1行取られるのは致命的だよな、と(笑)。
個人的な感想ね?まぁ、そんな事を感じておりまする。まる。

総合スコア51

投稿2026/08/20 09:12

改行しない派です。学校の試験で紙にコード書かなければいけなかったせいで、なるべく少ない行数で書くようになりました。

ちなみに、波括弧がいらないコード（一行のif文など）を書く場合、絶対波括弧を書かない派です。

hiroki-o

総合スコア1911

投稿2026/08/20 11:06

大前提として

プロジェクトのコーディング規約に従う
既存ソースに手を入れる場合は、周辺の書き方に従う

は、皆さんOKだと思います。(念のため)

何十年か前の記憶ですが、括弧の付け方には以下の3種類があります。
K&R

XXXX {
}

Microsoft

XXXX
{
}

GNU

XXXX
    {
    }

私の場合、まっさらから書く場合は、C/C++はMicrosoft、PythonはK&Rですね。
職業プログラマーとしての始まりはC/C++だったので、周りがK&Rで書いていても、Microsoft式のほうが新しくてカッコいいと勘違いしていました。若気の至りですが、今でも続いています。
Pythonは、ここ何年かで始めたので、周りの常識に従っています。

#7
私は1行でも括弧を書く派です。

yambejp

総合スコア118632

投稿2026/08/20 11:44

学校の試験で紙にコード書かなければいけなかったせい

紙に書く場合はいわゆる80カラムルールを適用してむしろ行を多く使うことになりそうですけどね

PHP
1<?php
2class hoge
3{
4    public static function fuga(
5        int $a,
6        int $b,
7        ):int
8    {
9        return $a + $b;
10    }
11}
12echo hoge::fuga(10,20);

たとえば引数を改行したり、関数の戻り値の型を宣言したりすると波括弧は開業したほうが自然に見える気がします

#10

u2025

総合スコア320

投稿2026/08/20 13:21

if文の場合入れない派です。他の人のコードを読んだ時に、改行が入ってると何処で終わってるのか読みづらくelseやelse if, ifの繋がりに関して混乱したからです。まあその人の書くコードが特別酷いというのがあるのですが、行間もとるし入れなくていいと思います。

ほかの回答を見て気づきましたが、関数やforの場合どっちでもいいですね。
C#とかだったらエディタが勝手に入れてくると思いますが、デフォルトの設定に従います。

まあ、本末転倒ですが実際にはプロジェクトのコードに合わせます。
自分の考えとしてはそうだ、という感じです、

コーディング全体の責任者的立場ですが、コーディングルールなんて誰も従ってくれないんで。

#11

fana

総合スコア12498

投稿2026/08/21 02:34

改行する派です．
そうなった理由は「最初に触れたコードがそうだった」程度の話かもしれませんが．

とりあえず { と } の対応関係が見た目に把握しやすいと思っています．
というか，私の頭が
「同一インデントの { と } を目視することでブロックを認識する」
という形に訓練(?)されてしまっている様子なので，改行無しコードはちょっと苦手……

あと， { に続けてコメントを書くという微妙な癖があるので，改行無しだときつい．

C++
1if( Catful() && !CatNapDisaster() )
2{//コメント（一行で済む場合，ここに書くので）
3  /*...*/
4}
5
6//---
7
8if( Catful() && !CatNapDisaster() ){//コメント（これだとちょっと見難い）
9  /*...*/
10}

#12

showark

総合スコア1

投稿2026/08/25 00:47

最初にきちんと習得した米某社の制御システム専用言語では改行が推奨だったので改行派です。

#13

fana

総合スコア12498

投稿2026/08/25 01:35

1行でも括弧を書く派

私もそうですね．
{} の「複文がどうので～云々」いう文法面の話はともかく，範囲が明確（「明示的」かな）みたいな面の理由で…かな？

あ，でも例外的に，単純な break とか return の場合は書かないですね．
if( XXX )return;　←こういうの．

処理の場合は括弧で囲むけど
if( XXX ){ 処理 }
って書くとデバッガのステップ実行とかがうまくいかなくて「クソオォォ」とかなるので，改行して

if( XXX )
{  処理  }

っていう形になります．

なんか，単文でも括弧を付ける理由として「括弧無しだと後で修正したときにバグりやすい（下記）」的な話を聞いたことがある気もしますが，そんなレアすぎるケースのことまでは考えてないかな．

//元々こうなってたのを……
if( XXX )
  YYY;

//こう書いてバグる奴がいたんですよー
//なーにぃー？　やっちまったなぁ！
//……みたいな話だったような？
if( XXX )
  YYY;
  ZZZ;  //←おおっと

#14

yambejp

総合スコア118632

投稿2026/08/25 01:53

編集2026/08/25 01:53

1行でも括弧を書く派

javascriptでは構文が用意されていないため「無意識に一行でカッコを省く」処理を書いている人は多いです。具体的には「else if」。javascriptはelseifという構文がないためelseの一行処理を利用してelseif的な処理を書きます
つまり

javascript
1if(条件1){
2//処理1
3}else if(条件2){
4//処理2
5}else if(条件3){
6//処理3
7}else{
8//処理4
9}

というのは、実際には「else if」という構文ではなくelse構文に一行処理でifを書いているだけで実際にはこういう処理です。

javascript
1if(条件1){
2//処理1
3}else{
4  if(条件2){
5  //処理2
6  }else{
7    if(条件3){
8    //処理3
9    }else{
10    //処理4
11    }
12  }
13}

#15

tmp

総合スコア382

投稿2026/08/25 03:35

編集2026/08/25 03:37

同じく最初に見たＣ言語が改行なしだったので、なにもなければ、改行しません。
で、改行する人に聞くと{と}が同じ位置にないと気持ち悪いそうです。私は、if と}が同じ位置で問題ないけど。

#13
まさに、その例にかいてるように間違えた人がいるので、また、運悪くコピペでその例にように並んでしまったようです。で「俺は悪くない単文を書くやつが悪い」という強い信念？により、実際、複文にする手間もないので、ifの処理の単文禁止にしました。

#16

Chironian

総合スコア23279

投稿2026/08/25 06:15

編集2026/08/25 06:24

私は圧倒的に改行派です。

改行しないスタイルはK&Rスタイルと呼ばれることが多いようです。
有名なカーニハンとリッチーのプログラミング言語Cのサンプルの記述スタイルから来ているようです。
改行する方はオールマン・スタイルと呼ばれているようです。
字下げスタイル

これらを含めて、生産性に影響する記述方法は何かを研究した論文では、オールマン・スタイルの方が可読性が高いと記載されているようです。

私自身は、改行しない方式もトライしたことがありますが、結局改行する方式に戻りました。
{と}が同じインデントに存在するとブロックの範囲を識別しやすいため、生産性があがると強く感じます。
逆にずれているとブロック範囲を判別するのに注意力を無駄に消費し、他に注意するべき部分への注意力が削がれると実感しました。

#17

cametan

総合スコア386

投稿2026/08/25 06:41

2014年のAppleのSSL/TLS実装で起きたCVE-2014-1266バグか。

C
1// 波カッコを省略していた実際のコードイメージ
2if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
3    goto fail;
4if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
5    goto fail;
6    goto fail; // ← インデント事故で追加された2つ目の goto fail
7if ((err = SSLHashSHA1.final(&hashCtx, &hash)) != 0)
8    goto fail;