Duncan Gibson wrote:
[ Albrecht Schlosser wrote:] added
>> Another point is to use better readable names: often it is better
>> to use uppercase letters (e.g. L for label instead of l). This
>> does also avoid a problem where some compilers (or code analysis
>> tools?) would get problems with single letter argument names and
>> a method with the same name (e.g. x and method x()). I remember
>> that Mike did lots of such changes for 1.1.x.
>
> Be careful here though, because I was just doxygenating fl_draw.H and
> *almost* changed:
>
> typedef void (*Fl_Draw_Image_Cb)(void *,int x,int y,int w,uchar *)
> void fl_draw_image(Fl_Draw_Image_Cb,void *,int X,int Y,int W,int H,int D)
>
> to all use uppercase parameter names, when a closer reading of the
> comments showed that the callback function parameter x is not the
> same as the main function X.
Fair point, we need to be careful...
> I do agree that the single letter 'l' is not suitable for a name and
> in many cases I have already changed it to L for label or T for title.
>
> And although I also think that it would be useful to have consistent
> names for the same things across routines, and X,Y,W,H,L,[user]data
> spring to mind as the minimum set, is it really worth the effort of
> going though all of the code (and doxygen comments!) to change them?
IMHO, no, that would be too much effort, and that was not what I
intended to say.
To be more clear:
(1) if we change headers and docs, we should add variable names
(2) if we add variable names, we should use "better" names (for
some undefined value of "better" ;-) )
(3) if there is a potential ambiguity, we should use longer names
or maybe upper case letters
(4) if applicable, we should also use the same name for the header
and the docs.
Many "if"s, I know, and I'm afraid that doesn't make it much clearer,
but that's what was intended. Don't make big code changes just for
changing the names in the headers and docs, but *if* we do it, then
we should do it "right".
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
