I am often working in very large projects that I didn’t do the original development. Other Peoples Code (OPC) projects present a lot of challenges because not only do you have to find the section of the project where an issue exists, but find it in the workflow of the product. This can be an exhausting process for some OPC projects. Perhaps you have to connect to a database server (and set up all of the security to do so), submit a query, download some data, interface with some hardware, and then navigate through the user interface to find the particular thing you’re working on.
I was doing this in a recent project and I wasn’t quite sure what the original developer was trying to do (because it lacked some necessary comments) and my iterative changes were taking too long to test. The debug cycle was easily 45 seconds just to tweak a simple constant and that was taking too long. I had to come up with a better solution.
What I ended up doing was taking the classes in question and put them into a much smaller project – a demo project, if you will – so I could work with it without having to go through the application GUI. I was able to control the environment so I could get to it in just a few seconds rather than having to wait almost a minute.
It quickly became obvious what the solution was and I ended up fixing the issue in just a few minutes. Putting those changes back into the original project was a trivial task. I ended up saving time, overall, by breaking the code out into a smaller project.
You would be surprised at how often I take a step back from the large project I’m working on to create smaller projects. My hard drive is littered with hundreds of small projects to demonstrate a technique or proof of concept. It makes coding OPC projects much, much easier.
This leads me to my next point. Write the code in your example projects as if you were going to use it in a real project. This means having reasonable object names, use your standard naming conventions, etc so you can copy and paste code and you won’t have to rewrite it again. I can’t tell you how annoying it is to have code snippets with meaningless variable names. What is i and why are you incrementing it? It might be obvious but perhaps iCount, or iObjectCount, is more descriptive (and helpful).
I am part of the Xojo alpha and beta program. When I submit a bug I almost always provide a small sample project demonstrating the issue. This proves that it’s not my coding that’s at fault (which happens more often than I’d like to admit) and helps the Xojo engineers out by providing a project for them to run. When they mark it fixed, I can also use that project to prove that it’s fixed.
Stop wasting time by trying to fix code in your big project if it’s taking too long. Break it out into smaller chunks. You’ll probably find yourself saving time (and your sanity).