[tetrep]

>What value did the comment have in the first place?

That comment is the only indicator that something may be wrong. Your next steps are the same as with any suspected bug, find out what the code is doing (seems obvious here) and then find out if that's what it should be doing.

That comment, however, is a good example of a bad comment. In this particular scenario, it's very obvious what the code is doing, so the comment should describe why the code is doing what it's doing. Much like should do:

    //set volume to 5
    x = 5;

Rather than:

    //set x to 5
    x = 5;

[glimcat]

> That comment, however, is a good example of a bad comment.

Yes, assuming there's not some contextual reason why hardware acceleration is obviously inappropriate. But even then, it would be much better to err on the side of "assume the next person to read it hasn't had their coffee yet."

Even something like "don't use hardware acceleration because compatibility issues" would be a better comment. You don't need an essay. But it should be both concise AND descriptive of the issue, not just normative or prescriptive.

[swanson]

Nope. You should do

  volume = 5;

Or

  setVolumeLevel(5);