views:

415

answers:

8

In some situations using C/C++, I can syntactically indicate to the compiler that a returnvalue is purposely ignored:

int SomeOperation()
{
    // Do the operation

    return report_id;
}

int main()
{
    // We execute the operation, but in this particular context we
    // have no use of the report id returned.
    (void)SomeOperation();
}

I find this to be a fair practice, firstly because most compilers won't generate a warning here, and secondly because it explicitly shows to future developers that the author made a concious choice to ignore the return. It makes the author's trail of thought non ambiguous.

As far as I know, the C# compiler won't complain about implicitly ignored returnvalues, but I would like to know if there's a similar convention to use in order to make a clear indication to other developers.

EDIT:

In response to some people here who questions the actual use of this convention (or that it would show bad design to have a method with a potentially unimportant return value).

A real life .NET example (which I maybe should have based the question on from the start) is the Mutex::WaitOne() overload which takes no arguments. It will only return if the mutex was safely aquired, otherwise it never returns. The boolean return value is for the other overloads where you might end up not being in possession of the mutex when it returns.

So along my reasoning, I would like to indicate in my multi-threaded code that I have made a choice to ignore the return:

Mutex mtx = new Mutex();
(void)mtx.WaitOne();

Since the returnvalue never can be anything but 'true'.

+7  A: 

The Microsoft C# compiler doesn't generate a warning on ignoring returns. It doesn't need to since there is a garbage collector so there won't be any memory leakage because of ignoring returned objects (unless they are IDisposable of course). Hence, there's no need to explicitly "override" the compiler.

EDIT: Also, I believe "maintainability" issue is more like a documentation and naming practice issue. I understand that this was only an example, but you wouldn't expect a method called SomeOperation to return a ReportId. You would, however, expect a GetReportId method to return a ReportId without having a lot of side effects. Indeed, ignoring the return value of a method called GetReportId would be rather strange. So, make sure that you name your methods well and people won't have doubts about the effects of your function calls.

EDIT 2: In this example of mutexes, I believe that the right usage would be actually not ignoring the return value. Even if the current implementation will never return false, I think it's good practice to still check the return value, just in case you will end up using another implementation in the future or they change the behaviour in a future release of the .NET Framework or something:

if (mutex.WaitOne())
{
   // Your code here
}
else
{
   // Optionally, some error handling here
}
DrJokepu
Understood. But as I mentioned in the question I would like to use the convention to explicitly indicate to other developers that I ignore the return on purpose. I'll update it to make it more clear.
sharkin
In response to your edit, see my update of the question.
sharkin
+9  A: 

I can only think of one situation, when a "return value" is not allowed to be ignored in C#: when an error occurred. This should be provided by throwing an exception, which makes it impossible to be ignored.

In other cases, it is (or better: must be) completely safe and not smelly at all to ignore return values.

EDIT:

I still can't see the point. Why should this improve the code? You specify to ignore the return value by purpose by not assigning it to a variable.

  • If you don't need this value in your code, everything is fine.
  • If you need it, you won't be able to write your code.
  • If there is a special case which must be handled and must never be implicitly ignored, an exception should be thrown.
  • If the called method did not have a return value and gets one later, it must be designed to not break existing code which ignores it. The existing calling code does not change.

Did I forget a case?

Stefan Steinegger
Good answer, because error codes shouldn't be returned in .Net, all other values are safe to ignore because they should only represent computation results or other info not representing error statuses.
Pop Catalin
@Stefan: I agree, but since errors should be handled by exceptions, the role of return values is more likely to be more of the status/info kind, which in my opinion validates the question even more.
sharkin
A: 

No standard conventions I'm aware of.

But I'm struggling to find a good reason for needing this. It sounds like SomeOperation() should really be two separate methods. Have you got an example of a method which really should behave this way? Why should a method bother returning a result if it's going to be ignored?

Matt Lacey
I updated the question with an example.
sharkin
Are you really going to refactor just because there's one place where you don't need the return value from a function? Personally, I *might* write a small function that just calls the existing one using a local dummy variable for the result, but doesn't return anything itself - but very likely not. Sure, I agree, why return a result if it's going to be ignored, but then again why have two nearly identical functions? And why prefer premature optimisation to clean, minimally cluttered code? Also, the function may be inlined and compiler-optimised anyway.
Steve314
Steve314 - I wasn't saying that it must require a refactor. I was trying to hint that this seemed like a code smell to me. I was therefore wanting to make sure this was a real problem, not just one created by something else.
Matt Lacey
@Matt - IMO it's not really a code smell. I've seen far too many functions that return a value basically because it's calculated anyway, and it's often useful. Also many functions return success flags, but sometimes the context guarantees the return-true kind of success anyway. There *are* good reasons for ignoring return values. It isn't the norm, but it's far from unusual. I agree with your claimed motive, but the final sentence of your answer reads as sarcastic criticism - and invalid sarcastic criticism at that, given that any one function can have many callers.
Steve314
A: 

Sometimes it's useful to be able to put in (void) to indicate to a future coder looking at the code that you know perfectly well it returns something, and you are deliberately ignoring it.

That said, the C# compiler will error on the syntax.

Chris KL
A: 

I've seen:

var notUsed = SomeOperation();

Not so fond of it though.

Jonas Elfström
+1  A: 

object dummy = JustDontCare();

wefwfwefwe
The traditional name is "dummy" variable.
Steve314
-1 for using a variable. Why not just drop the return value?
Charlie Somerville
(from Chris KL) ...to indicate to a future coder looking at the code that you know perfectly well it returns something, and you are deliberately ignoring it.
wefwfwefwe
@Charlie - Personally, I would just drop the variable, but that misses the point of the question. And the idea is reasonable. Some languages force you to do this kind of thing because they consider implicit discarding of return values evil.
Steve314
A: 

The convention in .Net is, if you don't store or use a return value that means you ignore it implicitly, there's no explicit convention, and the API is generally designed so return values can be generally ignored, with the exception of boolean values representing fail, success state.

But even in the case of Boolean return values representing success/fail status, the convention is that if you ignore the return value (don't use it) that means the code doesn't depend on the success status of previous call.

Pop Catalin
I appreciate the fact that some things are common practice in C#, but when speaking in general (in particular for vast projects) the quality of the code is always increased when the author's trail of thought is explicit and non ambiguous.
sharkin
Well if you are concerned by quality of code, ignoring return values that can be "safely" ignored and are not needed doesn't increase code quality. If an explanation is needed why the value is ignored except that is not needed, then a comment would be more adequate, because it would explain the "why", and not state the obvious "the value is ignored". There's no convention to state the obvious (the return value is ignored), because ignoring the return value is rarely and error, it's usually by choice in .Net.
Pop Catalin
+4  A: 

If you want to indicate to other developers and make it crystal clear that the return value is intentionally ignored, just comment it.

SomeMethod(); // return value ignored - $REASON
Charlie Somerville
Yup, this is what I would do as well. +1
Eyvind