For instance, you let the user define the notorious path variable. How do you interpret apppath = C:\Program Files\App?

This looks like a programming language adopted practice to ignore the white spaces and you leave them around the equality mark for readability, but it might be a valid variable value with white space in the application (consider, it is a suffix).

Even keys can contain whitespaces, can't they?

What is the general best practice for my application? If I have:

key-example = value-example

should I interpret the key being "key-example" or "key-example " and the value as being "value-example" or " value-example"?

  • I've read your question two times and still don't understand it. Could you rephrase it a little or show some code along with what you are trying to achieve?
    – Jay
    Feb 1, 2015 at 12:47
  • What programming language are you using for parsing the file? Feb 1, 2015 at 15:59
  • 2
    @user61852: why should that matter? The requirements for the config file should be fully independent from the programming language. Think of five different programs written in five different languages all sharing the same configuration file.
    – Doc Brown
    Feb 1, 2015 at 17:02
  • 1
    @user61852 It does not matter. I tried to use : in place of = because I use this exclusively in javascript (although my question is not limited to my app, therefore it is irrelevant to ask about its language at all) but this did not help me to read the config as JSON object. JSON requires all values quoted, which is unnecessary burden on the user.
    – Val
    Feb 1, 2015 at 18:35
  • @valtih I asked because some languages already have an API for config files. For example Java has a Properties class that handles those kind of key/value files. Feb 1, 2015 at 23:35

2 Answers 2


As a user, I don't expect the whitespace on either side of the equals sign to change the value of the key or the value. See this related question on unix.SE as too how confusing the situation can be.

Don't make it harder on your users, trim whitespace from both the key and the value. If leading whitespace has a real use case for either, then let the user wrap the key or value in quotes.


It's up to you to define the rules for your app.

For instance, you may define that:

  • Whitespace before or after the equality sign is ignored,

  • Whitespace inside the key is forbidden,

  • Whitespace inside the value can be used only if the value is enclosed in quotes, so:

    say-hello = Hello, World!

    is forbidden, while:

    say-hello = "Hello, World!"

    is allowed, which also makes it possible to have whitespace prefixes:

    say-hello = "    Indentation is sweet."

Defining a format may be a complex task. For instance:

  • How do you escape quotes?

  • How do you escape the escape character you use to escape quotes?

  • How do you handle empty values?

  • What is the maximum length of a key? What about a value?

  • How do you handle multiline values?

  • What about whitespace Unicode characters other than a space (such as a non-breaking space character)?

  • What about Unicode characters which are usually not displayed on the screen? For instance, how do you deal with Unicode categories Cf or Zl?

  • What are the characters allowed in the key? For example, is:


    a valid key?

  • Should the following line work?¹

    say-hello ꘌ "Hello, World!"

    Hint: the equality sign is not an equality sign, but the character 0xa60c (Vai syllable lengthener). Although few people would use this symbol instead of the equality, the more frequent case is a copy-paste from Microsoft Word (watch closely the quotation marks):

    say-hello = “Hello, World!”
  • etc.

This is why, unless you are completely sure that you can define a format and describe it precisely and verbosely, use a format which already exists.

JSON or XML are commonly used formats you can use in nearly every programming language. You may even abstract the underlying format by using a database. Redis, for instance, is a popular solution for key-value store.

¹ Chrome users using Windows would probably see a question mark in a square. With other browsers or with Chrome on Linux, the character appears like an equality sign and can easily be misleading: the only visual difference is that there is a tiny difference in the space between the horizontal bars.

  • Well, I will specify it to the user. I had a simple line per equality-separated key/value pair format in mind. That is, every line is split by = and quotes are not the issue whereas it is unclear with whitespaces because I prefer to have them and this creates ambiguity. Saying that leading/ending whitespaces are trimmed is enough. Thanks.
    – Val
    Feb 1, 2015 at 13:29
  • @valtih: Especially trimming trailing whitespace is good, IMO. Most users would not realize that it would be there as it is essentially invisible. Feb 1, 2015 at 16:35
  • @mainma That oversized equals sign renders perfectly on my win7 box in everything I've tried that's unicode aware. Feb 1, 2015 at 18:52
  • @DanNeely: that's weird. On Windows 8.1, Chrome shows a question mark in a square. Feb 1, 2015 at 20:18
  • 1
    @MainMa Chrome has always had issues with Unicode fallback on Windows. That's been a known issue pretty much for its entire existence (~5 years?); here is (one of?) the bug for it, and it might as well be wontfix at this point. It works fine in Firefox and IE.
    – Bob
    Feb 1, 2015 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.