Programming

17705 readers

3 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Terms for intentional anti-extensibility (programming.dev)

submitted 3 days ago by TheV2@programming.dev to c/programming@programming.dev

20 comments fedilink hide all child comments

Sometimes I create a solution to a simple problem. However instead of making use of the solution, I keep extending it unnecessarily. This is why for this kind of project, I want to systematically restrain my future self from adding new features beyond the initial vision e.g. by actively refusing generic and re-usable code.

What is the search engine friendly term for this approach or at least for this situation? "Ad-hoc programming" may be literally what I'm talking about, but in practice it's associated with unplanned happenings.

you are viewing a single comment's thread
view the rest of the comments

[–] tatterdemalion@programming.dev 2 points 3 days ago (1 children)

Organizationally, you don't want your API handler to care about implementation details like database queries. All DB interaction should be abstracted into a separate layer.

Generally API handlers only care about injecting any "global" dependencies (like a database object), extracting the request payload, and dispatching into some lower-level method.

None of this requires generic code. It's just about having a clear separation of concerns, and this can lead to more reusable and testable code.

[–] TheV2@programming.dev 0 points 3 days ago

But I do choose this approach for these problems to not have reusable code on purpose xD I'm not try-harding to rewrite everything for every feature separately, so most of it would be separated and modular, as long as it's required by the initial purpose of the software. However I avoid writing generic and reusable code that only gets rewarded with functional scalability in mind.

And unit testing is honestly not on my list for these kinds of projects. At best I'd write integration tests to challenge the route handlers. But simply using the software is sufficient to cover the predictably unpredictable usage in these cases.