Most of the code in this program has better comments than this:

oFont.setName("Palatino Linotype"); //MS Sans Serif

//This is not a comment

 I must admit I've been guilty of that sort of comment.  I usually preface it with the word "was" to make the intent more obvious, though.

Nice. I see these sort of things all the times. Code gets changed, but comment is forgotten. After all, comments are useless to the machine. But anyway, who needs a comment that says the name of the font that has just been stated in the code? Or maybe that comment is both correct and needed since on that machine the Palatino Linotype font file actually contains the MS Sans Serif font.

I can beat that: 

$var = $var; // NEEDS ATTENTION: may have been used for some specific purpose

The code does precisely what you think it does -- nothing.  Somebody added the comment later because they weren't sure if they should delete the code or not.  This line was not representative of the general codebase, either.  For one, it was actually commented, even if the comment was a Zen koan.  Second, even though the code itself was completely useless, it didn't: corrupt data, expose credit card numbers or send a list of every user under the age of 13 to a pedophilia mailing list.  Thus, it was technically less harmful than 90% of the remaining code.

morbiuswilters:

Thus, it was technically less harmful than 90% of the remaining code.

I'm not sure whether to laugh or cry at that last sentence. I decided that since its not my codebase, laughter is appropriate. Nervous laughter...

 

morbiuswilters:

$var = $var; // NEEDS ATTENTION: may have been used for some specific purpose

Could this be Perl?   In that case it would prevent the interpreter from complaining that  $var was only referenced once.

morbiuswilters:

$var = $var; // NEEDS ATTENTION: may have been used for some specific purpose

I've used something similar for debugging a specific section of a loop:

if (number == 2010)
    number = 2010; // Breakpoint here

sibtrag:

 

morbiuswilters:

$var = $var; // NEEDS ATTENTION: may have been used for some specific purpose

Could this be Perl?   In that case it would prevent the interpreter from complaining that  $var was only referenced once.

That was my thought, I use the same technique in C when I have a set of functions with identical parameters, where not all functions actually use all parameters.

My comment is usually more helpful, though: // Stop compiler whingeing

SenTree:

That was my thought, I use the same technique in C when I have a set of functions with identical parameters, where not all functions actually use all parameters.

 

i think this works as well : 

void iDoNotUseParams( int /* p2 */, void * /* p2 */ )

{

[...] 

} 

I'm almost certain that it's copypaste laziness. It's more obvious when you think of it as...

oFont.setName( "Palatino Linotype" );
//oFont.setName( "MS Sans Serif" );

The original writer was probably trying to find a good font (or was asked to change it), and he left the comment there as a way of not having to look up the exact spelling, capitalization, etc. of "MS Sans Serif", in case Palatino Linotype doesn't work out.

sibtrag:

Could this be Perl?   In that case it would prevent the interpreter from complaining that  $var was only referenced once.

No it wasn't perl.  Also, you can ignore the stupid "variable referenced once" errors in perl, which would make way more sense. 

Erick:

morbiuswilters:

$var = $var; // NEEDS ATTENTION: may have been used for some specific purpose

I've used something similar for debugging a specific section of a loop:

 

if (number == 2010)
    number = 2010; // Breakpoint here

No, that's not what it was for. 

Nelle:

SenTree:

That was my thought, I use the same technique in C when I have a set of functions with identical parameters, where not all functions actually use all parameters.

 

i think this works as well : 

void iDoNotUseParams( int /* p2 */, void * /* p2 */ )

{

[...] 

} 

I think it probably would; either method is valid C. However, our coding guidelines (based on MISRA) specify that all function parameters shall be named, and that the identifiers in the declaration and definition shall be identical, but they say nothing about lines of the form x = x;

Erick:

I've used something similar for debugging a specific section of a loop:

 

if (number == 2010)
    number = 2010; // Breakpoint here

So, your debugger didn't have conditional breakpoints?  That's unfortunate.

DogmaBites:

So, your debugger didn't have conditional breakpoints?  That's unfortunate.

I'm just lazy. You get to choose which is more unfortunate.

DogmaBites:

Erick:

I've used something similar for debugging a specific section of a loop:

 

if (number == 2010)
    number = 2010; // Breakpoint here

So, your debugger didn't have conditional breakpoints?  That's unfortunate.

Depending on the debugger and computer architecture, a breakpoint on an "if" statement can be several orders of magnitude faster than a conditional breakpoint.

Carnildo:

Depending on the debugger and computer architecture, a breakpoint on an "if" statement can be several orders of magnitude faster than a conditional breakpoint.

 

