addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrosseditemptyheartexportfacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [ljc] Return types

From: Jon H.
Sent on: Tuesday, February 12, 2013 9:17 PM
I would type "return;" to explicitly return before full execution of the method. Otherwise no return keyword at all, that is the very nature of void methods. The "Void" return type is misleading because it implies that a potentially not null object (like all objects) can be returned, which cannot actually happen.

If doing this to avoid primitives for reflection, it makes a bit more sense.

Unless I am missing something this looks to me like an idiosyncrasy of your company.

Cheers,
Jon

Sent from my HTC

----- Reply message -----
From: "Jonathan McNealy" <[address removed]>
Date: Tue, Feb 12,[masked]:14
Subject: [ljc] Return types
To: <[address removed]>

Hi guys,

We've been debating this for a while here, and we can't decide between the following two development methodologies with respect to the return statement.

It's currently policy to write functions that don't return a value like this:

public Void doTask() {
  ...

  return null;
}

this is best because:
- everything should be an object (Integer instead of int, and so on)
- it's type-safe
- reflection is more consistent, as the primitive/object difference api is a pain
- allows multiple calls on one line (saving vertical space, e.g. return runStuff(doTask()))

however some of the newcomers to the company are rather dismissive of the benefits of Void, and insist of the following nasty and inconsistent way of doing it:

public void doTask() {
  ...

  return;
}

and some deviants even insist on removing the return statement:

public void doTask() {
  ...
}

!!

I'm currently in the process of writing up a JSR to only support the Void/return null pattern, as it's clearly the most consistent and only having one way of doing something is the best approach, however I'm curious as to what the community thinks about the issue.

Please don't cheat by casting your vote more than once!

Kind regards

J.





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Jonathan McNealy ([address removed]) from LJC - London Java Community.
To learn more about Jonathan McNealy, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy