Coding style

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.

General

• 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 over 0/1

Naming

• 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 of Create-Pointcloud-from-Object.py)
• Classes start with a capital letter and are written in CamelCase (e.g. RenderPreview and NOT render_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

Methods

• 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

---

External libraries

(For example Tkinter)

1. Always specify the argument names of all external functions, e.g. use Label(master=self, text="Label") and NOT Label(self, "Label").
   This helps code readability and makes it easier to understand what exactly external functions do.

Tkinter

Tutorial: https://realpython.com/python-gui-tkinter

1. 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()

2. 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 or btn_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

3. 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
      ...