你喜歡分割長長的線條？

對於手工換行較長的線條，您有什麼個人啓發式的方法來選擇要打破線條的地方？你喜歡分割長長的線條？

假設這條線太長，您可能會在哪裏分解它，以及它的優先順序是什麼？

double var = GetContext()->CalculateValue(element, 10.0);

大多數人都同意約每行分離參數：

double var = GetContext()->CalculateValue(element, 
              10.0);

有誰打破在開括號？

double var = GetContext()->CalculateValue(
           element, 10.0);

但如何回合與對其操作（或.）：

double var = GetContext() 
       ->CalculateValue(element, 10.0);

或者你會：

double var = GetContext()-> 
       CalculateValue(element, 10.0);

任何不同的賦值運算符？

double var = 
    GetContext()->CalculateValue(element, 10.0);

或

double var 
    = GetContext()->CalculateValue(element, 10.0);

任何其他方面？

如果你的系統程序，你可以這樣回答：以逗號

參數名稱的->或.操作
之前賦值運算符後

或者只是發佈一些示例代碼！
獎勵積分，如果你可以在學術上證明你的決定。

來源

2010-12-10 ack

對程序員更好。 – dmckee 2010-12-10 00:10:34

我喜歡在綁定順序的強度上進行分割，最靠近行首。因此，在您的示例中，我會在=號處分割。如果這仍然溢出保證金，我將在 - >

拆分線的想法純粹是爲了讀者的利益（因爲編譯可能不在意）。我發現從心理上來說，將心智碎片塊分解成邏輯組更容易。

來源

2010-12-10 00:10:34 verisimilidude

我在現場分割並縮進到使代碼最易讀的程度。這一切都是美學，所以任何「學術上的理由」都不會比任何其他的人爲的，事後理由的藉口去做任何你擅自決定開始的事情。

來源

2010-12-10 00:11:37

我在開括號，然後在每個參數

來源

2010-12-10 00:12:16 jhuebsch

在您的特定例子打破的粉絲我會親自去與第四招：

double var = GetContext()-> 
      CalculateValue(element, 10.0);

我從來沒有去過除了基本規則之外，它還是一個嚴格定義的代碼格式化標準的粉絲，它總是對代碼進行格式化，使其有意義（特別對於沒有編寫代碼的人）並且易於閱讀。任何過分寬泛的規則，例如「總是在該行或該位置放行換行」，或者甚至「總是使用該名稱或該命名行爲來命名變量」，這些都不符合我的想法。我發現從長遠來看它弊大於利。

它沒有很好地解決邊緣案例，它把重點放在錯誤的東西（語法點而不是代碼的實際可讀含義和流程）上，並且促進了開發商商品化的目標儘可能地讓位置即插即用，而不考慮開發人員自己的最佳判斷。

（好吧，這可能已經變成了一個有點咆哮。我道歉，但問題依然存在。）

基本上，沒有任何具體的規則，代碼應該以最適合什麼它試圖進行以可讀的方式逐案說明。開發者應該相應地使用他們的最佳判斷。

來源

2010-12-10 00:13:20 David

對於此行：

double var = GetContext()->CalculateValue(element, 10.0, foo);

我會打破的第一個參數後的臨客，然後排隊後續元素開始的第一個參數開始的地方，但對下一行：

double var = GetContext()->CalculateValue(element, 
              10.0, foo);

如果第二行變得太長，請製作第三行，依此類推。

來源

2010-12-10 00:14:55 ford

你喜歡分割長長的線條？

回答

相關問題