Compiler warning if Debug commands are present

[MachineCode]

I just released a version of my app that had "Debug MyProcedure()" in it. As you can tell, this means that "MyProcedure()" was never called in the final exe. Major bug for my app. Lucky I found out in time, but there is still a version of my app "in the wild" that will probably get bug reports sent my way soon, depending on how many people downloaded it. Damn.

Therefore, my request is that when the user selects "Create Executable", that the compiler scans for any "Debug" or "CallDebugger" lines, and warns you that they're present before creating the exe, or even refuses to create it.

(And yes, I know I should've done a search for "Debug" first, but you know how it is).

[luis]

Only if it's an option i can permanently turn off

I would really hate to be bothered by this, at the point I would patch the compiler to skip it

Anyway I found this and odd request: programmers has always been confronted with the risk to leave debug code in the final exe, not only "debug" statement, and everyone has his own way to deal with it (macros, conditional compilation, search and replace, etc.).

[Ramihyn_]

No.

The Debug command has to be used with care. There are different documented ways how to screw up using it, but what you describe is actually intended IMHO.

You cant do

Code: Select all

Debug ManipulateData()

or

Code: Select all

ManipulateData()
Debug ManipulateData()

but always do it like

Code: Select all

Result = ManipulateData()
Debug "ManipulateData() = " + Str(Result)

and everything will be fine

[Tenaja]

I agree, there are workarounds...using a MyDebug macro instead of Debug is another one of them:

Code: Select all

Macro MyDebug (x)
	CompilerIf #DebugFlag = 1    ;set on or off at top, as needed.
		Debug x
	CompilerEndIf
EndMacro

...on the other hand, I am not one of those that believe just because there are workarounds does not mean things cannot be improved! A warning would be VERY helpful when you have the option to turn that warning on.

[Trond]

Tenaja, you don't understand the problem. He needed some procedure to run:

Code: Select all

Debug MustReallyRunThisVIPUltraImportantDontForget()

But debug statements are not compiled when the debugger is disabled. So the important procedure wasn't run in the final exe. Your macro doesn't change anything. Even if DebugFlag is 1, the compiler won't compile the debug statement when the debugger is off.

[luis]

You could use something like this

Code: Select all

Macro MyDebug (x)
   CompilerIf (#PB_Compiler_Debugger = 1)
    Debug x
   CompilerElse
    x
   CompilerEndIf
EndMacro

But only if x is a procedure, like the the current case. If you really FEAR to forget about it.

A quick find before releasing the exe doesn't sound so hard to me, but anyway that's up to Fred & Co.

[IdeasVacuum]

...+1 useful option.

[Blood]

To be honest this is a problem with your coding, not with the compiler. Asking for a feature just so you can personally code in a sloppy manner is laughable.

Honestly, just change the way you do things to something a little more 'best practise'.

[MachineCode]

@Luis and Blood: When I say "give a warning", I don't mean a messagebox or anything that actually STOPS compilation. Rather, just a compiler message at the bottom of the IDE that says "WARNING: Debug command present" while compilation occurs, so I can see it. The exe could still then be created, instead of aborted.

My request is functionally no different to the current "Deprecated command used" messages during compilation, so I don't see it as a real problem at all. Call it laughable if you like, and I'm sorry I'm not as perfect as you Blood, but it's easy to overlook 6 bytes in a 582,280 byte source, especially when procedure folding is used that hides it.

[luis]

@Luis and *****: When I say "give a warning", I don't mean a messagebox or anything that actually STOPS compilation. Rather, just a compiler message at the bottom of the IDE that says "WARNING: Debug command present" while compilation occurs, so I can see it. The exe could still then be created, instead of aborted.

OK OK, please note I have not called your request laughable

I still don't see it as something useful because there is nothing wrong in leaving debug commands in the source.
When you build the final exe they vanish.
You could have one or two of yours "debug FuncName()" and twelve "debug a$".
But you don't know if you left only debug statements of the second type (doable) or of the first type too (not a good thing, usually). So you have to go and check. You can do the same without the compiler warning.
Can be useful only if you want to remove all your debug statements from the source. And sometimes you don't want to rewrite all of them later, so you left them there. No harm done.

Again, it's not for me to decide about it, but I can express some doubt about its need and the request of "please I don't want to see it all, not even in the status bar!". It would be only a distraction for me.

But you are certainly entitled to ask for it!


BTW: I seem to recall the rolleyes was removed for a reason (I'm not saying it was a good reason).

But to reintroduce it by other means to me looks like a: "Admin, I don't care about your local policies, I'm above them! Stick it!"

Just a thought.

[Ramihyn_]

Using any expression or procedure inside a Debug statement which alters data is wrong!

You have experienced one of the side effects of this mistake, now go and check all your debug statements in your sources and verify them. Case solved. You need to do this anyway, no matter if Fred add's a conditional option for a compiler warning in some weeks

I would agree that a compiler warning if you use an expression or procedure in a debug call which alters data, would be useful. But that might be tricky to do right.

[Blood]

My request is functionally no different to the current "Deprecated command used" messages during compilation, so I don't see it as a real problem at all. Call it laughable if you like, and I'm sorry I'm not as perfect as you Blood, but it's easy to overlook 6 bytes in a 582,280 byte source, especially when procedure folding is used that hides it.

It IS functionally different because the deprecation warnings are needed to avoid using old language features that will be officially removed from the language. Your request, on the other hand, is because you refuse to code in a more safe way. Like what Ramihyn_ says, what you're doing is wrong and you have been shown the error of what you are doing. The compiler should not be coded to stop people being stupid.

You know debug commands are removed from the source on compilation. SO STOP PUTTING THEM IN FRONT OF FUNCTION CALLS! There i just saved your next project from bugs and Fred weeks of work!

[Tenaja]

Tenaja, you don't understand the problem. He needed some procedure to run:

Code: Select all

Debug MustReallyRunThisVIPUltraImportantDontForget()

But debug statements are not compiled when the debugger is disabled. So the important procedure wasn't run in the final exe. Your macro doesn't change anything. Even if DebugFlag is 1, the compiler won't compile the debug statement when the debugger is off.

Actually, I do understand the issue...but with the flag off, he'd catch the bug in testing. In theory, anyway, because then it'd be faster to test than by going through the compiler menus.

[MachineCode]

Well, deary me, haven't I been told! I still love you all.

[Danilo]

Well, deary me, haven't I been told! I still love you all.

The same happened quite often to me in the last 10 years.

Therefore, my request is that when the user selects "Create Executable", that the compiler scans for any "Debug" or "CallDebugger" lines, and warns you that they're present before creating the exe, or even refuses to create it.

Sounds like a IDE plugin for the trigger "Before create Executable":
It opens a new Window with a Listbox or ListIconGadget, shows all lines with Debug statements
and if it detects a procedure call or something like that behind the Debug statement, it gets highlighted.

A funny weekend project...