4 ms·

I treat it the same was as a code review. Makes it easy to generate a bunch of boilerplate code, but still want to verify it. (Just as I would if it was someth

by davely 3y ago

I treat it the same was as a code review. Makes it easy to generate a bunch of boilerplate code, but still want to verify it. (Just as I would if it was something I found on Stack Overflow.)

snotrockets 3y ago
Code reviews aren't meant to prove correctness. When I review code, I assume the author thought about it, realized this is the best solution, and tested it, all not happening with the models.
- davely 3y ago
  Honest question -- what are you doing otherwise then? Just checking for typos in variable names?
  - snotrockets 3y ago
    That's what linters are for. Each of us has a limited capacity to take critique from other humans, before we become irritated by it and just ignore it. Therefore, I've learned to leave things that can be caught by automated tools to automated tools. When I look at a PR, there are two things I try to validate: 1. Do I understand what the code is supposed to do, and why the author chose to do those things that way. If not, then either the code need rewriting (because it does things in a way that shouldn't be done,) or more commenting (because it ain't obvious), or both. 2. Catch anything that is obvious to me, but not the author, or to the linter. Maybe there's a different function that does a thing the author didn't know about? And while doing that, it's important to keep context in mind. You could write the kind of code that would be very smart, but can't be understood by most, and that's code is just as bad as a very dumb code (see (1)). If I have to catch obvious errors, than the author didn't do their job. If I have to catch spelling mistakes or formatting issues, than the linter didn't do their job. My job is to catch anything that neither the author nor the tools can.
    - davely 3y ago
      Ah, these are good things for me to keep in mind. Thanks for responding!

4 ms·

I treat it the same was as a code review. Makes it easy to generate a bunch of boilerplate code, but still want to verify it. (Just as I would if it was someth

by davely 3y ago

I treat it the same was as a code review. Makes it easy to generate a bunch of boilerplate code, but still want to verify it. (Just as I would if it was something I found on Stack Overflow.)

snotrockets 3y ago
Code reviews aren't meant to prove correctness. When I review code, I assume the author thought about it, realized this is the best solution, and tested it, all not happening with the models.
- davely 3y ago
  Honest question -- what are you doing otherwise then? Just checking for typos in variable names?
  - snotrockets 3y ago
    That's what linters are for. Each of us has a limited capacity to take critique from other humans, before we become irritated by it and just ignore it. Therefore, I've learned to leave things that can be caught by automated tools to automated tools. When I look at a PR, there are two things I try to validate: 1. Do I understand what the code is supposed to do, and why the author chose to do those things that way. If not, then either the code need rewriting (because it does things in a way that shouldn't be done,) or more commenting (because it ain't obvious), or both. 2. Catch anything that is obvious to me, but not the author, or to the linter. Maybe there's a different function that does a thing the author didn't know about? And while doing that, it's important to keep context in mind. You could write the kind of code that would be very smart, but can't be understood by most, and that's code is just as bad as a very dumb code (see (1)). If I have to catch obvious errors, than the author didn't do their job. If I have to catch spelling mistakes or formatting issues, than the linter didn't do their job. My job is to catch anything that neither the author nor the tools can.
    - davely 3y ago
      Ah, these are good things for me to keep in mind. Thanks for responding!