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…

  • JackbyDev
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    edit-2
    1 年前

    Its wild to me that some people hear “your code should be self documenting” and take that to mean “never write comments”.

    It’s the same people that hear “security by obscurity is not security” and take it to mean “publicity is more secure than obscurity”. A key being under a door mat is bad but putting it on top of the mat because “obscurity isn’t security” is silly.

    Edit: A better example is having a hidden door with a look is still more secure than having a non-hidden door with a lock.