got net?

Kevin Hazzard's Brain Spigot

About the author

Welcome to Kevin Hazzard's blog.
E-mail me Send mail

Recent posts

Recent comments

Authors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010

Methods Should Never Return Void

Returning void (or Nothing in VB.NET) from a method is best the way to say, "I don't care about you, caller." Consider this silly C# code:

var engine = Python.CreateEngine();
var scope = engine.CreateScope();
scope.SetVariable( "PIRoot", Math.Sqrt( Math.PI ) );
var result = engine.Execute<double>( "PIRoot ** 2", scope );
Console.WriteLine( result );

This code could be a lot more fluid but the ScriptScope.SetVariable method returns void. If the method returned a reference to its Engine property, the code could have been written more succinctly as:

Console.WriteLine( Python
    .CreateEngine()
    .CreateScope()
    .SetVariable( "PIRoot", Math.Sqrt( Math.PI ) )
    .Execute<double>( "PIRoot ** 2", scope ) );

Wouldn't that be nice? So don't return void (or Nothing in VB.NET). When you have nothing else you can return from an instance method, return the this pointer (or Me in VB.NET).

 


Categories: C# | DLR | Rant | Software Dev
Posted by kevin on Tuesday, January 06, 2009 9:53 PM
Permalink | Comments (4) | Post RSSRSS comment feed

Comments

Al Tenhundfeld United States

Wednesday, January 07, 2009 11:30 AM

Al Tenhundfeld

I completely agree with this sentiment, but I would qualify "never" a little by prepending Externally Exposed to the statement. I have no problem with private methods returning void if that makes life easier.

Externally exposed (especially public and internal) instance methods should never return void. If a designer feels strongly that void is better for certain categories of methods, then make a design decision and be consistent about it. It is frustrating to work with an API that has two semantically identical methods with one returning void and the other returning a default reference.

I think many times a method returns void, because there's more than one valid option for the return value. At least that's been my experience when experimenting with fluent interfaces. For example, in your code above, I would probably make ScriptScope.SetVariable return a reference to the ScriptScope, thinking that callers would often want to set more than one variable.

Todd King United States

Thursday, January 08, 2009 12:27 PM

Todd King

This principle has been around for decades with Smalltalk.
  - Function messages should produce no side-effects on the target object, and the reply is a reference to some object.
  - Procedure messages can potentailly modify the target object and therefore the reply is a reference to the target object.

Simple but effective principles.  "Old" is the new "New".  Wink

Kevin Hazzard United States

Thursday, January 08, 2009 1:44 PM

Kevin Hazzard

Smalltalk! It's always Smalltalk where the good ideas come from. Why is that? Smile

Kevin

mesa de ruleta United States

Thursday, April 02, 2009 4:09 AM

mesa de ruleta

I admit, I have not been on this webpage in a long time... however it was another joy to see It is such an important topic and ignored by so many, even professionals. I thank you to help making people more aware of possible issues.
Great stuff as usual....

Comments are closed