Hardcoding strings that will never change

Question

So, in my efforts to write a program to conjugate verbs (algorithmically, not through a dataset) for French, I've come across a slight problem.

The algorithm to conjugate the verbs is actually fairly simple for the 17-or-so cases of verbs, and runs on a particular pattern for each case; thus, the conjugation suffixes for these 17 classes are static and will (very likely) not change any time soon. For example:

// Verbs #1 : (model: "chanter")
    terminations = {
        ind_imp: ["ais", "ais", "ait", "ions", "iez", "aient"],
        ind_pre: ["e", "es", "e", "ons", "ez", "ent"],
        ind_fut: ["erai", "eras", "era", "erons", "erez", "eront"],
        participle: ["é", "ant"]
    };

These are inflectional suffixes for the most common class of verb in French.

There are other classes of verbs (irregulars), whose conjugations will also very likely remain static for the next century or two. Since they're irregular, their complete conjugations must be statically included, because they can't reliably be conjugated from a pattern (there are also only [by my count] 32 irregulars). For example:

// "être":
    forms = {
        ind_imp: ["étais", "étais", "était", "étions", "étiez", "étaient"],
        ind_pre: ["suis", "es", "est", "sommes", "êtes", "sont"],
        ind_fut: ["serai", "seras", "sera", "serons", "serez", "seront"],
        participle: ["été", "étant"]
    };

I could put all this into XML or even JSON and deserialize it when it needs to be used, but is there a point? These strings are part of natural language, which does change, but at a slow rate.

My concern is that by doing things the "right" way and deserializing some data source, I've not only complicated the problem which doesn't need to be complicated, but I've also completely back-tracked on the whole goal of the algorithmic approach: to not use a data source! In C#, I could just create a class under namespace Verb.Conjugation (e.g. class Irregular) to house these strings in an enumerated type or something, instead of stuffing them into XML and creating a class IrregularVerbDeserializer.

So the question: is it appropriate to hard-code strings that are very unlikely to change during the lifetime of an application? Of course I can't guarantee 100% that they won't change, but the risk vs cost is almost trivial to weigh in my eyes - hardcoding is the better idea here.

Edit: The proposed duplicate asks how to store a large number of static strings, while my question is when should I hard-code these static strings.

Answer 1

is it appropriate to hard-code strings that are very unlikely to change during the lifetime of an application? Of course I can't guarantee 100% that they won't change, but the risk vs cost is almost trivial to weigh in my eyes - hardcoding is the better idea here

It looks to me that you answered your own question.

One of the biggest challenges we face is to separate out the stuff that's likely to change from the stuff that won't change. Some people go nuts and dump absolutely everything they can into a config file. Others go to the other extreme and require a recompile for even the most obvious changes.

I'd go with the easiest approach to implement until I found a compelling reason to make it more complicated.

Answer 2

You are reasoning at the wrong scope.

You haven't hardcoded only individual verbs. You have hardcoded the language and its rules. This, in turn, means that your application cannot be used for any other language, and cannot be extended with other rules.

If this is your intent (i.e. using it for French only), this is the right approach, because of YAGNI. But you admit yourself that you want to use it later for other languages as well, which will mean that very soon, you'll have to move all the hardcoded part to the configuration files anyway. The remaining question is:

• Will you, with a certainty close to 100%, in the near future, extend the app to other languages? If so, you should have been exporting things to JSON or XML files (for words, parts of the words, etc.) and dynamic languages (for rules) right now instead of forcing yourself to rewrite the major part of your app.

