敲代码手不稳是个大毛病，往往会让一份能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.特判情况遗漏。
解决办法还是静下心来，思路乱的时候手不要碰键盘，太庞大太复杂的流程分模块来写，先想好样例再去写代码。
眼下组队赛要开始了，不能坑队友。
附：
debug流程（from知乎：
1、重新通读一遍代码，检查初始化，检查输出格式，需不需要输出CASE等
2、检查经常出现的一些手误，两重for循环中i,j用混，多重for循环中i被多次使用，long long相关问题等。
3、检查数据范围，重新读一遍题，确认题意，思考边界数据对代码的影响，数组是否开小，是否爆int等。
4、进行暴力对跑，写个暴力但保证正确的版本，利用小数据和代码对跑。
5、如果不是个人赛，找队友或者其他朋友帮忙看代码，把代码给他们解释，让他们想有没有问题。如果是在比赛中，现在可以暂时放弃这一题先看别的题了，之后有空再回来看。。
6、如果别人过了就对比两份代码，或者直接对跑
7、睡一觉，补下番，来两把lol，明天再看一遍。。
8、搜数据。。。。
9、搜题解。。。。
10、默念一句：数据有问题，关题目。
版权声明：博主表示授权一切转载：）