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 <r...@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 <r...@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? > > > > >