• Or there is only a minor probability that the app will be extended somewhere in the future, in which case YAGNI dictates that the simplest approach (the one you're using right now) is the better?

As an illustration, take Microsoft Word's spelling checker. How many things do you think are hardcoded?

If you are developing a text processor, you could start by a simple spelling engine with hardcoded rules and even hardcoded words: if word == "musik": suggestSpelling("music");. Rapidly, you'll start moving words, then rules themselves outside your code. Otherwise:

• Every time you have to add a word, you have to recompile.
• If you learned a new rule, you have to change the source code once again.
• And more importantly, there is no way you can adapt the engine to German or Japanese without writing tremendous amounts of code.

As you highlighted yourself:

Very few rules from French could be applied to Japanese.

As soon as you hardcode the rules for a language, every other one will require more and more code, especially given the complexity of natural languages.

Another subject is how you express those different rules, if not through code. Ultimately, you may find that a programming language is the best tool for that. In that case, if you need to extend the engine without recompiling it, dynamic languages may be a good alternative.

Answer 3

Strings should be extracted to a configuration file or database when the values could change independently from the program logic.

For example:

• Extracting UI texts to resource files. This allows a non-programmer to edit and proof-read the texts, and it allows adding new languages by adding new localized resource files.

• Extracting connection strings, urls to external services etc. to configuration files. This allows you to use different configurations in different environments, and to change the configurations on the fly because they may need to change for reasons external to your application.

• A spell checker which has dictionary of words to check against. You can add new words and languages without modifying the program logic.

But there is also a complexity overhead with extracting to configuration, and it doesn't always make sense.

Strings may be hardcoded when the actual string cannot change without changing the program logic.

Examples:

• A compiler for a programming language. The keywords are not extracted to a configuration, since each keyword have specific semantics which has to be supported by code in the compiler. Adding a new keyword will always require code changes, so no value in extracting the strings to a configuration file.
• Implementing a protocol: Eg. a HTTP client will have hardcoded strings like "GET", "content-type" etc. Here the strings are part of the specification of the protocol, so they are the parts of the code least likely to change.

In your case I think it is clear that the words are an integrated part of the program logic (since you are building a conjugator with specific rules for specific words), and extracting these words to an external file has no value.

If you add a new language you will need to add new code anyway, since each language have specific conjugation logic.

---

Some have suggested that you could add some kind of rule engine which allows you to specify conjugation rules for arbitrary languages, so new languages could be added purely by configuration. Think very carefully before you go down that road, because human languages are wonderfully weird so you need very expressive rule engine. You would basically be inventing a new programming language (a conjugation DSL) for dubious benefit. But you already have a programming language at your disposal which can do anything you need. In any case, YAGNI.

Answer 4

I agree 100% with Dan Pichelman's answer, but I would like one thing to add. The question you should ask yourself here is "who is going to maintain/extend/correct the word list?". If it is always the person who also maintains the rules of a specific language (the particular developer, I guess you), then there is no point in using an external configuration file if this makes things more complex - you will not get any benefits from this. From this point of view, it will make make sense to hardcode such word lists even if you have to change them from time to time, as long as it is sufficient to deliver a new list as part of a new version.

(On the other hand, if there is a slight chance someone else must be able to maintain the list in the future, or if you need to change the word lists without deploying a new version of your application, then use a separate file.)

Answer 5

Even while hardcoding seems fine here, and better than dynamically loading config files, I still would recommend that you do strictly separate your data (the dictionary of verbs) from the algorithm. You can compile them right into your application in the build process.

This will save you a lot of hazzle with maintenance of the list. In your VCS you can easily identify whether a commit did change the algorithm, or just fix a conjugation bug. Also, the list might need to be appended in the future for cases you didn't consider. Especially, the number of the 32 irregular verbs you counted doesn't seem be exact. While those seem to cover the commonly used ones, I found references to 133 or even 350 of them.

Answer 6

The important part is separation of concern. How you achieve that is less relevant. i.e. Java is fine.

Independently of how the rules are expressed, should you need to add a language of change a rule: how many code and files do you have to edit?

Ideally, adding a new language should be possible by either adding a 'english.xml' file or a new 'EnglishRules implements ILanguageRules' object. A text file (JSON/XML) gives you an advantage if you want to change it outside of your build lifecycle, but require a complex grammar, parsing, and will be harder to debug. A code file (Java) let you express complex rules in a simpler way, but require a rebuild.

I would start with a simple Java API behind a clean language agnostic interface - as you need that in both cases. You can always add an implementation of that interface backed by an XML file later if you wish, but I don't see the need to tackle that problem immediately (or ever).