Greg Ercolano wrote:
>> Strictly speaking not a doxygem problem, but at the source level there
>> are a lot of places where function/method signatures are not specified
>> in a consistent way, with (int,int,int) for example, or with different
>> parameter names in different places. We should address these too.
>
> Yes, changing the code to use meaningful variable names.
> This is going to be tricky/scary, esp. for single letter names;
> very hard to search/replace.. have to be careful.
Hmm, I just noticed something interesting.
It appears doxygen advertises the variable names in the prototype
in the .H file, and not the declaration in the .cxx
This, even if the docs are in the .cxx.
I noticed that in my .H file I had:
void remove(int t);
..but in my .cxx, where the doxygen docs are, I had:
/// Doxygen comment here..
void remove(int index) { .. }
Note I used 'index' as the parameter in the .cxx file,
but just had 't' as the parameter name in the .H file prototype.
doxygen still used the 'int t' from the .H file prototype,
even though the docs aren't in the .H file.
In a way, this might be good for us, because this way we can change
the .H files to use descriptive names in the prototypes so they'll
show up in the docs, while leaving the source code parameter names
the way they are, avoiding to have to carefully search/replace those
single letter names throughout the old source.
This is may be by design.. I imagine doxygen shouldn't have to force
programmers to use long descriptive variable names in their source code,
just the prototypes.
Or, maybe we should change the source anyway, though that might be
a big job. Traditionally, FLTK uses lots of short variable names..
and I've never found that to be much of a problem for maintenance.
Certainly keeps the code short and readable.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
