-
Notifications
You must be signed in to change notification settings - Fork 0
Naming
It is important to maintain a consistent naming policy throughout the code base, so names are predictable and easy-to-guess.
Most of the key principles and conventions are listed in the Ki wiki:
Here are a few GoGi specific cases:
It seems conventional in HTML to use lowercase with hyphen separator for id naming (i.e., "kebab" case, as in words skewered by hyphens on a shish-kebab). And for states such as :hover :active etc
- https://stackoverflow.com/questions/1696864/naming-class-and-id-html-attributes-dashes-vs-underlines
- https://stackoverflow.com/questions/70579/what-are-valid-values-for-the-id-attribute-in-html
- https://www.w3schools.com/cssref/css_selectors.asp -- specific selector names
We adopt that convention, which then provides a clear contrast to the UpperCase Go code.
In general, most methods that affect the display of a widget should be wrapped in UpdateStart / UpdateEnd, unless they are clearly very internally used only within a larger overall update.
However, only some methods should send a signal indicating some important event to any outside users of the widget. These should generally have the term Action appended to them. E.g.,:
-
SetValuekinds of methods are wrapped in updates, but do NOT emit a signal -
SetValueActioncalls SetValue and emits the signal
A somewhat tricky case are accessor methods that might need to apply changes before returning a valid value. In particular, the TextField has a Text() method that is designed to be used by the "end user" to obtain the edited text value -- it does an "apply" of any changes, and therefore sends a signal associated with that. This overall seems better than having to call TextAction() or something like that, and internal methods can avoid calling Text() when they need to access the current edited text without signaling.
Whenever you need a special type that drives a special ValueView for editing that type, the convention is to use *Name where the Name is then uppercase. This violates the general principle of using Filename instead of FileName but to keep it consistent and clear that this is that kind of special type, we do that.