Menu
▾
▴
RE: [MO-java-dev] Volunteer: Ted Husted
|
From: Tim M. <tim...@po...> - 2002-08-26 17:20:45
|
As I haven't actively commited any code since donating the original stuff - I think its probably unfair for me to cast a vote - although any new blood that is willing to put some energy into the thing is welcome. However I am still slightly nervous by the Java Doc discussion going.. I wouldn't want to see the mock objects project go the way of the SUN JavaDoc which is quite frankly useless!!! At the method level the doc simply states everything that the method signature gives - what a waste of energy. In many projects - Class docs can be useful - but again they usually are out of date. Overall project documentation is useful - examples are even more useful. So maybe I'm a bit jaded - or maybe I'm just used to using good tools like Idea, Eclipse, Visual Age that let me browse source code as documentation??? What tools do you use Ted - is this what is making you rely on java doc so much? Of course - even more poignantly - Mock Objects are just replicas of real objects - so the only documentation would be the orginal docs wouldn't they? I will agree there are classes like ExpectationList etc which aren't - so maybe they are candidates - but they are very simple... So Maybe - I (we?) need some examples of what java doc Ted feels needs adding. Maybe if he doesn't mind doing some doc for a class or two and we can have a look at it. It could be that we've missed something important that Ted has picked up on - however I think we agree that we don't want to do java doc just for java doc's sake right? Tim -----Original Message----- From: moc...@li... [mailto:moc...@li...]On Behalf Of Ted Husted Sent: 25 August 2002 17:42 To: Vincent Massol Cc: 'MockObjects' Subject: Re: [MO-java-dev] Volunteer: Ted Husted Since the MockObjects Java API, by definition, has to implement many methods as stubs, browsing the CVS is much more difficult than it would be if this was a finely-tuned XP codebase. My suggestion would be that we (meaning I) provide JavaDocs for methods that provide functionality, but continue to omit them for "notImplemented()" stub methods. This will make it easier for *users* to zoom in on what they need to know. As is stands, because of all the red-tape methods, it is very hard to see the forest for the trees. Respectfully, I would also suggest that XP teams do not omit JavaDocs because of the presumed clarity of the code. The precept is that XP runs on conversation and unit tests rather than on paper *and* that everyone will be cross-trained through pair programming. An affect of the combined XP team practices is that conventional documentation tends to become redundant. Since this is a public API -- and not an application being developed by a closely-knit team -- we can't rely on many of the XP staples, like real-time conversation and pair programming. I agree that it is redundant a nd counterproductive to document stub methods. But I do feel that omitting JavaDocs for implemented and additional methods will make the API harder *for users* to access. IMHO, dismissing JavaDocs for a public API is not playing to win. Of course, I'm not asking anyone else to do anything. But I would like to volunteer to provide JavaDocs and package overviews for the implemented methods -- for the combined benefit of the thousands of developers who (we hope) will be using the API. I would also be happy to address any code-style issues as I go. As for my own stuff: I am trying to turn over a new leaf and move to test-driven design. My own toolkit - http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/#dirlist does not have unit tests. When I tried to just add application-level unit tests for my latest project, - http://sourceforge.net/projects/wqdata I found the lack of mock objects for my toollkit made testing difficult. Since many of my classes work closely with the Java API, I then found that I need to use some standard Java mock objects along with my own. Which brings me here. Since you were looking for help, I thought this would be a good time to become involved with the MockObjects project and share what I learn as I go. -Ted. Vincent Massol wrote: >Hi Ted!, > >Hey, that's great! I'd love to have you join us. I'm +10000 :-) > >Warning: <xp mantra>The consensus on this project is to have no javadoc >(a la XP). The belief is that the code should always be so simple as to >not require any javadoc. If it's too complex, it needs refactoring. In >addition, unit tests are provided and should act as documentation</xp >mantra> > >Code formatting would be great. Actually, I need to work with Steve to >mavenize Mock Objects and thus also benefit from the checkstyle reports. > >Have you been using mock objects on your projects ? > >I'd like to add you right now, but I guess I need to wait for the other >project admins to have a say ... > >For all: Having Ted participate to our project is a god send! He is a >very well known committer in jakarta land and has always produced >excellent work. > >Thanks >-Vincent > >>-----Original Message----- >>From: moc...@li... >>[mailto:moc...@li...] On Behalf Of >> >Ted > >>Husted >>Sent: 23 August 2002 20:38 >>To: moc...@li... >>Subject: [MO-java-dev] Volunteer: Ted Husted >> >>I would like to volunteer to work on the Code formatting and Javadoc. >>I'm a Committer to the Jakarta Struts and Commons, as well as a couple >>other Sourceforge projects. My SourceForge handle is thusted >> >>-Ted. >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by: OSDN - Tired of that same old >>cell phone? Get a new here for FREE! >>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>_______________________________________________ >>Mockobjects-java-dev mailing list >>Moc...@li... >>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev >> > > > >------------------------------------------------------- >This sf.net email is sponsored by: OSDN - Tired of that same old >cell phone? Get a new here for FREE! >https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >_______________________________________________ >Mockobjects-java-dev mailing list >Moc...@li... >https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Mockobjects-java-dev mailing list Moc...@li... https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002 |
