Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6C9C06E66 for ; Mon, 25 Jul 2011 15:23:11 +0000 (UTC) Received: (qmail 70800 invoked by uid 500); 25 Jul 2011 15:23:10 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 70694 invoked by uid 500); 25 Jul 2011 15:23:10 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 70686 invoked by uid 99); 25 Jul 2011 15:23:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2011 15:23:10 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com designates 209.85.213.43 as permitted sender) Received: from [209.85.213.43] (HELO mail-yw0-f43.google.com) (209.85.213.43) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2011 15:23:04 +0000 Received: by ywt2 with SMTP id 2so2473871ywt.30 for ; Mon, 25 Jul 2011 08:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=b76Bh+YRAuHg/o2pQk0EauSQWFsyf1KEfwXRmK/2Hac=; b=bMJn4Af8ogXPZnO+NoiH3tps08ByeqHGJiKAKWmx9dX3VUn8C1q1KpRmin8MrwA/fE 2gWiDQpVC5zL5LbazVzxCKbUviNQI6JG6oLRkOcIb8t2m51QOjqx7PzNoH3iCkfmlLkj S28neEMOxo4wEIW6hgbwaFvyR5QmvosViXhDE= Received: by 10.142.188.17 with SMTP id l17mr3073834wff.156.1311607362721; Mon, 25 Jul 2011 08:22:42 -0700 (PDT) Received: from a.local (71-223-74-208.phnx.qwest.net [71.223.74.208]) by mx.google.com with ESMTPS id t20sm3219622wfe.0.2011.07.25.08.22.39 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 08:22:40 -0700 (PDT) Message-ID: <4E2D8A3D.6060704@gmail.com> Date: Mon, 25 Jul 2011 08:22:37 -0700 From: Phil Steitz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [math] Inherits doc and @Override References: <1311315486.2827.2.camel@knuffelchen> <20110724221359.GI7045@dusk.harfang.homelinux.org> <4E2C9BAB.6000508@gmail.com> <4E2D0D85.2020606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/25/11 6:31 AM, Matt Benson wrote: > On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt wrote: >>>> Good code needs little javadocs. >>> I disagree strongly. >>> >>> The Javadoc should present the public API (and should ideally be >>> written before the code - i.e. the code implements the docs). >>> >>> If the only documentation is the code, it is much harder for users to >>> determine how to use the API. > I have to agree. Ever programmed against cglib? When depending on > libraries with no javadoc, I invariably find myself going to the code, > which I really shouldn't have to do. Of course, I must admit that > even for libraries that appear to be reasonably well-documented (e.g. > Spring), I still often end up going to the code. > >>> For some code (interfaces, abstract methods) only Javadoc is available. >> Did you even bother to read the blog post? > I read it, Torsten. What I get from its main theme though is that you > are encouraging the class-level "book" comment one sees in e.g. > oac.jxpath.JXPathContext or Mockito's main Mockito class. I suppose > that's a matter of preference, but personally I prefer to digest an > API in smaller bits than that. Honestly, I think its best to have both. Good class-level javadoc describes the overall function of the class, primary properties and use cases and macro-level considerations about what the class expects from or how it interacts with its execution environment. Method level javadoc specifies contracts. If you have to skimp on one of these, for library code it is in general better to focus on the method-level documentation, because that is what the user always sees and depends on and also what can be validated by the unit tests. Phil > > Matt > >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org