I just came across this article, and in particular, this answer. Essentially they're talking about returning self from instance methods to allow for method chaining. That being said, one of the first thoughts that came to mind was, Why not always take instance methods with void return types and make them return this or self instead? The next thought, which came to mind immediately, was, There's probably a reason this isn't more common. So what could be the harm in it?

It seems like there honestly wouldn't be any. The reason is that nothing about the mere existence of a return value implies or even seems to imply the need to use that return value. If the method is a specialized getter or file reader or something, that's one thing, but if people aren't looking to use the return value, they naturally won't pay one any attention. Furthermore it shouldn't be too confusing, because return this; is pretty trivial; at most, somebody would probably think it's irrelevant. It certainly seems like it wouldn't hurt anything, and it's generally better to have too much than too little.

closed as primarily opinion-based by gnat, user40980, Bart van Ingen Schenau, Kilian Foth, GlenH7 Apr 24 '14 at 13:30

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    recommended reading: Discuss this ${blog} – gnat Apr 22 '14 at 15:42
  • 1
    It's not done more often because it's a convention that would be useless most of the time, misleading some of the time, misused half of the time, and unnoticed when actually relevant. It goes against YAGNI. – MetaFight Apr 22 '14 at 15:47
  • 1
    I am not sure there is anything constructive to add that is not already covered in the question/answers to which you linked. – user22815 Apr 22 '14 at 15:56
  • 1
    re: your update. If I'm working with an API, I will be checking return types. If I expect void and see something else then I'll stop and think about why it's not void. If there's no good reason other than "why not?" then I'll be left scratching my head about it. After all, why would something like gameComponent.Draw() return a GameComponent? If you aren't going to need it, then don't do it. It just adds unneeded complexity and additional points of failure. – MetaFight Apr 22 '14 at 15:57
  • 1
    @Panzercrisis: Your question would be a better one if it didn't simply boil down to "is this good or bad?" There's a difference between questions that examine the relative merit of specific technical issues, and ones that merely discuss opinions. – Robert Harvey Apr 22 '14 at 16:13

In general, methods returning void should be uncommon. Why? It means that for the method to do anything meaningful, it needs to mutate the class or have some other side effect. Mutations and side effects generally cause trouble with concurrency, testing, and reasoning about the correctness of your program.

Worse, the trend in modern object oriented programming is to favor immutable objects more and more. What does the function signature look for methods that do some operation and then return a new form of the object (think DateTime.AddHours)? That's right, the same as some self returning mutating function.

And in general, ignoring return values is a code smell, often obscuring error handling or other errors.

In short - it can lead to clean code if that is the idiom in your language/environment, but is a bad idea in general, going against the trends of best practices.

  • Method chaining does not guarantee purity. – Robert Harvey Apr 22 '14 at 16:09
  • @RobertHarvey - no, it pretty much guarantees impurity if you're converting void methods. – Telastyn Apr 22 '14 at 16:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.