On Mon, May 14, 2018 at 9:38 AM, Python <pyt...@bladeshadow.org> wrote: > Absolutely correct. If you're not doing THOROUGH code reviews, and > not thoroughly testing your code, your job is only half done. You > should be your own first reviewer, and then have a second someone > competent review it after you do.
One should never be their own "first reviewer" because it may lead to the mindset that a "second reviewer" is unnecessary. You're about as likely to notice the glaring bugs in the code that you just wrote as you are to notice the missing or misspelled words in the sentence you just penned. Why? Because you just wrote it, and as a result you believe that you know what it says, and you'll simply fail to process the fact that it actually says something different. That said, when I'm doing a code review, my focus is on all of the following things: * Design: does this code make sense for what it's trying to accomplish? * Functionality: does the code work as intended? * Readability: can I understand it, and will others understand it later? * Complexity: could this code be simpler? * Tests: does the code include good tests? The existence of subtle bugs are just one of the things that I'm thinking about, so from my perspective, the more the compiler can help with this, the better. In C, if I miss a misplaced '=' then the code will do the wrong thing. In Python, I don't even have to worry about it, and I like it that way. So when you say that '=' as an expression should be supported because you think it's useful, and anyway those sorts of bugs will be caught by code reviews, the way that reads to me is: "'=' as an expression should be supported because it's convenient to me, and I don't believe I write bugs, and if I do it doesn't matter because my time is important than that of the person who reviews my code." -- https://mail.python.org/mailman/listinfo/python-list