Satisfy ruff's rules by adding a lot of docstrings.#76
Conversation
AadilLatif
left a comment
There was a problem hiding this comment.
@josephmckinsey there is inconsistance between docstrings aand even in function signatures. Some functions are explicit in defining input type expect. Other sare not. Some docstrings have parameter (input / output ) definations other do not. we should be consistant, which ever way we go.
| comp_type : str, optional | ||
| Component type identifier (not used in mock implementation). | ||
| """ | ||
|
|
There was a problem hiding this comment.
Where did this paratmeter list come from? Does not match function / class signature
| links: list[Link] | ||
|
|
||
| def clean_model(self, target_directory="."): | ||
| """Remove component directories, log files, and stray broker processes.""" |
There was a problem hiding this comment.
Alot of these docstrings do not have paraterer defination, errors raised etc. is that expected implmentation?
There was a problem hiding this comment.
I've tried to change it so that most functions have longer descriptions with some exceptions on private functions and the CLI documentation. Some of the less commonly used utilities also have short docstrings still.
| @@ -53,6 +54,7 @@ def plot_graph_matplotlib(wiring_diagram: WiringDiagram): | |||
|
|
|||
|
|
|||
| def get_graph_renderer(G): # noqa: N803 | |||
There was a problem hiding this comment.
What is G? add typecast
There was a problem hiding this comment.
I did not add a typehint since that would require importing networkx, which would break installations without that dependency.
Some of these docstrings have been autogenerated but reviewed my me. Claude seemed to be around 95% accurate, and only 5 or so docstrings needed much attention. I've erred on the side of brevity in all cases.