-
Notifications
You must be signed in to change notification settings - Fork 0
Coding style
Alexander Ritter edited this page Jul 17, 2022
·
3 revisions
This coding style guide exists to create consistency in our code.
Suggest changes to the coding style in a new issue, but please do not diverge from the style on your own.
-
Strings should be encased with
""
and not with''
. -
Comments start with
#
and one empty space after it to improve readability, better seperating the comment marker from the text
(e.g.# Do sth
and NOT#Do sth
) - Multi-line comments should be written using multiple single-line comments, since Python doesn't have syntax for them and we won't abuse strings
- Always prefer using
True/False
over0/1
- Use American englisch (e.g. "color" and not "colour") to name functions, files and to write comments
-
Filenames: Lowercase only, use underscores instead of spaces (e.g.
create_pointcloud_from_object.py
instead ofCreate-Pointcloud-from-Object.py
) -
Classes start with a capital letter and are written in CamelCase (e.g.
RenderPreview
and NOTrender_preview
) -
Functions are written in lowercase letters only and use camel_case (e.g.
import_mesh()
) - Fields+variables should generally be named lowercase, and with underscores as word seperators
- Constants can be made UPPERCASE if important
- For naming of GUI widgets please refer to point 2. in the Tkinter section
- Try specifying the return type for every method. If it's
None
, you can omit it. - Regarding the types of parameters, here you are free to decide whether to explicitly mention them or not.
However, always consider who needs to use the function and what knowledge you should give them.
If a parameter is of a very specific type (for example a self created object), always specify it (e.g.function(cam: OrbitCam)
)
Example:
# Create and return a bump material to an object, with adjustable scale and detail level of the noise
def bump_material(scale: float = 5, detail: float = 2) -> bpy.types.Material:
pass
(For example Tkinter)
- Always specify the argument names of all external functions, e.g. use
Label(master=self, text="Label")
and NOTLabel(self, "Label")
.
This helps code readability and makes it easier to understand what exactly external functions do.
Tutorial: https://realpython.com/python-gui-tkinter
-
Geometry Managers:
- Generally, use the
.grid()
Grid Geometry Manager, since it is much more flexible and powerful - For very simple frames you can theoretically use
.pack()
, but please prefer.grid()
since it can do the same and more, and is easier to understand since it doesn't depend on the order of function calls - Never use
.place()
- Generally, use the
-
Name widgets by prefixing them with an abbreviation of the widget name or the full widget name, e.g. name a Button that closes the window
button_close
orbtn_close
.Widget Class Variable Name Prefix Example Label lbl lbl_name Button btn btn_submit Entry ent ent_age Text txt txt_notes Frame frm frame_address Checkbutton check check_mesh Scale slider slider_brightness OptionMenu dropdown dropdown_materials -
We are working with a class based GUI.
Try containerizing logical units into a seperate class.
Then, in the superclass, create an object from the class and set its position/layout.
Example:# Create class instances right = RightPanel(master) left = LeftPanel(master) # Layout left.grid(row=0, column=0, sticky="nw") right.grid(row=0, column=2, sticky="ne") # Class class LeftPanel(Frame): def __init__(self, master): Frame.__init__(self, master) # Create and layout elements inside the panel ...