• 3 Posts
  • 191 Comments
Joined 1 year ago
cake
Cake day: July 7th, 2023

help-circle




  • C was my first language some 18y ago, and I wouldn’t recommend it to anyone starting today. If anything, learning C is a great way to teach why, maybe, we shouldn’t be using it to build customer applications, web servers, and whatnot.

    Keep your gold, I’ll stick to sane error messages, memory management, a packaging system, and a dozen other things that actually make working on multiple projects somewhat doable and not a constant fight against seg faults.









  • get rid of companies making money off the FOSS

    I’m afraid if we discourage companies from adopting open source we’ll end up with even more closed source garbage.

    There are industry sectors where closed source is the norm, and it just leads to more vendor lock-in and less standardization and interop.

    I’m a bit young to say for sure, but I believe closed source was the norm in the software world 20-30 years ago and openness was stigmatized. I certainly don’t want to live in that world.


  • tldr

    1. Keep Commits Small: Ensure commits are small and manageable to facilitate easy reverts and debugging.
    2. Continuous Refactoring: Prioritize frequent, minor refactorings to simplify future changes.
    3. Deploy Continuously: Regularly deploy code to ensure it works in production, as working software is progress.
    4. Trust Frameworks: Avoid over-testing framework capabilities; focus on application-specific logic.
    5. Create Independent Modules: Place functions in new modules if they don’t fit existing ones, preserving code organization.
    6. Write Tests Early: Use tests to design APIs and guide development, but don’t be rigid about TDD.
    7. Avoid Duplication: Prevent repeated code by abstracting similar implementations after copying once.
    8. Embrace Change: Accept and adapt to evolving designs, understanding that change is intrinsic to software development.
    9. Manage Technical Debt: Focus on minimizing immediate blockers and plan for potential future issues.
    10. Prioritize Testability: Ensure that your code and design facilitate easy testing to maintain code quality and coverage.

  • Because you’re assuming foo won’t be renamed when it becomes a function. A function should start with a verb, say get_foo(), because just foo() tells me nothing about what the function does (or what to expect as output). If you make it a property, get_ is implicit.

    So if the age is computed from the year of birth for example, it’s really e.g. thing.age or thing.get_age() - both of which are fine, but I’d pick the property version.