The easiest way to verify whether your code behaves as you expect is to set a breakpoint and inspect variable values. When the app stops at a breakpoint, enter po someProperty in the console (where po stands for print object).
If the part of the code where the bug occurs is complex and it’s not easy to track what’s happening using breakpoints, adding multiple print() statements can be very helpful. This gives you a clear picture of the flow and allows you to quickly localize where the logic fails.
A good practice is to format your prints like this:
print("__ someValue \(someValue)")
print("__ func setup()")
// etc
Add __ in the console’s filter text field, so you only see these debug prints and avoid noise from other messages.
Another technique is commenting out large chunks of code to see if the bug still appears. For example, imagine you have 100 lines of code and one of them causes a bug:1. Comment out the first 50 lines and check if the bug is still there.2. If the bug disappears, you know the problematic line is in the commented section.3. Keep halving and testing until you find the exact line.Of course, this description is very general, but it illustrates the logic of the method.
When working with code, the time spent writing it is much less than the time spent reading it later for debugging or extending functionality. Code is often written in multiple iterations with new features added over time. Keep in mind that you’re not just writing code to make it work now — you’re writing code so that future you(or others) can come back and quickly understand and modify it.
Before committing to git, take time to refactor and improve readability. This is an investment that pays off in the long run. The time spent on cleaning up the code doesn’t extend development — it ultimately reduces it by preventing confusion and bugs down the line.
Formatting. Even an extra space can be worth fixing, despite the code “still working.” Also proper naming is crucial: be sure the names you use accurately convey the concept. Apply the “5-minute rule” — if you’re unsure about a name, don’t hesitate to spend a few minutes thinking it over. That small investment will save much more time in the future.
Things that might seem trivial now can become critical during debugging, when your mind is already consumed with finding a fix. Any additional mental overhead in figuring out ambiguous code can seriously slow you down.
Software development is essentially a battle against complexity. As the codebase grows, you should avoid unnecessary cognitive load, because more complexity means a greater chance of introducing bugs. By following simple clean-code principles, you’ll make your life easier and more enjoyable.
Surface potential bugs as early as possible — before building more layers of logic on top of them. For example, using assertion failures (e.g. assertionFailure) in guard statements can catch problems in their earliest stages. Cover your code with tests wherever possible.
When writing concurrent code, pay extra attention. Concurrency bugs are the hardest to reproduce, making them the worst type of bug. They can appear randomly without any clear reason, which makes finding the root cause extremely challenging.
Think about modules APIs. A well-designed, minimalistic API prevents one module’s bugs from spilling over into another.
Avoid Smelly Solutions. Bugs often have both a cause and an effect. While you can sometimes fix the effect to make the bug appear “gone,” that adds complexity, making future maintenance more difficult. Always aim to fix the root cause. In exceptional cases, leave a comment indicating that a better solution exists and add it to your task tracker.
Finally, clean up the DerivedData folder.