Auto comment: topic has been updated by Kevin114514 (previous revision, new revision, compare).

Getting WA on samples is actually great, because this is even not penalized by the system. And such problems are very easy to fix, assuming that your general approach is correct.

As for stupid typos, I wasted a lot of time during a few contests simply because of mistyping something like a[i-i] instead of a[i-1]. The worst part is that I was going through the code multiple times and just couldn't see anything wrong by visual inspection. That's a freaking optical illusion! And of course in all of these cases, the samples provided by the problems statement were "weak" and couldn't catch the bug. Apparently there's some truth in the tourist's joke about erasing your code and writing it from scratch again :-) I'm dealing with this problem by writing testcase generators and inspecting corner cases, but this takes time and costs a lot of points.

And finally, I just dislike C++ as a programming language. It is surely very popular among competitive programmers, but it's also error prone and not very suitable for rapid development. In the real world, software developers prefer to use something like Python, Ruby or some other scripting language for implementing quick and dirty prototypes or helper tools. But in the world of competitive programming, TLE failures are throwing a big wrench into this habit and this is very annoying. As a compromise, I switched to using D programming language in competitive programming contests. But I'm yet to see whether this helps or not in the long run.

Do you code problems you solve in practice or do you just skip coding? You will always have bugs, the question is how fast you find them. Debugging is a skill on its own and should be practiced accordingly.

This is exactly the problem I am facing too. It takes me much more time to debug then to get to the correct approach, because of these stupid errors.

If you're getting too many stupid errors like mistyping x for y then use longer, more descriptive variable names. Maybe using spaces in your codes would make them more readable.

more carefully.Maybe you can use '#define',like this:

"#define x y"

I usually have those kind of mistakes, but I think there are some advice that I will like to give:

• Make neat and readable code so it's easier to check.
• Before submitting, make sure to check your code (I usually check line by line if I'm not in a rush).
• Don't rush yourself, be patience and take your time on checking your solution.
• And as tourist have said in one of his google code jam, "It's better to prevent bug, than fixing it", so try to take your time on thinking and making solutions :D

I think it is a misconception to come up with a solution that has to be "simply implemented right", and then it would work.

If it is difficult to implement a solution, then usually it is because the solution is not a solution, but only a vague idea of one. Typing x for y happens if you have to think for three other things in parallel.

Hence it is a clear sign of need for optimizing the process, how to come up with a submittable code.

Use good IDE and enable all warnings.

And you are not the worst.I always get right on the samples.But It get WA on test 2,and I can't even debug!

I dont understand why green/cyan/blue coders are even writing comments and giving advice to yellow. Like seriously? It doesnt even make sense to advice someone who outranks you a thousand fold.

Maybe you can check it after you type each line.