Hard coding vs Generic coding : Where to draw the line?

Question

I'm not exactly sure how to word this but I'll try.

Suppose you have some settings in some piece of your program where your 80% sure you won't ever have to modify again. How do you know where to draw the line on changeable code? You know that taking the settings all the way to a user defined XML file is overkill. However, you also know that there is a slight 20% chance that these settings may need to be changed later on so coding it at the place where the rubber meets the road isn't optimal either.

I guess what I'm trying to ask is, how far up the abstraction tree should you allow your program to be easily changeable?

One of many examples is writing the HTML code for a website manually vs having the program automatically generating it. Writing the HTML code directly doesn't take too much time. Writing the a program to automatically generate the HTML code takes much longer.

Answer 1

This is a good question but there is no absolute answer for it:

As noted by Einstein:

Make things as simple as possible but not simpler.

Simplicity is relative. Making the best decision about the amount of abstraction layers in a design is what makes a great architect great. A good architect should always evaluate the particular situation and make the best trade-off. There aren't any silver bullets.

Answer 2

80% ? Not nearly good enough to hard code, put it into the config file.

100% ? A constant may do.

Answer 3

Two points:

• All constants should be generic, ie, don't ever hard-code magic numbers without putting it into a descriptive constant.
• Implement the minimum you actually need - hard-code it until you are about to duplicate hard-coded code more than once - in that case, you should start making the code generic. (Test Driven Development is amazing here).

Answer 4

Your question was geared towards actual code design than whether to put variables in the configuration file or in constants. I agree with the other answers regarding those respects.

But regarding whether to write generalised code...

In my experience if you write code specifically to deal with the task at hand, you will only find yourself writing similar code at some point in the future. Ok if you really will only do the task once, it's alright. But I find that most times this isn't the case.

Should you find yourself repeating a task at all then you should take a step back and consider what it would take to automate it in a general way.

Also check that someone hasn't done it already. If they haven't, do consider publishing your code, no matter how small or rough it might be. Someone might improve on it for you, for free.

Answer 5

In the last four years, this old dog has learned the new trick of TDD. Even when I don't have time to do "real" TDD, I pretend that I do.

So I always write duplicate code. Which is ok, because I always refactor it afterwards. This is part of the process of writing the code, not something to get around to later. Since I've followed TDD and only written the minimal code necessary, and since I've got automated tests proving that the code works, if I find duplication, I can refactor it away in comfort, knowing that I'll run my tests again during and after refactoring. This will prove again that I haven't broken anything.

This way, I don't speculate about whether the code will be reused - I never refactor until it is reused. Since it is created in each instance according to the needs of the instance, I know that the caller of the code hasn't been warped by the desire to make the code generic. The callers, including the unit tests, were written to meet their immediate needs. The separate refactoring pass handles the broader need to not duplicate code.

Answer 6

I'll give this a shot, my philosophy is as follows:

1 - Keep a config file & parser class/function that are extremely dumbed down and simple as possible to give you the peace of mind that whenever you need something from it, you can get it without having to instantiate a ridiculously overbloated XML crunching configuration file parser. My config file looks like this:

DBHostname -> XX.XX.XXX.XX
DBUsername -> foomonger
DBName -> fooDb
DBPassword -> xxxxx
ImageUploadsDir -> /uploads/images/
...

I extract what I need from it using either a static helper method (small apps) or a singleton instance (large MVC driven apps) generated by my idiot friend ConfigHelper, who is so dumb, he doesn't know how to generate overhead.

I have this dilemma several times in my average working day: should I put this in config.txt or should I make it a class constant? My answer is I just don't know - until much later on. If it turns out that it needed to be put into the config file, nothing beats a decent IDE with a stable 'Find & Replace In Projects' implementation for changing references.

3 - Config files take the nightmare out of application deployment when development involves a testing server followed by deployment to production - there is no real practical alternative. Different database instances on different machines have different IPs in the world I understand.

One of many examples is writing the HTML code for a website manually vs having the program automatically generating it

This is so true. While we as developers enjoy building machines, we tend to waste a lot of time building machines to build the machine we initially intended to build. While this can be extremely gratifying, from experience I can venture to say that in most situations the more machines you have, the more systems you have to support, the more points of failure, the more hand smacks you get from the business owners - and that is not fun. Furthermore, you will tend to run into situations where the intermediate HTML generator thingie cannot produce the desired output. So what do you do, waste time fixing the bug in the generator thingie, waste time devising a voodoo workaround, or simply hand-write the HTML? It really depends on the particular circumstance, but I prefer the latter.

Was a bit of a rant, but hope it helped answer your question, at least a little.