Naming your code

This morning I posted how I had come to the conclusion that findability might play a role in design. Since Uli questionned my argument, I’ll try to elaborate a bit on the thought.

In the case at hand I had been thinking for some time where to put that code. The code was responsible for calculating/scheduling when the next task would take place. This calculation can be done from some global property, some local property that comes with the task to be scheduled and the current time.

I thought I had several options on where to include that piece of code. My first solution put it right in the same method that executed the database update that followed the calculation. Not good. So I moved the code to where the local property was derived from some data gathered by the last execution of the task. No good either. It always felt wrong.

Those three lines of code didn’t quite belong anywhere. Testing didn’t work either because I need to test all those methods without interfering with each other.

Every time I decided to move the code somewhere else, I was having trouble remembering where I put it an hour before.

I have never considered using the “search in project” method. The only search methods I ever use from my IDE are: “find references” and “find in file”. My guess is that I don’t think about the “search in project” because 1) the project is very small (<100 classes and half of that test classes) and 2) such a search would seem like the design/organization wasn't intuitive (for a project of that size a valid argument IMHO) and 3) not intuitive = not good.

Now my final solution is to have a very small class called "Scheduler" because that is the exact task and it is quickly found because I know exactly to which package such a class just must belong, it feels intuitive.

I think my current thought on the issue has come to: an intuitive design isn't necessarily good, but a counter-intuitive design may very well have some issues that will sooner or later need fixing. Naming and organization are pretty big problems sometimes. For those of you working in big projects where you always have to fight others and the naming conventions that might sound a bit bizarre: but I have too many choices and nobody to question them.

Oh well and I still think it is impossible to have a good design without someone continously, seriously counter-checking. I am not that kind of genius. So I am deciding this and deciding that and some decisions feel good and some decisions leave me feeling insecure wether that really was a good idea. Which brings me to my next issue: keeping track of decisions made during development and the reasons for them, but that will be another post.

By Yashima

Writer of code and stories


  1. Concerning the last paragraph, I think that there’s another dimension in design decisions. Before starting to think about which decision is the “right” one, one has to decide if it’ll actually make a difference in the end.

  2. @Daniel: isn’t that a Corollary of: “Optimize, don’t do it!”

    My point is that I tend to not document “key” decisions well enough: which has me come back to old issues that were already solved and I need to solve them again. Two days/weeks/months later I must still be able to answer this: “Uhm why did we do that again? Wouldn’t it be better ….” I am improving my process in that respect. Another positive outcome of documenting/communicating “key decisions”: I can always tell my boss: “Told you so back then, you could have ….” which means less responsibility for me.

    The hard part for me is to distinguish between the small stuff, the don’t care stuff and the “key decisions” that I definitely need to notify someone (=my boss) about. I guess in bigger projects those are decisions fought over in meetings, well I have no meetings, so I must fight with myself to weed out the evil ones. That’s why going is so slow sometimes. I am meeting with myself in my head to discuss the project 😉

Comments are closed.