-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Function naming inconsistency #728
Copy link
Copy link
Closed
Labels
C - needs discussionDirection must be ironed outDirection must be ironed outH - good first issueIdeal for new contributorsIdeal for new contributorsS - apiDesign and usabilityDesign and usability
Milestone
Description
Somewhat nitpicky, but there's an amount of inconsistency in our function naming schemes:
WindowBuilder::with_dimensionsvsWindow::set_inner_sizeWindowBuilder::with_visibilityvsWindow::show/Window::hideWindow::get_positionandWindow::get_inner_positionvsWindow::get_outer_sizeandWindow::get_inner_size(get_positionshould beget_outer_position)Window::set_position(should beset_outer_position)grab_cursorandhide_cursorvs all other state-setting functions (should beset_cursor_grabandset_cursor_visibility)set_{min/max}_dimensionsvsget_{whatever}_size(set_dimensionsshould beset_size)
Additionally, there's inconsistency in the word forms of the functions:
with_visibilityvswith_maximized(visibilityis a noun, whilemaximizedis a past-tense verb. Could bemaximization)with_visibilityvswith_resizable(resizableis an adjective. Could beresizability)
I don't feel too strongly about the word-form inconsistency since that's hard to get right and being consistent may force us to use uncommon forms of the words, but the other inconsistencies should be addressed. Being consistent will reduce the mental overhead of using the API and should reduce the amount of time users spend referring to the API docs to find which naming variation is used for each specific function.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
C - needs discussionDirection must be ironed outDirection must be ironed outH - good first issueIdeal for new contributorsIdeal for new contributorsS - apiDesign and usabilityDesign and usability