As the project maintainer of Cardboard.NET it's important to me that both contributors to the library itself and library consumers can understand the project. I need to fix the api doc generation but I digress. God being a maintainer sucks ass sometimes because I am responsible for the "architecture"/"design" of the project. I have the final say and it's sort of my baby. Just because I have the authority doesn't mean I know all the answers ahead of time...
I hate doing busywork but everyone else hates doing it and when I can just flex with more contributions to a project because I actually did the boring stuff I feel like I’m really helping the project. See, it’s one thing to implement hard features. Those are exciting, problems that don’t have easy solutions. Unit tests and documentation are just as important especially to ensure that solution stays consistent. It also makes sure other people can understand the implementation by describing why it’s done that way. It is a core part of any project and most people just neglect it. Fuck it. Documentation hell because I am a responsible programmer
Also one of the things I use to "convince" myself to do either of these strenuous tasks... Writing documentation (inline) along with unit tests gives you an astronomical amount of additions which artificially boosts your contributor status. problem is, this doesn't matter for me because i already have 20,000+ lines committed to this repository lol
In programming, there are a lot of things that I consider repetitive/tedious. One of these things includes making unit tests, I find it to be exhausting. Another one of these things is commenting my code. Not just // or my long form comments but XML-doc comments like so: /// <summary>
/// Sends a post request given an endpoint, a body, and optional headers
/// </summary>
/// <param name="endpoint">A string containing the api endpoint to invoke this request on</param>
/// <param name="body">The request body</param>
/// <param name="headers">An optional List of KeyValuePairs</param>
/// <returns>an instance of RestResponse containing the result of the POST request</returns>
internal async Task<RestResponse> WrappedRequestAsync(string endpoint, string body = "{}", List<KeyValuePair<string, string>>? headers = null) "The thing" refers to the fact that in particular, cardboard.NET's MisskeyRestApiClient class (which basically encapsulates a RestSharp client instance and has all of the functions actually sending requests to the misskey RESTful API) is being refactored. I have replaced some of the underlying functions that the rest of the functions rely on (namely, renamed SendWrappedRequestAsync to WrappedRequestAsync and introduced WrappedRequestAuthAsync along with the nonwrapped variants). I have >60 errors because all of these functions are calling functions that do not exist.
What I have been doing to fix this is taking the time to write out the XML-doc comments describing what the function does, and adding remarks for the required scope just on the off chance we ever get an endpoint to see the current scopes of the token. Why is this important? Because it would save me a lot of time later, I won't have to look up the api doc to see the required scope. I'm doing more work now so I have less work later. Problem is I am bored out of my fucking mind doing this repetitive task. Do I do the thing and just skip over all the xml-doc to work on things I actually care about or do I continue to build my discipline and do things that need to be done but aren't fun