Supplying code to people helping you debug?

Question

I was wondering if it is wise or advisable to send over a large amount of source code of one's application for debugging and error solving purposes, I'm working on an iOS app that I hope to release to the App Store and am seeking help on Stack Overflow and I'm tempted to send over a large amount of the code so someone (they requested it) can help me. Would you recommend sending over a significant portion of your app to someone for debugging purposes?

Answer 1

Licensing and copyright issues notwithstanding, you usually get the best responses for really short code snippets - 5 lines is ideal, 50 lines is doable, 500 lines is asking too much. If you post a short snippet, you demonstrate that you have made an effort narrowing the problem down, that you are willing to do your homework (translate the short proof-of-concept solution into something that works in your product), and that you consider the time of those that are helping you as valuable as your own.

Honestly, I can't think of a problem that would require you to send large quantities of code; such problems should always fall in one of the following categories:

• "Please do my work for me, because I am lazy": Your problem can be solved or narrowed down using standard debugging techniques, but rather than try them yourself and seek help with the results, you prefer someone else doing the work for you.
• "I don't understand this code, it's too complicated": One could argue that if your code is so complicated that you cannot understand it, it is bad code and needs to be refactored or even rewritten. It is also possible that you do not fully understand the problem you are trying to solve, in which case your coding attempt is doomed from the beginning; and the solution is obvious (though not comfortable): re-analyze the problem, refactor, redesign, rewrite, until the structure is clear. You should now be able to extract a short snippet that shows the problem.
• Someone Else's Mess. Most of us have been in a situation where you inherit a 10-something-year-old pile of spaghetti, with cross-dependencies all over the place, full of mysterious methods with no apparent purpose, misleading identifier names, useless comments, liberal use of obscure language features and edge cases, stuff that's needlessly complicated, redundant, or outright wrong - in short, your average nightmare. The sad news is: You're in this mess alone, nobody likes dealing with it. Man up and ask questions about suitable strategies (in fact, p.se is full of excellent questions and answers on this topic), but don't expect anyone to do your work for you (see a pattern yet?)
• Large-scale design problems. These problems play at the macroscopic scale, but if you can word them well, you don't need to post any code at all, or maybe just some stubs illustrating your design.

Answer 2

Whenever I have a such scenario when I have to share my code for debugging purposes on Stack Overflow. I do a lot of edits. I remove the package of my organization from Java files. I rename API names. And a lot of stuff. So that I can comply to the policy of my company to not supply code online. But with edits, it will be safe to get help from people.

People can help quickly with short code snippets. I always share my sense and approach that I am using and ask people. And I always get very useful pointers.

Answer 3

Remember that code published on Stack Exchange sites will become CC-wiki licensed, so you may not want to license your code thus by publishing it in that context.

More generally, you want to demonstrate enough code that the problem or bug you're trying to solve is reproducible. But regardless of intellectual property considerations, giving the other party more code than is necessary makes it harder for them to determine where the problem lies-remember that you're having trouble finding the bug, and you know your code better than they do. The "minimal buggy project" helps your reader see what you're trying to do, and indeed you may even gain a better understanding of the problem by identifying the relevant extracts of code.