But you're... debugging.

Carnildo:

DogmaBites:

Erick:

I've used something similar for debugging a specific section of a loop:

 

if (number == 2010)
    number = 2010; // Breakpoint here

So, your debugger didn't have conditional breakpoints?  That's unfortunate.

Depending on the debugger and computer architecture, a breakpoint on an "if" statement can be several orders of magnitude faster than a conditional breakpoint.

 

"several orders of magnitude."   O RLY?

tster:

Carnildo:

DogmaBites:

Erick:

I've used something similar for debugging a specific section of a loop:

 

if (number == 2010)
    number = 2010; // Breakpoint here

So, your debugger didn't have conditional breakpoints?  That's unfortunate.

Depending on the debugger and computer architecture, a breakpoint on an "if" statement can be several orders of magnitude faster than a conditional breakpoint.

 

"several orders of magnitude."   O RLY?

It's been a while since I've debugged anything on a 80486 using Microsoft C/C++ 7, but yes.

Isuwen:

Carnildo:

Depending on the debugger and computer architecture, a breakpoint on an "if" statement can be several orders of magnitude faster than a conditional breakpoint.

But you're... debugging.

 

So? What if you're debugging something that has to chew through a few ten thousand iterations before the error occurs and that even without the debugger can some time to complete? Speed can matter even when debugging. And honestly, I find an if statement sometimes to be more convenient than to click through IDE windows in order to try to get my breakpoint condition right.

Kermos:

Speed can matter even when debugging. And honestly, I find an if statement sometimes to be more convenient than to click through IDE windows in order to try to get my breakpoint condition right.

 

I can't believe your code skills are bad enough that you actually feel the need to try and defend optimization of debugging code. 

You should really learn to use your IDE, and your brain. There are much better things to spend your time on than debugging optimization, like writing code that actually works.

KenW:

Kermos:

Speed can matter even when debugging. And honestly, I find an if statement sometimes to be more convenient than to click through IDE windows in order to try to get my breakpoint condition right.

 

I can't believe your code skills are bad enough that you actually feel the need to try and defend optimization of debugging code. 

You should really learn to use your IDE, and your brain. There are much better things to spend your time on than debugging optimization, like writing code that actually works.

Would you say it's a problem to optimize ones data, to cause the breakpoint to hit sooner? I ask, as that's what I tend to do here. I don't think I've ever encountered a situation where I needed to run through a loop section more than 100 times to get to a particular scenario.

That *having* been said, using a construct such as 'if (const == variable) { noop; }' to be able to break when one wants to actually takes far less brain power for some people than conditional breakpoints - especially in some IDEs I've seen, that make them far too complicated. No, I can't cite a reference; I'm repressing it.

Sorry for the delayed response. Nasty little crunch this week to get something done by September 1st.

tgape:

Would you say it's a problem to optimize ones data, to cause the breakpoint to hit sooner?

 

I'm not sure how you would "optimize data", but if that means "reduce the amount of data you have to process" to get to the breakpoint faster, then sure. I had code a while back to process a large (> 1GB) text file in a really nasty format. The code would blow up about 3/4s through, and obviously that would have been a pain to debug using just a breakpoint. So I put in code to show enough relevant data to identify the location in the file when it exploded, and ran it again. I then created a copy of the file, deleted most of the data (maintaining structure) before that location, and set a breakpoint there. I'm not sure you'd call that "optimizing" data, though.

tgape:

That *having* been said, using a construct such as 'if (const == variable) { noop; }' to be able to break when one wants to actually takes far less brain power for some people than conditional breakpoints - especially in some IDEs I've seen, that make them far too complicated.

Agreed, although we primarily use CodeGear's RAD Studio (Delphi and C++ Builder) here; Delphi allows inline assembly, so a simple block like

if (SomeVariable = SomeValue) then  asm int 3 end; 

works to trigger the debugger with a single line of code and a two second compile. 

 

SenTree:

Nelle:

SenTree:

That was my thought, I use the same technique in C when I have a set of functions with identical parameters, where not all functions actually use all parameters.

 

i think this works as well : 

void iDoNotUseParams( int /* p2 */, void * /* p2 */ )

{

[...] 

} 

I think it probably would; either method is valid C. However, our coding guidelines (based on MISRA) specify that all function parameters shall be named, and that the identifiers in the declaration and definition shall be identical, but they say nothing about lines of the form x = x;

 

 

 I have seen the following form used:

void iDoNotUseParams( int p1, void * p2 )
{
    (void)p1;
    (void)p2;
}

This makes it fairly clear.