I recently hired into a data analytics team for a hospital, and we don't have a style guide. Lots of frustration from folks working with legacy code...I thought putting together a style guide would help folks working with code they didn't write, starting with requiring a header for SQL scripts first as low hanging fruit.
Or so I thought.
My counterpart over application development says that we shouldnt be documenting any metadata in-line, and he'd rather implement "docfx" if we want to improve code metadata and documentation. I'm terrified of half-implementing yet another application to further muddy the waters--i'm concerned it will become just one-more place to look while troubleshooting something.
Am I going crazy? I thought code headers were an industry standard, and in-line comments are regarded as practically necessary when working with a larger team...
I encourage you to find a name for this function that describes why there is a second inner function. One restriction - the name of the function must be
run(that's what the trait being implemented calls it, you can't rename it).Sure, you can call the inner function
run_inner_to_fix_rustc_issue_probably_caused_by_multiple_fnmut_implsbut is that really any better than using two forward slashes to explain the context?