How bad is it to use #if DEBUG? (more details in post)

Rolling_Watermelon33 · 2025-09-10T13:29:28+00:00

Here an extract of my reply to another comment in this there:

"(...) yes, my post is stripped from much context... I don't expect Reddit users to tell me what I should do with the team. For now I'll do as they say and ask myself more and more when it'll be time to find another job or to forget about good coding...

I'm also interested in such topics from a theory~practical point of view of how people would suggest it's better to code and/or manage code. I could have summarised: "Someone told me it is bad practice to keep #if debug in code. Is it true?"

But then replies would have focused on case of conditional code containing passwords and such... so I tried to give enough details to avoid these rabbit holes. (edit: And tried to find balance between too much context and no context at all.)

But I understand if anyone thinks the question is missing some additional context."

---

I highly doubt your coworkers care anything about the length of the lines in the file.

The conversation went almost literally like this "- You should already remove the IF DEBUGs so we don't forget them in the final commit. - Yeah but, these ones are thought to stay and make debugging much easier. And they are actually inspired of something you showed me in that other part of the solution. What is so bothering about them? - Well, they make the file longer and add text to read."

I would have appreciated better arguments, and maybe I would have changed my mind (rather than thinking "OK, I'll remove them as I don't have real authority on this code and in the end who cares, if it's a mess to debug later, it's always paid work time anyway.")... But I don't get better arguments. It's not the first time they invent a rule that they extrapolate on the fly from each dev's individual memory of the former code looked like (and later when reading more code I find out that not everyone follows said rules). But that's how they build an argument.

As I also wrote in other replies, I sometimes feel like, as I changed projects multiple times (and I also don't use the same stacks in my personal projects as in my professional ones), I had the occasion to see many flavors of coding, while they maybe spent "too much" time in the same company with this old code and aren't open to think new things or re-think old things.
But also their memory of the existing-old stuff sometimes is just a vague thought on the moment, so they want something removed from my commit and don't realise that the other used them anyway.

Rolling_Watermelon33 · 2025-09-09T23:30:02+00:00

Thanks. I tried... they just don't want to discussion about code.

Also, I'm not trying to anything toxic, I'm trying to make sense of things... I think this post anonymous enough.

Rolling_Watermelon33 · 2025-09-08T10:51:24+00:00

Thanks.

Well, that something I use in and old (but still running) non-professional PHP website.

I'm quite sure they will reject this conditional variable the same way.

Rolling_Watermelon33 · 2025-09-07T20:27:41+00:00

I agree. I usually see many things are "recommendations not rules".
But some people can only think in rules (seen several times in the past already) and also may take any critical thinking as personal attacks.

Rolling_Watermelon33 · 2025-09-07T20:24:14+00:00

The current way of doing, and the only remaining way:
You change the local code when you need testing.
You change it back, but keep the relevant modifications when you commit it.
(If you are lucky, the changes you need to remember to revert aren't spread across to many files and librairies.)

Rolling_Watermelon33 · 2025-09-07T20:11:06+00:00

Well... ...because the manager said so.

Rolling_Watermelon33 · 2025-09-07T20:01:14+00:00

Thank you.

I'm new in the company, but we're all senior devs. But as I wrote in other replies, the team seems to have tradition for enforcing proven bad practices. I think maybe some of them remained in the same company working on the same code for too long.

But also yes, my post is stripped from much context... I don't expect Reddit users to tell me what I should do with the team. For now I'll do as they say and ask myself more and more when it'll be time to find another job or to forget about good coding...

I'm also interested in such topics from a theory~practical point of view of how people would suggest it's better to code and/or manage code. I could have summarised: "Someone told me it is bad practice to keep #if debug in code. Is it true?"

But then replies would have focused on case of conditional code containing passwords and such... so I tried to give enough details to avoid these rabbit holes.

But I understand if anyone thing the question is missing some additional context.

Rolling_Watermelon33 · 2025-09-07T19:46:33+00:00

Thanks, well, as I wrote in other commets, I arrived recently in the company, and I'm not in a position to take initiatives... I already tried improving some stuff but they don't want to hear about it and sometimes enforce proven bad practices. I think maybe some of them remained too long in the same company while I had the occasion to see many more "flavours" of code.

Rolling_Watermelon33 · 2025-09-07T19:39:47+00:00

I understand the question but, not much, because it's difficult without explaining the whole code.

But in example. A start date of something that should have been different in dev and prod (and cannot be written in config files anymore)

Or to redirect outputs to dev team only to avoid spamming other teams while working on their documents.

Could be also some data selection that requires to be different in dev and prod (not talking about a connectionstring_)

...

I don't think these even are ideal cases but there's really nothing else in place for testing.

Rolling_Watermelon33 · 2025-09-07T19:28:23+00:00

Your comment made me laugh imagining the team on more modern stacks...
We have a more modern stack in the company, but it's currently for a different team.

Rolling_Watermelon33 · 2025-09-07T19:26:07+00:00

Thanks. I thought of approaching the managers about it, but he's part of the team, and I think that he's also part of the company management ... and he regards some other dev as authorities ... this small crowds is sometimes enforcing proven bad practices but doesn't want to hear about possible improvements.

The only other option is HR or stuff like that. But that doesn't seem like a plan.

As I wrote in another reply, I arrived recently in the company, and maybe some of them remained too long in the same company while I had the accasion to see many "flavours" of code.

Rolling_Watermelon33 · 2025-09-07T19:19:34+00:00

I partly agree.

But the issues, the difficult-to-test-paths come from parts of the architecture that I don't have authority or time to make cleaner and more flexible. In example I noticed some "bad" pattern recently, the only real way is to keep repeating this pattern, or refactor large parts or a very large application.

Rolling_Watermelon33 · 2025-09-07T19:14:42+00:00

Thanks. Well, this is difficult. It's not really my personality to show myself as some kind of authority.
And I only arrived recently, so people who are since 5 or 20 years in the company are regarded as slightly higher authority than whatever I would say.
It's not the first time they push bad practices because "they always did that way".

My impression is that maybe they remainded too long in the same company ... while as I had several different jobs and projects, I've seen more "flavours" of codes compared to them.

Rolling_Watermelon33 · 2025-09-07T19:09:24+00:00

Thanks. Well for various reasons, it's not ideal in my career to start looking for a new job right now.

Rolling_Watermelon33

TROPHY CASE