写程序手不稳是个大毛病，往往会让一份能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、默念一句：数据有问题。关题目。