[Libreoffice] Splitting up source/header files for clarity
Soeren Moeller
soerenmoeller2001 at gmail.com
Wed Jan 12 11:48:36 PST 2011
Hi Thorsten
Thank you very much for your review, I attached a new patch (the three
patches together contain the old patch and the fixes), and below
commented on some of your your remarks.
2011/1/12 Thorsten Behrens <thb at documentfoundation.org>:
> Soeren Moeller wrote:
>> > I have now splitted the implementation of funcdesc.hxx out into a new
>> > source file funcdesc.cxx.
>>
> Hi Soeren,
>
> first off, many thanks for going to clean this up, your work here is
> much appreciated! That split so far looks good.
>
>> > In the process I also have extracted two new header files for
>> > classes previously defined in global.cxx.
>>
> That's not necessary - ScResourcePublisher and ScFuncRes are only
> used inside global.cxx, thus need no extra header - in fact, this
> would not be idiomatic for c++. Simply leave them next to the code
> that's using them.
After moving the implementation of funcdesc.hxx to funcdesc.cxx, now
its only funcdesc.cxx which uses ScResourcePublisher and ScFuncRes,
while they aren't used in global.cxx anymore. So I have now moved both
declaration an implementation of these two classes into funcdesc.cxx.
>
> See a few more comments inline of the actual patch:
>
>> diff --git a/sc/inc/funcdesc.hxx b/sc/inc/funcdesc.hxx
>> index d94d9b2..5f3ca7e 100644
>> --- a/sc/inc/funcdesc.hxx
>> +++ b/sc/inc/funcdesc.hxx
>> @@ -34,39 +34,161 @@
>> * global.cxx
>> */
>>
>> +#include "scfuncs.hrc"
>> +
>> #include <tools/list.hxx>
>> -#include <tools/string.hxx>
>> +//#include <tools/string.hxx>
>>
> Please remove, don't comment out.
Sorry, this was an error, it seems I forgot to remove the line before comitting.
>
>> +/**
>> + Contains description of a function
>> +*/
>> class ScFuncDesc : public formula::IFunctionDescription
>> {
>> public:
>> + /**
>> + Constructor
>> + */
>> + ScFuncDesc();
>>
>> - virtual ::rtl::OUString getFunctionName() const ;
>> + /**
>> + Destructor
>> + */
>> + virtual ~ScFuncDesc();
>>
> Those doc-comments don't provide any value. Destructors and nullary
> constructors seldomly need any comment at all, and for the class,
> I'd suggest something along the lines of "Serves human-language
> function descriptions within the calc formula parser framework" - or
> somesuch. Did not look too closely, TBH. ;)
>
> Two related golden rules for good comments/documentation:
>
> Good comments don't repeat the code or explain it. They clarify its
> intent. Comments should explain, at a higher level of abstraction
> than the code, what it does.
>
> or, put bluntly:
>
> Don’t insult the reader’s intelligence ;)
Thank you for your tips, I have now removed the non-informative
comments, and added a clearer description of the intention (as far as
I can see from the code) of this class
>
>> + /**
>> + Resets the object in a clean manner
>> + */
>> + void Clear();
>>
> For one-liners like this, I'd prefer this markup:
>
> /// Resets the object as if it were newly constructed
>
> (well, does clear() perform that? writing good comments usually
> involves some detailed code review, or even debugging)
I have now added a more precise comment to Clear.
>
>> + /**
>> + Returns the category of the function
>> +
>> + @return the category of the function
>> + */
>> virtual const formula::IFunctionCategory* getCategory() const ;
>>
> Since these methods are inherited from the IFunctionDescription
> interface, I'd rather document them there (in the formula module).
> That way, all derived classes benefit from your documentation (and
> doxygen is smart enough to link that).
>
>> + /* Public variables */
>>
> I'd consider this redundant. If you want to comment on the fact that
> this class exposes its data structures, try to reconstruct the
> reason why this is so - e.g. a bug number, for which it was added,
> e.g. in a hurry before a shipment, to keep changes minimal (and
> later cleanup was forgotten). Else, the reason would be "programmer
> lazyness / sloppy coding", and that's a default assumption that
> needs no comment. ;)
>
>> - USHORT nFIndex; // Unique function index
>> - USHORT nCategory; // Function category
>> - USHORT nArgCount; // All parameter count, suppressed and unsuppressed
>> - USHORT nHelpId; // HelpID of function
>> + sal_uInt16 nFIndex; // Unique function index
>> + sal_uInt16 nCategory; // Function category
>> + sal_uInt16 nArgCount; // All parameter count, suppressed and unsuppressed
>> + sal_uInt16 nHelpId; // HelpId of function
>>
> Ok to change, but I'd then also adapt the other occurences. And
> maybe make that a separate patch - makes review easier, and ensures
> that uncontroversial changes get in right away. :)
Now I also have changed the types in the implementation in funcdesc.cxx
Regards
Sören Möller
(LGPLv3+ / MPL)
>
> Could you quickly brush this up a bit & resend? As I said, otherwise
> good & useful!
>
> Cheers,
>
> -- Thorsten
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Moved-funcdesc-s-implementations-out-of-global.cxx.patch
Type: text/x-patch
Size: 65352 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110112/1308aff6/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Minor-fixes-to-the-previous-patch.patch
Type: text/x-patch
Size: 4487 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110112/1308aff6/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Minor-fixes-to-the-previous-patches.patch
Type: text/x-patch
Size: 12109 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110112/1308aff6/attachment-0005.bin>
More information about the LibreOffice
mailing list