6

How "commented" is your org's codebase?

I joined this company a few months ago, and I've yet to see a single comment explaining how/why some code (doesn't) work.

It's a great company for the most part, this just seems to be the standard practice here and I'm wondering how many more like it are out there.

Comments
  • 6
    Here it's mostly ancient Africa : oral tradition. If the two devs (including me) leaves, it would take months for someone new to get used to the codebase. The CTO could help for the big picture but he stopped working on code some time ago
  • 1
    mostly my comments, and I write any only for the parts that r a bit or more complicated and on mixed files to separate sections
  • 8
    At our place, we use our tests as documentation and treat them as our source of truth for all the legacy's weirdness.
    A great benefit of this is: your tests scream at you if your code changes make them out of date.
    So if all your tests pass, and their good tests, your docs are always (in theory) up to date. 🪄

    We put our comments in the tests if there's any legacy weirdness we can't explain with code
  • 5
    Depends on the language. C++? Hella commented. TypeScript? Ehhhhhh.

    We only use comments to describe something that has a use which isn't obvious from the code.

    Doesn't help a guy like me that wants explanation for why we needed each tailwind class to make it work because I suck at css, but overall the code is very readable.
  • 1
    @ostream I can throw you some projects, and I'm sure even you will cry for comments, but there are none... and it's a total mess. I had to constantly grep everithing to find where I need to fix it again... mind there is no dev server or git on one of them, and everybody just work on live praying their changes will not put the whole site down...
  • 2
    @ostream I no longer work there. almost lost my sanity, but had recovered already =]
  • 1
    file...comments not found.
  • 2
    @ostream
    > comments are for noobz

    At my job, my boss was dealing with a bug in another API (which we had no control over). He left comments explaining this bug, as well as his workaround.

    There's not really a way to avoid this, and the code would be worse without comments
  • 2
    @ostream should we start labeling people that are for and against comments?

    1 - commentists - for comments

    2 - chadists - against comments

    ;-)
Add Comment