commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)
Date Sun, 20 Jul 2014 12:04:48 GMT
I like using all "get" methods and no "is" methods. It is simpler and makes the getters easier
to access as a group with code completion IMO. The with methods do not behave like Java bean
method so I do not thing we need to worry about that. Unless we want to register immutability...

Gary

<div>-------- Original message --------</div><div>From: Benedikt Ritter
<britter@apache.org> </div><div>Date:07/20/2014  04:02  (GMT-05:00) </div><div>To:
Commons Developers List <dev@commons.apache.org> </div><div>Subject: Re:
[CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons
CSV 1.0 based on RC1) </div><div>
</div>using "get" for methods that return booleans is very uncommon imho...

how about leaving all the gramme stuff out and use:

void withSkipEmptyHeaders(boolean)
boolean isSkipEmptyHeaders

that would
- restore symmetry between getter and setter
- almost follow JavaBean conventions (except for the "with")

br,
Benedikt


2014-07-20 8:00 GMT+02:00 Dipanjan Laha <dipanjan21@gmail.com>:

> Although i am not familiar with CSV's codebase, imho "get" is more straight
> forward, so +1 to Gary's suggestion.
>
> On Saturday, 19 July 2014, Gary Gregory <garydgregory@gmail.com> wrote:
>
> > On Sat, Jul 19, 2014 at 12:14 PM, Emmanuel Bourg <ebourg@apache.org
> > <javascript:;>> wrote:
> >
> > > Le 19/07/2014 13:48, Gary Gregory a écrit :
> > >
> > > > Can we go back to use "get"?
> > >
> > > We are running in circles Gary, Benedikt and I, if others could weigh
> in
> > > that would help.
> > >
> >
> > Circles, back and forth, to and fro, call it what you will. IMO this is
> the
> > nature of the kind of development we do. Decentralized, no water cooler,
> no
> > white board, all emails, leads to this development style, which is what
> we
> > have to live with.
> >
> > In this case, it seems we had to try the code several ways and see it
> > before we can decide. In an office, we might have decided in pair
> > programming in 5 minutes, this is not what we have. That or architect
> would
> > have created some coding edict that imposes coding style.
> >
> > So this circling is all OK by me ;-)
> >
> > Gary
> >
> >
> > >
> > > Emmanuel Bourg
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > <javascript:;>
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > <javascript:;>
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com <javascript:;> | ggregory@apache.org
> > <javascript:;>
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message