> One of the things I struggled with when I started out as a programmer was where to put my code. It was not something I could easily find in tutorials and for a long time I wondered why everyone was so focused on how to get framework X to do Y, when all I wanted to know was where to put the code that does Y.
So true. Small things like this are why I'm so glad I had a software engineering job at a real company for a few years, even though I don't necessarily want to do that for life. I learned a lot from looking at codebase conventions and quick questions to the elders. Unfortunately, no one can help you with the other hard problem: naming.
That is one reason to choose a framework instead of building from scratch, so you don't have to make decisions like "Where do I put Y". The most import value a framework provides isn't in the way it functions, but that it is a collection of idioms, decisions and conventions that everyone has to use.
It also means I don't have to worry about where Dev X put thing Y, because I know where to look for it already.
That's what software patterns are good for as well, a shared set of idioms so you don't have to invent new approaches. I think that's important in a professional environment but less so in a personal one. For personal projects I just do whatever is fun.
But the whole problem is frameworks always decide against code colocation, and also they don't tell you what to do with all the functions that don't fit their directory scheme. People who don't use a framework will naturally tend toward fewer subdirectories and code colocation just because, e.g., there's no reason to elevate the importance of a models/views/controllers pattern.
> Unfortunately, no one can help you with the other hard problem: naming.
I have a guiding principle here: If, a few minutes after naming something, you want to use the thing and (without looking it up) your first attempt at writing the name is correct, it's a decent name.
If you name a function processFoos and then later in your code your first intuition for what it was called is createBars, then there is some disconnect (and possibly some missing conceptual clarity) in what this function is supposed to accomplish. Is it more about accepting foos or is it more about creating bars? I find it very productive to, in such a case, dive a bit deeper into these differences (which may often also reveal something about different perspectives between caller and callee).
So TL;DR: If you don't have to look up the name of what you wrote minutes ago, it's probably a good name.
So true. Small things like this are why I'm so glad I had a software engineering job at a real company for a few years, even though I don't necessarily want to do that for life. I learned a lot from looking at codebase conventions and quick questions to the elders. Unfortunately, no one can help you with the other hard problem: naming.