spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Nguyen <...@adatao.com>
Subject Re: coding style discussion: explicit return type in public APIs
Date Wed, 19 Feb 2014 06:35:17 GMT
Reynold, perhaps better than enumerating all the rules, it should be
generalized to a guideline that allows this relaxation when the return type
is immediately obvious from the next few tokens in the code. In exceptional
cases of doubt, provide the return type.

The cases you've listed should serve as examples of the guideline.
--
Christopher T. Nguyen
Co-founder & CEO, Adatao <http://adatao.com>
linkedin.com/in/ctnguyen



On Tue, Feb 18, 2014 at 10:23 PM, Reynold Xin <rxin@databricks.com> wrote:

> Case 2  should probably be expanded to cover most primitive types.
>
>
> On Tue, Feb 18, 2014 at 10:22 PM, Reynold Xin <rxin@databricks.com> wrote:
>
> > Hi guys,
> >
> > Want to bring to the table this issue to see what other members of the
> > community think and then we can codify it in the Spark coding style
> guide.
> > The topic is about declaring return types explicitly in public APIs.
> >
> > In general I think we should favor explicit type declaration in public
> > APIs. However, I do think there are 3 cases we can avoid the public API
> > definition because in these 3 cases the types are self-evident &
> repetitive.
> >
> > Case 1. toString
> >
> > Case 2. A method returning a string or a val defining a string
> >
> > def name = "abcd" // this is so obvious that it is a string
> > val name = "edfg" // this too
> >
> > Case 3. The method or variable is invoking the constructor of a class and
> > return that immediately. For example:
> >
> > val a = new SparkContext(...)
> > implicit def rddToAsyncRDDActions[T: ClassTag](rdd: RDD[T]) = new
> > AsyncRDDActions(rdd)
> >
> >
> > Thoughts?
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message