I get them everywhere. I mean im coding mostly mathematics, so theres a ton of nested for loops all over the place, but there can be string related C issues as well.
Brute force will get you some unmaintainable kludge that grows in complexity quickly with the number of lines of code. Break things up into functions wherever appropriate. Smaller, testable units with well-defined inputs and outputs is vastly superior to monolithic blocks of inpenetrable code.
Ideally when a function is the correct size you can see all of it at once without scrolling; you know what input it takes, what output it's supposed to give and you can see how the function works all at once without having to think through a long chain of events.
Throw in some debug asserts to validate input to functions(they compile to nothing in release mode). You can do an "int 3" from inline assembler in your assert macro if you want to invoke the debugger when an assertion failes.
If you're writting for anything serious, use unit tests and maintain a consistent coding standard between the group of people you're working with. A good idea might be to have someone else write the unit tests for your code and write the unit tests for other peoples code. Then you'll have a better grasp if the documentation for your function is up to scratch or not.
I have a nasty tendency to mix and match loop types, for instance for, + while do + do while. I do this because its usually the most elegant and compact way of solving the algorithm (eg minimizes conditionals).
Try to maintain internal consistency and avoid going against common sense.
E.g. "for ( size_t i = 0; i < nElements; ++i )" makes sense. The number of elements processed is nElements, starting from 0. 0 is the first index into an array. Consider what would have happened if you had chosen to start i off as i = 1 or used <= as the escape condition.
Find similar rules that make sense to you for while and do-while statements and learn to detect other implementations as a bad code smell.
Anyway, im just baffled by how people deal with scope. Its one thing when you patiently debug a 1000 line bit of code, but surely these sorts of things become prohibitively time expensive over the long haul, and I would have thought there would be smarter time tested tricks or meta code around those sorts of things.
Programs tend to spend some ridiculous amount of time in a tiny fraction of the code. Unless your function is part of that tiny percentage of functions that see some significant run-time, speed is simply not a concern. A full page of code is starting to get too long for comfort unless it's some kind of inner loop.
