CODEWITHSUNDEEP
cdebuggingcoding-stylec-preprocessor
Liran Orevi
Liran Orevi

Reputation: 4903

To remove #ifdef DEBUG parts for release or not?

When releasing source code for someone else to see, when coding style is not well defined (no pun intended) do you remove the #ifdef DEBUG parts?

(that is the parts that are compiled only when DEBUG is defined)

If I remove it, it makes the code looks better (or me look better - do I really want someone to know I've debugged, and how I've done it? ), but then I'll lose my debug parts, or have to keep two (or more) versions of the code.

What is to be done?

Upvotes: 3

Views: 2850

Answers (6)

user82238
user82238

Reputation:

Maintaining multiple versions of ANYTHING is undesireable.

Only do so if you must.

Upvotes: 0

Brian R. Bondy
Brian R. Bondy

Reputation: 347276

Maintain your base version with everything in your source code management system.

Then if you want to distribute source code filtered in one or more ways, make a script that will make a release version of your source code.

Do not maintain these secondary filtered repositories, make them always generated.

But is it worth the time? Probably not, and you should probably just distribute everything including the #ifdef DEBUG parts.

Upvotes: 2

Slidell4life
Slidell4life

Reputation: 310

I also vote to leave it in. If/when you start work on your first patch, you'll likely need those DEBUG-blocked pieces. Also, QA won't love it that you removed the code, even if it is blocked in a directive.

Upvotes: 3

Jaka Jančar
Jaka Jančar

Reputation: 11606

If you do decide to remove them, just filter them out with a script when exporting the code, no need to maintain two versions.

Upvotes: 2

MissT
MissT

Reputation: 780

You should leave the code as is, unless you make use of non-recomadable language in your commentary. If someone is to use your code, chances are they'll need those, or it will help them understand your code. (this is also true for commentaries)

Edit: I worked on drop of other studio code often in the past. I have seen debug code, dead path and many other stuff, still the only thing I hated, was people that strip their code of debug and commentary, this makes their code real hard to maintain

Upvotes: 3

Andy White
Andy White

Reputation: 88375

I think if your debug code is clean and has "professional" language in any logging statements, it's okay to leave it in. If the debug code is sloppy or has debug messages like "I'm here...," "Now I'm here..." you should take it out.

If your debug statements reflect the fact that there are issues that you can't figure out, it might be best to take them out, if you're trying to "sell" your software to someone. (Hopefully you can fix them later...)

Upvotes: 8

Related Questions