•  Vlyn   ( @Vlyn@lemmy.zip ) 
    link
    fedilink
    English
    910 months ago

    I’ve worked in a company that used linear code most of the time. And at first it felt really easy to read and work with. If you wanted to know what happened, just jump to the entry point, then read over the next 200 lines of code, done. No events, no jumping around between 10 different interfaces, it worked at first.

    But over time it became a total mess. A new feature gets added, now those 200 lines get another if/else at several spots, turns into 250 lines. Then a new option is added that needs to be used for several spots, 300 lines. 400 lines. 500 lines… things just escalate.

    You can’t test that function and bugs sneak in far too easily. If you want to split it up later into new functions it’s going to be a major hassle. There also was no dependency injection or using interfaces, other classes were often directly called or instantiated on the spot. Code reuse was spotty and the reused functions often got 5+ parameters for different behavior.

    It was horror after a while.

    The company I work for now uses interfaces, dependency injection, unit tests, but all the way down a function might still have 50 lines tops or so. It’s slightly tougher to find out where things happen, but then much easier to work with. You need a certain balance either way.