1. 42

  2. 12
    1. 5

      You might enjoy this later post which is more explicitly about the problems of DRY and abstractions


      1. 2

        Indeed, I’d forgotten about that one.

    2. 6

      I feel like everyone should read Chuck Moore’s Programming a Problem Oriented Language (1970)(Also available on Amazon), if not for the walkthrough in building a beautifully designed program then be it for snippets of wisdom like this:

      The Basic Principle has a corollary:

      • Do Not Speculate!

      Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each one has 0 probability of realization. If you need an extension later, you can code it later - and probably do a better job than if you did it now. And if someone else adds the extension, will they notice the hooks you left? Will you document that aspect of your program?

      1. 1

        Yep, that’s the YAGNI (You Ain’t Gonna Need It) principle at work, which I talk about every time I teach a class. Good to know an early source for the principle!

      Stories with similar links:

      1. Write code that is easy to delete, not easy to extend. via pushcx 4 years ago | 20 points | 7 comments