string.format vs. string concatenation

[Crendgrim]

Finally, while you can use string.format(), you don't have to.

I'm very sorry to use this thread for my question, but as this topic arose here: What are the advantages / disadvantages of using string.format()?
Or is it just a matter of taste?


Crend

[Anonymissimus]

[What are the advantages / disadvantages of using string.format()?
Or is it just a matter of taste?

Silene said performance.
Afaik if you concatenate strings like this
local s3 = "s1" .. "s2"
you first construct (which needs some time and memory) each of them and then concatenate them, this is somehow optimized when using string.format
local s3 = string.format(%s%s, s1, s2)
Also, one can perform a precise check about the type and values of a variable (whether a positive integer actually is for instance).

[8680]

On my computer at least, concatenations are faster when you're only doing a few of them, but string.format() is faster when you have many variables to interpolate. But, as with most such things, you'd have to be doing billions of interpolations like I was to notice it. The main difference is that string.format() can format ( ) the variables being interpolated.

[melinath]

I've had some issues with string formatting and userdata (like translated strings) in the past. I do generally prefer string.format, though, because it's easier to read.

[8680]

I've had some issues with string formatting and userdata (like translated strings) in the past.

Try tostring(...):format(...).

I do generally prefer string.format, though, because it's easier to read.

Even with syntax highlighting?

[melinath]

Try tostring(...):format(...).

Yeah, that's what I ended up doing. This was a while ago. Although I'm pretty sure you mean string.format(<format_string>, tostring(<userdata_string>), <normal_string>, ...)

Even with syntax highlighting?

Compare:

string.format("%s.%s", namespace, key)

namespace .. "." .. key

Looking at the first, it's easy to tell immediately that I have two strings separated by a period. It's not that hard to understand the second, either, but it does take just a split second longer (at least for me) - and this is a simple example. Something more complex might be:

string.format("%s pokes %s in the belly %d times, then %s away on a %s.", person1, person2, number_of_times, verb, steed)

person1 .. " pokes " .. person2 .. " in the belly " .. number_of_times .. " times, then " .. verb .. " away on a " .. steed

Here, with the string.format version, the number of variables being replaced is large enough that there is some cognitive load if you need to match variables with their place in the sentence - however, it's extremely easy to parse what the sentence is going to say.

The concatenation version, otoh, clearly shows where each variable goes in the sentence, but it's practically illegible - and it was a pain to type. I kept forgetting spaces at the beginning of the hard-coded string segments. Syntax highlighting helps only marginally.

Granted, this is based on an experimental pool consisting only of me.

Edit:: Just ran across a case where I generally use concatenation: incrementally building strings. For example, building a message based on a lua table. I usually loop through the table and add a new bit to the string each time. Suppose I could use string.format here as well. Maybe I should, if it's faster.

[8680]

Although I'm pretty sure you mean string.format(<format_string>, tostring(<userdata_string>), <normal_string>, ...)

Ah. I assumed the t_string was the formatstring. I'm not sure why now.

Granted, this is based on an experimental pool consisting only of me.

It's not like my sample size is any better. Anyway, I didn't intend to discuss a subjective topic like legibility, and furthermore this off-topic conversation about concatenation versus formatting has been too long ongoing.