4 ms·

I use type annotations. They make it a lot easier to do things like refactoring. I've written a ton of Python since the early 2000s, and my experience is that p

I use type annotations. They make it a lot easier to do things like refactoring. I've written a ton of Python since the early 2000s, and my experience is that projects above a certain size (and it's not really that large, like a few thousand loc) start getting hard to modify. There are also a few types of errors that reliably get caught by type checkers that you can easily encounter in Python code... for example, misspelling an exception name, or constructing an exception wrong. Simple typos in code paths that are not exercised in tests. The annotations also help you acclimate faster to code you haven't seen before (you can navigate to definitions / call sites more reliably), and lets Emacs / Vim / VS Code make better autocompletion suggestions. In short, it helps me code faster.

klyrs 5y ago
Do you not test exceptions? It's really easy°, and I strongly encourage testing them. with pytest.raises(ZeroDivisionError): 1/0 ° note, it's not always easy to exercise all exceptions -- just, it's easy to make tests that fail if an exception isn't raised
- klodolph 5y ago
  I do test exceptions, I just don't test 100% of code paths. Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... The problem is that as you approach 100% code coverage, the amount of effort it takes to test the remaining code paths skyrockets. At some point, you decide to stop writing tests. Then static typing steps in, and catches some bugs that were not cost effective to catch with testing. The exceptions are sometimes there because I am programming defensively... as in, "I don't think that it's possible for this condition to happen, but if it does, I'd rather raise an exception." Then I run mypy, and it tells me that there's no such thing as a VauleError. The other factor here is that when I exercise poorly tested code paths (which again, I'm going to assume exist), it's often because I'm in the middle of working on something else. The simple typo or bad call is an interruption.
  - deleted 5y ago
    [deleted]
  - klyrs 5y ago
    > Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... [ed. note, wow you added a lot as I was typing out my response to this] Not as a hard and fast rule, but as a target to aim for. If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient. I do a lot of my work in strongly typed languages; believe me when I say that code without type errors or variable misspellings can still be chockablock with bugs. In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it.
    - klodolph 5y ago
      > ed. note, wow you added a lot as I was typing out my response to this I only spend, like, two minutes editing a comment after I post. You must have had a stale browser window open. > If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient. That's an extremist viewpoint. It's unreasonable. It's a waste of time and money. You have tons of tools at your disposal for finding bugs in your code. You have automated tests, manual tests, unit tests, integration tests, type systems, static analyzers, linters, code review, logging, analytics, and bug reports from production. Use a mixture. As you increase the sensitivity of any one tool, the cost of development increases. For most projects, if you don't see bugs in production, you are not shipping soon enough. The cost of shipping late is, at some point, going to be larger than the cost of shipping bugs to production. > In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it. My experience is that there are only a few explanations for why you would see a code base with 100% test coverage: 1. The code is so critical that high test coverage is justified (e.g. SQLite), 2. The code is so trivial that high test coverage is easy, or 3. The engineers in charge are just fucking nuts. I'd like to share this recent quote from @tef_ebooks: https://twitter.com/tef_ebooks/status/1434706902366228480 https://twitter.com/tef_ebooks/status/1434706902366228480 > trying to work out how to impress on people that i'm an incredibly masculine programmer, and although people have suggested comparing it to hunting animals for food, as far as i can tell the most 10x macho behaviour that programmers do is working unpaid overtime > the best thing about being a macho programmer is that you can do it by saying one thing like "write 100% test coverage" or the opposite "i don't write tests" because nothing shouts status like extreme viewpoints in a land of tradeoffs

klyrs 5y ago

Do you not test exceptions? It's really easy°, and I strongly encourage testing them. with pytest.raises(ZeroDivisionError): 1/0 ° note, it's not always easy to exercise all exceptions -- just, it's easy to make tests that fail if an exception isn't raised

klodolph 5y ago
I do test exceptions, I just don't test 100% of code paths. Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... The problem is that as you approach 100% code coverage, the amount of effort it takes to test the remaining code paths skyrockets. At some point, you decide to stop writing tests. Then static typing steps in, and catches some bugs that were not cost effective to catch with testing. The exceptions are sometimes there because I am programming defensively... as in, "I don't think that it's possible for this condition to happen, but if it does, I'd rather raise an exception." Then I run mypy, and it tells me that there's no such thing as a VauleError. The other factor here is that when I exercise poorly tested code paths (which again, I'm going to assume exist), it's often because I'm in the middle of working on something else. The simple typo or bad call is an interruption.
- deleted 5y ago
  [deleted]
- klyrs 5y ago
  > Do you encourage 100% code coverage? Because I think that 100% code coverage is insane... [ed. note, wow you added a lot as I was typing out my response to this] Not as a hard and fast rule, but as a target to aim for. If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient. I do a lot of my work in strongly typed languages; believe me when I say that code without type errors or variable misspellings can still be chockablock with bugs. In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it.
  - klodolph 5y ago
    > ed. note, wow you added a lot as I was typing out my response to this I only spend, like, two minutes editing a comment after I post. You must have had a stale browser window open. > If you're finding bugs in code that isn't covered by tests, I'd take that as evidence that your coverage isn't sufficient. That's an extremist viewpoint. It's unreasonable. It's a waste of time and money. You have tons of tools at your disposal for finding bugs in your code. You have automated tests, manual tests, unit tests, integration tests, type systems, static analyzers, linters, code review, logging, analytics, and bug reports from production. Use a mixture. As you increase the sensitivity of any one tool, the cost of development increases. For most projects, if you don't see bugs in production, you are not shipping soon enough. The cost of shipping late is, at some point, going to be larger than the cost of shipping bugs to production. > In some codebases, 100% test coverage is equivalent to solving the Halting Problem. Don't sweat it. My experience is that there are only a few explanations for why you would see a code base with 100% test coverage: 1. The code is so critical that high test coverage is justified (e.g. SQLite), 2. The code is so trivial that high test coverage is easy, or 3. The engineers in charge are just fucking nuts. I'd like to share this recent quote from @tef_ebooks: https://twitter.com/tef_ebooks/status/1434706902366228480 https://twitter.com/tef_ebooks/status/1434706902366228480 > trying to work out how to impress on people that i'm an incredibly masculine programmer, and although people have suggested comparing it to hunting animals for food, as far as i can tell the most 10x macho behaviour that programmers do is working unpaid overtime > the best thing about being a macho programmer is that you can do it by saying one thing like "write 100% test coverage" or the opposite "i don't write tests" because nothing shouts status like extreme viewpoints in a land of tradeoffs