Menu

#113 changes to improve manual and code comment clarity

Unstable (example)
open
nobody
None
5
2023-03-15
2023-03-15
Kxie
No

I've been spending some time writing a binding to sharedspice using the manual and sharespice.h file for reference, and there were a few places where I felt the wording/description was confusing.

  1. Under Manual section Status, it should specify the preferred method to report mistakes or make suggestions after inving the reader to do so.
  2. comments explaining structures exposed by the API were often unclear. Unless it has a specific technical meaning that I'm not aware of, the use of the word 'actual' is redundant and should be considered "bad English style".
typedef struct vecvaluesall {
    int veccount;      /* number of vectors in plot */
    int vecindex;      /* index of actual set of vectors. i.e. the number of accepted data points */
    pvecvalues *vecsa; /* values of actual set of vectors, indexed from 0 to veccount - 1 */
} vecvaluesall, *pvecvaluesall;

For example, "index of actual set of vectors" can just be "index of set of vectors" without loss of meaning. Although, in this case, it's not clear to me anyway what the index of a set of vectors mean, or how it differs from veccount. It's meaningless to know "number of accepted data points" without knowing what the criteria for acceptance is.

I suggest changing the description for vecsa to: "pointer to an array of vecvalues pointers, indexed from 0 to veccount - 1". This way understanding is possible even if the reader misses that pvecvalues is a pointer.

In my binding I am able to get all of these structs back, so I have some understanding of what they are. But there are still many values which I'm not sure. If you think the suggestions I'm making is worthwhile, I think a good way to move forward would be for me to work on a merge request while working on understanding what all of the data represent.

Discussion


Log in to post a comment.