• 0 Posts
  • 810 Comments
Joined 2 years ago
Cake day: August 7th, 2023
  • normalexit@lemmy.worldtoProgrammer Humor@lemmy.ml•Infallible Code
    1·
    2 minutes ago

    The monkey at the keyboard thinking is what software development is. When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.

    In this case that is using math to check if the input is divisible by two without a remainder. If you don’t know how that works, you’re going to have a bad time, like the picture in this post.

    TDD doesn’t promise to drive the final implementation at the unit level, but it does document how the class under test behaves and how to use it.

  • normalexit@lemmy.worldtoProgrammer Humor@lemmy.ml•Infallible Code
    3·
    5 hours ago

    In a world where this needs to be solved with TDD there are a few approaches.

    If you were pair programming, your pair could always create a new failing test with the current implementation.

    Realistically I would want tests for the interesting cases like zero, positive even, negative even, and the odds.

    Another approach would be property based testing. One could create sequence generators that randomly generate even or odd numbers and tests the function with those known sequences. I don’t typically use this approach, but it would be a good fit here.

    Really in pair programming, your pair would get sick of your crap if you were writing code like this, remind you of all the work you need to get done this week, and you’d end up using modulus and move on quickly.

  • normalexit@lemmy.worldtoProgrammer Humor@lemmy.ml•Infallible Code
    9·
    6 hours ago

    TDD has cycles of red, green, refactor. This has neither been refactored nor tested. You can tell by the duplication and the fact that it can’t pass all test cases.

    If this looks like TDD to you, I’m sorry that is your experience. Good results with TDD are not guaranteed, you still have to be a strong developer and think through the solution.

  • normalexit@lemmy.worldtoNews@lemmy.world•US agriculture secretary says Medicaid recipients can replace deported farm workers
    1·
    5 days ago

    This feels like a flimsy solution to the problem that will fail. I guess that when Medicaid recipients don’t/won’t/can’t sign up, the government will take away their healthcare and use slave labor from prisons to catch up.

    I think in six months they will be saying: "hey we tried this idea with Medicare recipients, but they just wanted to stay home and play video games. Now our crops are in danger of not being harvested.

    What if… We round up some of these bad prisoners and make them work for almost free!? That will kill two stones."

  • normalexit@lemmy.worldtoProgramming@programming.dev•This Overly Long Variable Name Could Have Been a Comment | Jonathan's Blog
    5·
    10 days ago

    Clear concise code that reads like documentation is the ideal. Good function and variable names, formatting, and encapsulation play into this. Tests should document and describe the system.

    If it still isn’t clear what the code is doing, and I’m all out of ideas (or time) for refactoring, a well placed, accurate comment is fine. It needs to be kept up to date like any other artifact in the project.

    It’s harder to keep comments accurate than code, since code can be executed and tested. I use them sparingly; when I’ve otherwise failed to write clean code, or the code is just so complex that it needs to be described.

    Comments are just another tool in the toolbox. If they add clarity to the situation, by all means, use them.

    If you can think of an expressive variable name that lets you skip a comment eg “employeeCount”, instead of “e” // number of employees, do that.