> Since FLTK2 and FLTK1 are emulated in FLTK3, there is no need to > comply to either of the predecessors in API naming. > > At first I thought that the fltk2 naming is so much better, and it > is for classes, but the global function names are inconsistent > [...] > Any suggestions on how the global function naming should be in FLTK3?
As I've been writing Python at work for the past couple of years, and although this isn't consistent with other areas of Python, I've become used to our convention with capitalised for class names, camel case for functions and variables, and upper case for constants: ClassName, functionName(), memberFunction(), variableName But as with any "standard" there are always exceptions, usually to do with incorporating abbreviations, eg getRGBIndex() v getRgbIndex() However, what I do think important, and I've raised this before, is that we should think about using a standard set of words so that we can distinguish between length of an array or string in terms of the number of bytes, characters, "glyph columns", and the width of strings in terms of bytes, characters, columns and pixels. D. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
