Mine is this:
Hard coding is the way! All my problems go away. Just code it one by one. And problems come back kill your day.
I absolutely hated it but the fact is "business people" tend to like it because it takes less time to get what they wanted. And as a software developer especially working in a corporate environment, most people will say: "yeah, why bother, just hard code it". What is your attitude toward hard coding?
I generally try and put values into a configuration file rather than hard-code. If a value must be hard-coded, I create a constant with the hard-coded value and everywhere in the code references the same constant. If the value needs to change it can be done in one place.
For application-wide constants, I normally create a class and create constants in that.
Hardcoding is something that should be avoided as much as possible.
If you hardcode something on your code it will completely "destroy" the portability of your code in a great extent. Even with a platform independant languages you will not able to say "Compile once, Run anywhere". Since it is not a good software engineering practice, I think avoiding hardcodes is better.
But I know in some cases we need that, specially in debugging the codes. The way I suggest is: First develop the code with hard codes, make it stable and eliminate the hardcodes then...
And there might be some cases that we need hardcoding, due to security concerns etc :). you might not be allowed to use registry, configuration files, any thing because they can increase the attack surface. But I think it is a rare case.
Hard coding is the way to go!
But as Anthony mentioned, I put the configurable values in their own class. This way they are configurable at compile time, but without the added complexities that come with having an external xml/txt file for configuration.
I only use xml/txt files for configuration where absolutely necessary. Otherwise you're just over-engineering which can be just as bad, if not worse than hard coding. Not to mention there's a lot of stuff people put in configuration files which you don't want the client to change at all.
If you need different configurations for different clients, no problem, put the hard coded values in their own assembly/dll and deploy different configuration assemblies per client.
As Ayende says, hard coding everything is the key to enabling change.
As someone who's had some experience with hard-coding in my early days (don't tell anybody mate), I can confidently tell you that it will come back to haunt you. There's this application that I made (which I don't talk about now) which had to be completely re-written cause it had a lot of hard-coded content. That was back in 1998 mate.
Don't do it unless you don't want to support that client in the future. The time you save now, will be time spent in fixing later.
There're a several factors involved that is hardly to make an assertion that will cover all cases.
If it is a long project with several cycles then if you start hard coding it is likely that they will rather soon than later will popup again. So in these cases is better to fix with a proper solution.
But if you have a project with a short cycle, or with predefined schedule and you have to ship the product anyway, most clients will be satisfied if the product work, they will not care about the internals. But in these cases I prefer to hard code a solution, but let the path open so in the future it will be easy to make a proper solution.
Hard coding is bad anyway, but I you document properly it can make the life of the next person much easier, and will probably not curse you, at least not much ;) .
But from my experience I started avoiding to hard code from the go, and only using them when I've no other option, and always documenting those cases so later I can fix it properly when I've time.
You need a good healthy balance between hard & soft. :snicker:
Soft thread from the other day : http://stackoverflow.com/questions/823610/what-is-soft-coding-anti-pattern
Nothing wrong with hardcoding provided its done right for the right reasons!
"Doing it right" means concentrating all your hard coding in one or two modules.
For C define all the values in a codes.h for Java have a codes.java class which is just full of public constants.
There are several "right reasons" for hard coding.
There are also several reasons to avoid over complex configuration files. If you have enough parameters and options you just end up programing in a not very good language.
it takes less time to get what they wanted.
That's almost like saying, "I like to write my code without comments because it takes less time to get what I wanted."
Of course, that's not to say that hard coding is always a Very Bad Thing. (I mean, it'd be kind of stupid to store, say, a mathematical constant such as π, e, or Planck's constant in a config file. Also, hard coding a lookup table for, say, sine/cosine values would probably be a lot more efficient than loading it from a file.) But hard coding data purely for the sake of convenience is not a smart idea. It's inflexible and makes modifying data later on much more troublesome than it has to be.
Also, hard coding can make localization extremely difficult, if not impossible in many situations. If it's an internal app for some company, then I guess it doesn't really matter to some extent, but that doesn't make it a good software development practice in general.
Conceptually I don't like too much hard-coding.
But in praxis I tend to hard code some values. The main reasons to hard-code are:
There are some "hard-coding best praxis's" I think are never over-engineering:
This makes it possible to move the hard-coded values to an other place later.
Silver bullets do not exist in IT.
If someone tell you to do the dumb thing, save the email thread and save your J.O.B.
If I need a char * to point to 12 characters, I can safely write malloc(12) because sizeof(char) will always be 1. If I need an int * to point to 12 integers, I write malloc(12 * sizeof(int)).
Hardcode the few things that will absolutely, positively never change. For everything else, it takes an extra two seconds, so why not go ahead and do it?
I think hard coding the default values is the way to go for everything that might be needed to be configurable:
In our GUI code (client-server) we use a three step lookup: we ask our preferences instance for a preference with a default value. But this passed default value is overridden by a config file, if it exists.
That way we have two options later. If a customer wants something different, we can change it in the config file. And we can also configure our settings dialog to make it user configurable.
So effectively we have hard codes, that can be overridden by config, that can be overridden by user preferences.
The only problem is to document all the preferences keys...
If hard-coding is done correctly, it can be a bonus. For example, if you hard coded your array sizes instead of doing dynamic allocation, it makes it easy for debugging since you know exactly where the array resides in memory. This is assuming that you actually want to know things like these though.
Usually more time and money is spent maintaining the code than writing it originally. 80% of total spent on the code is typically spent during the maintenance period. Therefore anything that makes maintenance harder will eventually cost more than doing it right the first time. Hard-coding is definitely one thing that makes maintenance harder, and consequently is a bad idea.
In embedded and critical software, hardcoding has two main advantages:
This means less CPU load, i.e. less power consumption, less or no dynamic memory allocation, less algorithmic complexity, i.e. easier debugging, ...
Usually, hard coded data are put in a single header file for more maintainability.
Moreover, flexibility is provided by an automatic generation of this header file from a database.
I always create a constant, but close as possible/sensible to where its "only" use is to be.
If I then need it somewhere else in the unit, it gets moved to the top of the unit.
If its then needed in another unit, the constant gets moved to a settings unit.
If someone wants it changable it gets moved to the settings unit (if not already), and set from a config file etc.
At the end of the day the name you give the thing is its documentation, at the very least it means you don't get your 73 mixed up with someone elses 73. If you see what I mean.
Regarding hard coded strings in C/C++; I usually #define them as the simplest way to avoid hard coding (though in a sense that is still of hard coded). The reason is that a defined identifier that is misspelled will be caught by the compiler, whereas anything between quotation marks will not.
My attitude to configuration? It's too often done poorly and too casually - increasing TCO as users try to grok 100s of configurable values. Add configurability (soft coding) only when proven necessary.
When it's necessary ... A configurable value ought to be treated with the same mistrust as user input, and provide lucid error messages when input is bad. Most components should be isolated from the configuration infrastructure - just as you isolate most components from any data access infrastructure. Once isolated from the configuration infrastructure, you can and should test how the component handles various "input" from the configuration system. Most important, the program should work just fine with an absolute minimum of configuration.
However, this type of anti-pattern is extremely common:
File.Open(configuration["widgetsFileStorage"] + "/" + widgetImage)
Or this (would you ever put user input directly into an href? I wouldn't. Somehow, many people trust configuration values far too much ).
LinkWriter.href=configuration["supportUrl"]
When to configure? As you prove you need to. Good separation of concerns will make it easy to make a value configurable at a later point. I'd drop responsibility for locating a file into a file locater.
File.Open(new WidgetFileLocater().GetUncPath(widgetImage))
Somewhere behind my file locator I might or might not refer to a configuration file, a database. I'll probably start hard coding to a "images" directory in the application directory. Configuration comes when we have a use case for flexibility (someone wants to put it on SAN?) but not before. Anyway, most of the app should not whether it's configured or not. I'd likely use some dependency injection on the file locater to verify that it correctly handled lousy input from the configuration file.
Also: Configuration is almost always loosely typed, not compiled, and thus much more dangerous than code. This risk is rarely respected by developers (but heavily respected by sysadmins). I've debated using a script language like python / ironpython / boo for configuration needs. I'd get the ability to change stuff after compilation, with a much more free syntax and type checking than xml or text.
Caveats: My attitude assumes an iterative release cycle. If you have a 2-10 year release cycle, like Microsoft, you'll want to bias in favor of configuring many more values .