另外註釋寫在行末的話整個代碼會很寬，建議寫在函數聲明的前面。在函數定義那裡就沒必要再註釋一次了。

我個人喜歡的結構是這樣的：

// 這個文件做了這些和那些……
<空行>
#include <foo_lib.h>
#define BAR_NUMBER 1
<空行>
// 執行某任務
void do_foo(int bar_count);
// 測試輸入字符串滿足某條件
int test_bar(int name_len, char[] len);
<空行>
int main()
{
// 函數主體
return 0;
}
<空行>
void do_foo(int bar_count)
{
// 函數主體
}
<空行>
int test_bar(int name_len, char[] len)
{
// 函數主體
return TRUE;
}

題外話，三個函數的定義之間隔個空行吧，好看一點。另外定義的宏最好用大寫，像「 NUM 」這樣。

你期望什麼結果？我覺得「不足補 0 」、「多餘的扔掉」和「報錯」都是合理的

@aisaaceinstein #64 如果加密了，是不是洩漏了也不要緊？

除了「 for(; ;)」和「 8 個空格縮進」屬於口味不同以外，樓主的代碼簡直是一股清流……

@qian19876025 多系統是說多個 Linux 麼…… 不至於「很多人都」多個 Linux 吧

而且七牛 10 TB 應該是￥ 1650 吧

全套亞馬遜多半是成本最低的

比較喜歡 Haskell ，主要是類型系統比較好玩

對於這種情況我個人習慣 422

@itfanr 你說的 shellpy 能改環境變量麼？

所以大多數 Git 教程都有說「強推需謹慎」，就是避免這種讓人困惑的情況……

樓主，你看下面這麼多特性請求，不如去 Worktile 、 Trello 之類的網站開一個頁面，讓大家提要求好了……

我和 @goodbest 意見相同，如果樓主堅持要這麼做，至少應該在軟件開機畫面或者其他醒目位置警告用戶。如果新浪微博客戶端突然跟我說某個原本能用的功能突然變成付費的了，我會一生黑的……

Google Forms +1

弱引用得到的 a 不是對象，是對對象的引用。並沒有「得到」那個對象。對象還是對象，沒有弱對象和強對象。

@Patrick95 {{63L}}: 在知乎有相關討論： https://www.zhihu.com/question/19570377

@Patrick95 {{63L}}: 這篇文章的評論區清一色反對

哦，還有一點，要能無限接近 0 和 1 。用數學的語言來說，就是（高能預警）：

記概率密度函數為 f(x)。給定任意的 δ>0 ，則 f(x) 在區間 (0, δ) 上的積分大於零，且在區間 (1-δ, 1) 上的積分也大於零。