Christoph Buchner

Doctests in both pymeasure code and runnable examples in the documentation would be useful, see [here](https://github.com/ralph-group/pymeasure/issues/98#issuecomment-317273099).

I found this a good, short, read about what constitutes good documentation: https://www.divio.com/en/blog/documentation/

Some doctests executing code in the documentation has been added in #111, so this can be used as a guide for adding documentation doctests elsewhere. I have also looked a...

document that * [x] Ideal order of objects in a class implementation: `__init__`, then class variables, then properties, then methods * [x] common pattern: bool properties with map_values * [x]...

* [x] Maybe we should put some recommendation how to deal with atypical communication needs of some instruments (and pointer to examples) in the docs? One [c|sh]ould encapsulate the device-specific...

Yeah, if we re-organize the docs according to the scheme linked above ( tutorials, how-to guides, explanation, reference), this should naturally fall out of that.

also see #364. Instrument naming patterns: One pattern you can use for the adapting the names, while retaining full flexibility, is: ``` class BaseClass: def __init__(self, adapter, name=None, **kwargs): #......

* [x] Extend https://pymeasure.readthedocs.io/en/latest/dev/adding_instruments.html#writing-properties to explain more about the different options to use, and how to use them (e.g. `check_set|get_errors`) to avoid what kind of problems.

* [x] Good naming scheme for boolean property - able to formulate as a question (` output_enabled`) * [x] "Actions"/commands/verbs should typically be methods, not properties (`recall()`, `trigger_scan()`)

> What are people's thoughts on the usefulness/necessity of adding support for additional file formats in the Results and Worker classes and specifically for live image plotting, adding FITS support?...