On Mon, May 14, 2018 at 12:02:47PM -0600, Ian Kelly wrote: > 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.
I went on to say that the second reviewer was required (i.e. this should be considered a required part of good process). If you decide this is your process and it's required then it's required, regardless of what you personally think. > 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. I'm well acquainted with that pheonomenon, though I daresay that if you proofread your own product you will often find your mistakes. You just won't always. But, I never said review it right after you wrote it, and in fact I don't do that (well, I do reread it if it seems something potentially concerning). Rather I review it when I'm about to check it in, which for anything non-trivial is generally days later, after it's been tested (which implies the tests were written). I find my own bugs very often (but not nearly as often as I'd like). I am hardly perfect. What I am is thorough. I would argue that is required to write quality software. If your goal is not to write quality software, then none of this matters. And if it is your goal, you shouldn't need to care about this, because you'll either get it right through whatever process you have, or you'll avoid it entirely if you don't think your process is adequate. Your choice. Or not, if the language decides you can't be responsible enough to make that choice for yourself. > 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? These all seem fine, but if you're missing extremely well-known pitfalls, then... I'll prefer a different code reviewer. :) Maybe you should consider adding that to your list. > 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. I don't disagree with that, except that I don't consider this a subtle bug, largely on account of its aforementioned status as well-known pitfall. But niether do I consider it damning, obviously. > In C, if I miss a misplaced '=' then the code will do the wrong > thing. Better yet, the compiler should warn you about it (which I believe it does). And you should be compiling with warnings. > In Python, I don't even have to worry about it, and I like it that > way. If you're so concerned about making that mistake, YOU CAN CHOOSE TO NOT USE THAT CONSTRUCT. It doesn't need to be a decision forced on you by the compiler. As we've learned in this thread, there is a PEP for implementing this feature which Guido apparently approves, so it can't be all that evil after all, can it? > 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: Actually if you read all of what I wrote, you'll know that what I said was assignment as an expression should be allowed, and if there were to be a different operator to express that to avoid confusion, that would be just fine with me. But I don't think that need be a condition. > "'=' as an expression should be supported because it's convenient to > me, and I don't believe I write bugs Convenience is sort of Python's gig, isn't it? "Make simple things easy, make hard things possible." > and if I do it doesn't matter because my time is important than that > of the person who reviews my code." Circumstantially, that may actually be true... or it may not. Depends on who you're working with, their roles and seniority, relative skill and compensation, and probably other factors. Most groups have such a heirarchy, even if it is largely implied rather than stated. HOWEVER it hardly matters if the construct in question is accepted practice. -- https://mail.python.org/mailman/listinfo/python-list
