寫代碼時大括弧該不該換行？

01-07

對於代碼中大括弧換行的問題，一直不是很明確，換行和不換行各有什麼優缺點，反正我是兩個混用（逃
補充:
左大括弧前加不加縮進？
縮進用空格還是tab？
"="兩邊加不加空格？

看你寫什麼代碼。我寫javascript、java、php的時候是不換行的。寫C++、C#的時候是換行的。

題主這是要引發戰爭啊

可以換，可以不換，沒什麼應該不應該，但是儘可能在同一種語言中保持一致。

不換的好處？行數少，不佔地方。

換行，看起來清楚那麼一點點，但是佔地方。

謝邀，我沒有這個困擾：

沒什麼好討論的，打架吧

保持自己的風格並堅持不變的用下去

無所謂，主要還是看IDE，Eclipse中方法頭寫好了前大括弧不換行後大括弧自動另起一行。VS兩個大括弧都獨立各成一行。

換行。

嘛，倒不如問問不換行的各位究竟要不要在大括弧前加空格（手動滑稽）

來來來各位撕起來（滑稽）

@楊大濕補充：其實等號兩邊加不加空格也可以撕起來…（手動滑稽）

取決於是否按行計費

這個還得看個人習慣和團隊規範

當一回搬運工，我覺得下面這篇文章可以幫助理解「大括弧是否要換行」這場爭執的歷史。

哪種編碼風格是你的「菜」

每個程序員都有自己的編碼風格，這基本上都是由他們的喜好決定的，此外，程序員還樂於爭論各種編碼風格的優劣，比如關於Tab和空格（見《Tab v.s. 空格：一個永恆的神聖戰爭》、《空格「異教徒」去死》）、80列規則（見《保衛80列規則》），還有大括弧的縮進風格等。
一致的編碼風格，更便於閱讀。因此程序員都想極力說服別人認同並使用與自己一致的編碼風格。下面來了解一下我的編碼風格變化歷程吧。
1980/1990年代的緊湊風格

當我開始編程時，我使用tab字元，因為使用它保存的文件更小，還可以將代碼限制到80列。我還遵循Kernighan和Ritchie的《C Programming Language》一書中約定的「大括弧放在同一行」規則，代碼看起來是這樣的：
int main(int argc, char *argv[]) { int a = rand() % 100; if (a &> 25) { call_a_function(); call_another_function(); } else { call_b_function(); } // end if } // end main
當時Tab縮進默認為8個字元寬度，這意味著你不能縮進過多，以免打破「80列」寬度的限制，這也迫使你寫更少、更精簡的函數名或代碼（這是好事）。大括弧在同一行上，意味著可以在一頁中顯示更多的代碼。
但也有一些不好的事情。我們開始使用更短的變數名，這使代碼更難以閱讀和維護。我們在代碼行之間沒有添加任何空白行，結果很難找到代碼塊開始和結束標記（因此我們必須在代碼塊結束的地方加上注釋）。由於縮進太寬，留給我們的編碼空間就少了。
2000年的寬鬆風格

在2000年，我以及周圍的程序員基本上都已經切換到了微軟的C/C#約定上，即使用4個空格，而不是Tab，不限制代碼行的長度，大括弧單獨一行。如下：
int main(int argc, char *argv[]) { int a = rand() % 100;
if (a &> 25) { call_a_function(); call_another_function(); } else { call_b_function(); } }
空格縮進意味著我們不必處理不同編輯器中Tab大小（Tab大小可以根據用戶喜好進行設置）。我們使用空行，以使代碼更易於閱讀。單獨一行的大括弧使代碼塊更加明顯（可以很快找出開始和結束點）。
但是，這也導致了一些問題。由於行長度（大屏幕）無限制，我們不再感覺必須要限制縮進的數量，並開始創建更大更長的代碼。由於當時的編輯器無法很好地格式化代碼，程序員經常會在水平滾動時無法看到左側的代碼。代碼變得難以閱讀，並排比較更困難。
因此，在2000年初，我選擇使用4個空格來縮進，依然遵循80列規則，將大括弧單獨放在一行中，以改善可讀性。

2010年的典型風格
現在，我開始使用Xcode 4。Xcode中默認為4個空格縮進，保持不變，還可以智能格式化代碼，不會出現滾動到右邊看不到左邊代碼的情況。但是，令我鬱悶的是，默認代碼片段中大括弧竟然不一致，有時單獨一行，有時和代碼共用一行。
看看默認的initWithNibName代碼片段：
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]; if (self) { self.title = NSLocalizedString(@"Detail", @"Detail"); } return self; }
事實證明，蘋果沒有弄錯。它使用了正確的Kernighan Ritchie風格，在早期C語言書籍中是為了節省空間才將所有大括弧放在代碼後面的。根據維基百科，KR風格是：
「當秉承K＆R時，每一個函數左括弧都應在下一行中，並與開頭行有相同的縮進。括弧中的語句應該縮進，右括弧應該與函數開頭有相同的縮進，並單獨一行。對於代碼塊內的控制語句，左括弧應與控制語句在同一行中，右括弧單獨一行（除非有else或while關鍵字）。」

事實上，這是典型的KR風格，針對所有的C衍生語言，包括C++、C#和Objective-C。這是語言本身的設計者所遵循的風格。
因此，我也改變了我的括弧使用風格，我仍然使用空格縮進，仍然遵循80列寬度原則，但現在更多依賴於編輯器來進行代碼格式化。不過，我現在堅持真正的K＆R括弧風格。
int main(int argc, char *argv[]) { int a = rand() % 100;
if (a &> 25) { call_a_function(); call_another_function(); } else { call_b_function(); } }
英文原文：Reprogramming My Brace Style Mind

正如一位長者所說，一個人代碼風格的養成，不僅要靠個人的奮鬥，也要考慮歷史的進程。

不換行可以顯示更多的代碼，習慣了看起來更舒服。

特別是顯示器不太大的時候。

看了你的問題描述，強烈建議你看一本書《代碼大全》，這是一本編程規範的書，即便編程經驗很多的老鳥，也有學習的必要！

你的問題在第31章布局與風格那塊

不想看給你總結一下，用風格2的任意一種

騷年你這是在玩火！{

「啊！」}

0. =兩邊必加空格

1. if,while,for大括弧{}必換行

2. 我連public static void main(String[ ] args)大括弧我都換行，你來咬我啊

3. 變數後面，逗號，分號後面，我都空格

想換就換，不想換就 →_→ go to die

Js使用Eslint extends Airbnb

看心情。

我也是混用的，寫函數、類、結構體定義的時候換行，寫邏輯控制語句的時候不換行，因為感覺這種風格看起來簡潔很多。

醬紫不算異端吧？

public static void main(String[] args){ String str = "換行的都是異端！！！"; System.out.println(str); }