Greg Ercolano wrote: > I don't think the FLTK coding standards cover the issue of naming > new methods regarding 'setting' vs. 'getting'. > > It seems FLTK likes to use set_xxx() to 'set' things, and xxx() to 'get'. > There's a pretty long list of these, as noted in my Nov 5th comment in this > STR: > http://www.fltk.org/str.php?L2083 > > I'm thinking the FLTK coding standards should probably explicitly cite this > under the section for "Function/Method/Variable Naming", eg. something like: > > Methods whose operations set and get values should be named > set_xxx() to 'set' the values, and xxx() to 'get' the values, e.g. > > widget->set_modal(); // set it > if ( modal() ) { .. } // get it > > widget->set_changed(); // set it > if ( widget->changed() ) { .. } // get it > > > ..and should probably weigh in on how to 'set' vs. 'clear' should > be specified, eg. whether to use separate methods for each: > > set_xxx(); > clear_xxx(); > > ..or to only have one set_xxx() method that takes an optional bool: > > set_xxx(); // set: same as set_xxx(1); > set_xxx(0); // clear > set_xxx(1); // same as set_xxx(void); > > I'm not sure myself which FLTK prefers, or if it should be one over the other.
I agree that there should be a standard proposed in the FLTK coding standards document. However, I think that your analysis covers only the exceptions, because you searched only for "set_", "is_", and "ed()" as you described in the link above. IMHO, the majority of methods doesn't use any prefix or suffix for distinction of get and set methods, if feasible. E.g. look at the documentation of Fl_Widget and lots of other widgets. label(), box(), align(), ... all use a get method without an argument and a set method with one or more arguments. My conclusion: The preferred FLTK naming convention seems to be one name with different arguments, as described above, with exceptions, where the preferred naming would be misleading or "unusual english", as with the discussed maximized(). I am aware that modal() and set_modal(), as well as some other exceptions from this rule exist, but that's what it looks to me. Maybe some of them are due to the history as a forms replacement. Bill and Mike can surely tell as more ... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
