写程序手不稳是个大毛病，往往会让一份能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相关问题等。

3、检查数据范围。又一次读一遍题，确认题意。思考边界数据对代码的影响。数组是否开小，是否爆int等。

4、进行暴力对跑。写个暴力但保证正确的版本号，利用小数据和代码对跑。

5、假设不是个人赛，找队友或者其它朋友帮忙看代码。把代码给他们解释，让他们想有没有问题。

假设是在比赛中，如今能够临时放弃这一题先看别的题了。之后有空再回来看。

。

6、假设别人过了就对照两份代码，或者直接对跑

7、睡一觉，补下番，来两把lol。明天再看一遍。。

8、搜数据。

。。。

9、搜题解。。。。

10、默念一句：数据有问题。关题目。