KDE libs documentation policy

John Ratke jratke at comcast.net
Mon Oct 13 00:18:59 BST 2003


Brad Hards wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Sun, 05 Oct 2003 13:46 pm, Benjamin Meyer wrote:
>  
>
>>I have noticed a lot of activity on improving the documentation of the
>>classes in kdelibs and was curious if there was an official policy for the
>>docs of the classes in kdelibs and if not, would there be interest in
>>making an official policy.
>>    
>>
>I'd definatly like an official policy. As one of the people that's been doing 
>some work in this area, I'd suggest:
>1.  enum's have to be overviewed, and each enumerated value has to be 
>explained.
>2. Order is important, or readability is trashed. I've been using @brief, 
>detailed explanation, @param's, @return, @see, @author, @since.
>3. Examples are A Good Thing.
>4. Every UI element needs a picture.
>5. Try to avoid humour and exclamation marks.
>6. "make apidox" before you commit any code.
>  
>
I agree, and also let's add outlawing use of "iff" as a short hand.    
It is used to mean "if blah true, else false", but it is confusing and 
looks like a type-o.  As seen in ktoolbar.h:

@return @p true iff button is on and is a toggle button

As Ben said earlier, we should just mention one case (usually the true 
case), so that should be changed to:

@return @p true if button is on and is a toggle button


Thanks,

-John






More information about the kde-core-devel mailing list