Everyone hates php and cobol, and use their scripts dozens of times each day.
I hate php but have to write in it ( help me). I still won’t touch cobol.
Everyone hates php and cobol, and use their scripts dozens of times each day.
I hate php but have to write in it ( help me). I still won’t touch cobol.
How about just fires to use smoke signals?
It worked for my grandfathers, and it seems comforting
Most people do not know how to manage thousands of files of code in a project until they do exactly that. It comes with experience.
Many people learn by example, working on existing projects and seeing how it’s done.
Others can learn the hard way by making their own projects, and refactoring as the complexity grows.
It can be helpful to use a framework for your language of choice, that has a way of organizing files and code.
courses and books really don’t help much, except maybe to learn some ideas that some people use.
Once code is organized, there are as many ways to do it as there are people. But all of them seem to fall into broad patterns with none being wrong, except for those that slow down the code in real time systems.
The main secret behind any code organization is that it should not drive other people crazy, and they can learn to work on it too .
People will say that a project should be organized and follow rules. But I have never seen a big project that is more than organized chaos. With a few sketchy rules keeping the entire thing connected with bubble gum and duct tape.
I think a medium sized project with a few hundred files and a few tens of thousands of lines of code can be organized well. After that it gets more chaotic
Yes, the more information and standards in an api response the better. There should be front end messages and developer messages. URL links to documentation are great too. Standards assist automation and testing.
I understand other viewpoints about maintenance and redundancy, this can cause errors. And the above is too much work for some projects .
But most api start as a temporary or one person project. It’s tempting to be terse and cool with responses . Even more tempting is this is a great cost cutter to not have overly detailed responses.
However
It’s much easier to add in more data to responses now than later. And a future you years later, or strangers who use it , will be grateful. It may be the thing that allows an api to be popular, rather than people use it despite the api