Skip to content

Guidelines for making internal functions #16

@lwjohnst86

Description

@lwjohnst86

We sort of have some guidelines, but I think we need them to be more specific and then to make it easy to refer back to them.

Some guidelines might be:

  • Always name internal functions with _ (I don't love this, but it is how Python formally "hides" functions from being exposed).
  • Use the name of the function to describe what it does.
  • Combined with the point above, if the function is small enough and specific enough, we only need to write a one-liner docstring (or none). Unless the function is complicated enough or big enough that it should have a more described docstring.
  • Try to keep internal functions small.
  • Prioritize testing the bigger, public function rather than smaller specific functions, and just test those bigger public functions more extensively. Unless the specific small function does some complicated stuff or non-standard stuff that you as the developer aren't sure about. So there is some judgement to this guideline.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions