2010-04-28 38 views
29

哪個是首選(「。」表示空白)?「空行」中的Python縮進

A)

def foo(): 
    x = 1 
    y = 2 
.... 
    if True: 
     bar() 

B)

def foo(): 
    x = 1 
    y = 2 

    if True: 
     bar() 

我的直覺是B(這也是什麼VIM做對我來說),但我請參閱使用人)所有的時間。這是否僅僅是因爲那裏的大部分編輯都被破壞了?

回答

18

PEP 8在這個問題上似乎不太清楚,雖然關於「空白行」的陳述可以被解釋爲支持B. PEP 8樣式檢查器(pep8.py)更喜歡B並且在使用時發出警告一個;不過,這兩種變化都是合法的。我自己的看法是,既然Python在任何情況下都能成功地解釋代碼,這並不重要,並且嘗試執行它將會有很大的收穫。我想,如果你非常堅定地支持這一方,那麼你可以自動將這一方轉換爲另一方。儘管如此,嘗試手動修復所有這些線路將是一項艱鉅的任務,實際上不值得付出努力,恕我直言。

+8

有好的理由支持A - 複製到shell中,B導致一些編輯出現問題。除非A也存在問題,否則似乎是「A在某些情況下有幫助,不會傷害」的情況,因此應該使用A. – Ted 2013-04-17 17:14:06

+1

's/^([\ t] +)([^ \ r \ n] *)(\ r?\ n)\ r?\ n/\ 1 \ 2 \ 3 \ 1 \ 3 /'。搜索:在行首捕捉製表符或空格,捕獲任何非換行符(如果有),捕獲換行符,查找換行符*。替換:縮進,行內容,換行符,縮進,換行符。注意:如果縮進行打開一個新塊,則正則表達式不會檢測到這一點,只是將下一行放在相同的縮進級別。 *我忽略了第二個換行格式,只是使用以前的換行格式來提高一致性 – 2016-08-16 04:41:54

0

Emacs B)對我來說,但我真的不認爲它很重要。 A)意味着你可以在沒有任何標籤的正確縮進處添加一行。

9

該空行屬於foo(),所以我認爲A是最自然的。但我想這只是一個意見問題。

+0

我同意這更自然,我不同意這是一個意見問題。這是事實。 – 2014-08-31 13:58:08

3

我不一定會稱第一個例子爲「破碎」,因爲我知道有些人在代碼中向上或向下移動光標時光標「跳回」時討厭它。例如。 Visual Studio(至少2008)會自動防止這種情況發生,而不在這些行上使用任何空白字符。

28

如果使用一個,你可以複製粘貼在Python Shell塊,將得到意想不到的縮進錯誤。

+0

我嘗試在idlex中使用A,而是得到了無效的語法錯誤。 – obesechicken13 2013-08-11 16:17:20

+0

版本B在複製/粘貼到iPython時無法正常工作。 – Mitch 2015-05-12 18:56:06

+0

@ obesechicken13這些點應該是空格,它們只是畫出來讓你知道它們在那裏。 – pydsigner 2015-08-11 20:52:27

1

我在開源開發方面的經驗是,不應該在空白行內留下空白。也不應該留下拖尾的空白。

這是編碼禮儀的問題。

+0

+1:我有我的IDE條尾隨空白。 – 2010-04-28 10:19:07

+3

不是縮寫像python – 2010-05-03 08:45:52

+1

這樣的語言@ Lo'oris Indentation對於代碼而言是強制性的,對於空白行則不是。因此空白行中的任何空格都是不必要的。 – 2010-05-10 06:32:52

4

如果您使用B,TextMate會打破塊摺疊,而且我更喜歡A因爲它更「合乎邏輯」。

+0

有趣。我只是用EditPadPro試用它,它也使用縮進級別進行代碼摺疊,並且它很好地處理空行。 – 2010-04-28 11:50:10

7

添加適當的縮進空白行(風格在問題的)極大地提高了代碼的可讀性,並啓用顯示空白,因爲它可以更容易看到一個空行之後的代碼是否是相同的縮進塊與否的一部分。

對於像Python這樣的語言,沒有結束語句或者括號,我很驚訝這不是PEP的一部分。強烈建議使用顯示空格開啓編輯Python,以避免尾隨空格和混合縮進。

比較閱讀以下:

A)

def foo(): 
....x = 1 
....y = 2 
.... 
....if True: 
........bar() 

B)

def foo(): 
....x = 1 
....y = 2 

....if True: 
........bar() 

,它遠遠更清楚的是,最後兩行是foo一部分。這在縮進級別更高的情況下更有用。

0

vi隱含地阻止了A中的行爲,因爲{/}導航不再按預期工作。 git通過在運行git diff時突出顯示它爲紅色來明確阻止它。我還會爭辯說,如果一行包含空格,它不是空行。

因爲這個原因,我非常喜歡B.沒有什麼比期待跳過六個左右排列起來的{動作並最終在類def的頂部更糟糕。