寫程序手不穩是個大毛病，往往會讓一份能AC的代碼變成99.995%正確，失之毫厘謬以千里，近期十場個人賽非常少有能一次AC的經歷，細致想想除了根本邏輯上的錯誤。大概都是跪在這些細節上：
1.輸出格式，輸入格式是否符合規范。有沒有Case #？是否有多余空格輸出？I64d or lld？輸出浮點數盡量不要用cout。
2.i和j，n和m，l和r有沒有寫混了的。。（今晚檢查了兩小時的程序發現i<=m寫成了i<=n...吾之內心差點兒崩潰orz。
。
3.邊界問題。從0開始還是從1開始？遞推式有沒有越界？不要使用cnt數組來累計某個值出現多少次，最好使用map來映射。。
4.爆int，爆longlong。數論題尤其要注意，每次測試滾鍵盤來幾個大數字。爆int的話實在拿不准數據范圍，在內存同意的情況下#define int long long；爆long long的話把每一個乘法操作模除大素數（必要情況下加法操作最好也要。
5.對於不合法輸入或無解情況的處理。。
是輸出-1還是0還是no solution好好讀題。
6.某些應該凝視掉的句子沒凝視，freopen什么的。。
7.特判情況遺漏。
8.數據還沒全然讀入就貿然結束程序。。盡管有些時候答案已經出來了。
解決的方法還是靜下心來，思路亂的時候手不要碰鍵盤，太龐大太復雜的流程分模塊來寫，先想好例子再去寫代碼。
眼下組隊賽要開始了，不能坑隊友。
附：
debug流程（from知乎：
1、又一次通讀一遍代碼，檢查初始化，檢查輸出格式，需不須要輸出CASE等
2、檢查常常出現的一些手誤，兩重for循環中i,j用混。多重for循環中i被多次使用。long long相關問題等。
4、進行暴力對跑。寫個暴力但保證正確的版本號，利用小數據和代碼對跑。
5、假設不是個人賽，找隊友或者其它朋友幫忙看代碼。把代碼給他們解釋，讓他們想有沒有問題。
假設是在比賽中，如今能夠臨時放棄這一題先看別的題了。之后有空再回來看。
。
6、假設別人過了就對照兩份代碼，或者直接對跑
7、睡一覺，補下番，來兩把lol。明天再看一遍。。
8、搜數據。
。。。
9、搜題解。。。。
10、默念一句：數據有問題。關題目。