this post was submitted on 28 Dec 2024
11 points (67.7% liked)

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

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
11
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
[–] 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.