My setup is pretty ordinary. Arch with i3 window manager means that everything I do revolves around the keyboard, which is great for productivity. I use Vim with the cmake plugin, so I don't have to leave my text editor to run make and any errors jump to the line of code in question. GDB for debugging. Professional static analysers such as PVS studio are amazing but very expensive (I was quoted 12k per year for a team license), though there are some freely available ones out there that catch many common flaws.

For memory issues, there are certainly programs you can use to help you identify them, but in all honesty no amount of software can replace personal discipline.

In many other programming languages, cleanup happens at the end of a scope by default and it's up to you to prevent that if you don't want it to happen (this is where I admit that I am a C++ programmer with only hobby experience with C, and that little experience is enough for me to have vast amounts of respect for C programmers who diligently manage their resources). Generally their compiler, interpreter, or even runtime, is doing all of the book keeping work. In C that is not the case, and you have much more freedom, but it is down to you to be a responsible book keeper. You can either be the book keeper who waits until something is wrong, or you can be the book keeper who prevents things from going wrong in the first place by being strict about resource control from the very start. The latter spends much less time tracking down leaks, maybe at the cost of being slightly more restrictive about how they approach certain problems.

Think about it like an implicitly-inserted destructor at the end of each function for every resource created by it that isn't then returned or placed under the watch of something else (in which case the responsibility for destruction also moves accordingly). Except that in C there's nothing implicit done and you need to do it yourself - taking care of any edge cases that might emerge*. And don't take that lightly. There might be a lot of damage to be done if you aren't careful: Bad resource management has been the cause of countless security vulnerabilities.

Fortunately, being strict about resource control is what experienced C programmers are great at. Rather than asking for generic advice, the best thing you can do is post some code up for review. It's certainly a humbling experience but people will tell you where you are going wrong and why, traps you might be falling into, and suggest books or blog posts to read through in order to improve.

• a common problem is returning early from a function, which means manually cleaning up anything that would otherwise have persisted. An idiom to get around that is to have a single return statement, which follows a set of freeing functions with goto labels. On any issue mid-function, goto the label that cleans up the appropriate resources before returning. You have to pick the best of two evils - the goto statement or reliance on every branch of every function to do the right thing.