• 0 Posts
  • 820 Comments
Joined 2 years ago
cake
Cake day: August 7th, 2023

help-circle


  • 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."





  • 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.