To me, one of the most frustrating aspects of programming comes in something as seemingly trivial as how to best name and organize files. And by that, I mean the process of figuring out what to name directories and files all the way down to how to best name classes, variables, and functions.

If it doesn’t sound trivial, then maybe it just sounds silly especially to those who are more experienced programmers.

Interestingly enough, this is a bit more of a challenge for some, but not so much for others. After all, isn’t this is where standards come in to play? That is to say, isn’t this where they help us make decisions on how to avoid problems just like this?

Sure, in some ways, but there are times in which standards may not cover all cases or certain aspects of what we’re trying to do.

So what then?

The Dilemma Of Pragmatic Programming

To be honest, naming things is hard (and I know I’m not the only one who feels this way) but I’d like to think that, over time, I’ve gotten better at organizing my code, recognizing when certain patterns – be it naming patterns, or design patterns – fit what I’m trying to do, as well as learning certain standards such that I know how to best organize, document, set things up the proper way for the environment in which I’m working.

Then again, having someone else audit code and provide feedback can determine whether or not this is actually true.

The thing is, though I know that this is something that plagues developers, it’s something that doesn’t affect some as much as it does other. For example, there are some people who I know end up halting development because it’s hard to determine the optimal way to name directories, where to place files, and how to reference them throughout the code.

Speaking honestly, I used to be really bad about this. I’m not claiming I’m cured, but I’m better than I used to be. I’m somewhere on the road to recovery :).

On the other hand, there are other people who recognize that this is important, but are also incredibly pragmatic – if that’s even the right word – in that they recognize that it’s also important to solve the problem and ship the code.

Attention to Tension

But there’s a little bit of tension here:

  • Those who agonize over naming things can end up spending time on the project figuring out what to name and where to place things.
  • Those who write code and ship a solution end up likely having to do a bit more refactoring later.

This isn’t a new problem, is it?

I mean, on one hand, you’ve got developers spending time on the front end of the project determining how to best organize the code. On the other side, you’ve got developers who are likely spending time on the back end of the project refactoring code in a way that may have been avoided if there was a bit more discovery of the problem domain when the project started.

Any programmer who has done any outside reading be it in books, articles, blogs, or something similar on improving code knows that this problem has been presented in one of the ways mentioned above.

Yet here I am still talking about it.

Anyway, I don’t know if it’s meant to be presented as a black and white issue, but at this point in my career, it appears as if there’s a lot more gray area than some of the material would have us believe.

Not “Either/Or,” but “A Little of Both”

By that, I mean that each of the aforementioned cases can both negatively and positively impact – that is, they have their disadvantages and advantages – of delivering a solution.

Even more so, I don’t know if it’s really a fair comparison because a number of external factors so easily dictate how a project is managed from inception to delivery that there are going to be various stop gaps along the way.

So what are practical things that we can do to actually strike a balance between the two?

I wish I knew.

Not only do I think a number of outside factors contribute to how a project is built, but I think personality goes into it, as well. For every developer I’ve heard trouble themselves (myself included) with something as seemingly trivial as naming a set of classes, I’ve also heard developers say that “it doesn’t really matter so long as the problem is solved.”

But again, we’re back to the binary mode of thinking.

What’s a Developer to Do?

Experience can help mitigate this issue such that naming things become easier, and organizing code becomes easier, but that’s a point at which only time (read: experience) will allow us to reach.

What’s the ultimate conclusion to this dilemma of sorts? I wish I knew.

In some ways, I lean in the direction of spending time on the front end of the project proposing a solution for how to best organize the code so that it solves the problem in an elegant way. On the other hand, I recognize the importance and getting a problem solved, and working to make short, quick iterations to improve the project over time.

If my back was against the wall and I had to make a decision, I’d have to say that it depends on the nature of the project, the team ,the customers, the problem domain, and how much time is alotted for the work.

Not a great answer is it?

That’s okay, though, because the real world is more complex than black or white solutions for how to write code. We can’t prescribe a general solution to specific problems – only best practices to common problems.

So rather than worry so much about if something is named properly, or if something is written quickly, we should work to learn and to identify the best practices and standards for a given type of project and a given type of problem and aim to balance form and function rather than trying to perfect it or ignore it.