Formatting strings

re: Formatting strings

Vincent Croquette — Tue, 11 Nov 2008 15:11:34 GMT

<quote>Readability is king unless there are big-Oh reasons to change...</quote>

This could also be one of my mottos

yet, even though str1 + str2 is sometimes more readable than string.Format(... I've stopped using it for performance reasons

Anders Hejlsberg used it in his PDC presentation and I thought it was very approprate in this context (i.e. the context in which someone else than you has to read your code)

Jon, glad to see you also own an eee. I bought it for ebooks reading... but was surprised I could actually develop WCF services and Silverlight frontends with it (OK, the performance is not optimal, but it's still usable)

re: Formatting strings

skeet — Tue, 04 Nov 2008 19:40:03 GMT

@Sam: Look at the advice you give at the end. It's about performance, and not about readability:

"However, When you need to concat 5 or more strings, use multiple statements of 4 strings at once. This is appropriate for when you have a known number of strings."

I would always go for the simpler approach until the performance proves to be a bottleneck.

As for this blog post: it's about performance without giving advice to readers (seeing as the request I've made hasn't come to fruition yet). However, look at the last bit:

"I'm not saying it would do a huge amount to aid performance, but it could shave off a little time here and there, as well as making it even more obvious what the format string is used for."

See - it's about making it more readable *as well* as performing better.

re: Formatting strings

Sam — Tue, 04 Nov 2008 19:02:58 GMT

I don't see why you say the dotnetperls.com article is solely focused on performance. It has many more examples than this blog post. Obviously you want to write clear code.

In my opinion this post is focused solely on performance.

Sam

re: Formatting strings

skeet — Tue, 04 Nov 2008 18:47:20 GMT

The problem with that article is it's focused solely on the performance. Sure, concatenating 5 strings in one go may be slightly slower than keeping them within blocks of four - but it's more readable.

Readability is king unless there are big-Oh reasons to change...

re: Formatting strings

Charles Feduke — Tue, 04 Nov 2008 18:39:47 GMT

Working my way through some of your older articles, I thought you may find:

www.dotnetperls.com/.../String-Concat.aspx

interesting. Well okay the interesting part is where he determines that 4 concats are substantially better than 5, and breaking up your concatenations into groups of 4 is always better than just doing more than 4. At some point you resort to a StringBuilder of course, but still interesting to know.

re: Formatting strings

Pavel Minaev — Fri, 10 Oct 2008 14:35:21 GMT

Interestingly, that's one case where F# ML curring functions allow for smoother syntax. You could curry Format with the format string, and if the implementation is smart, it will parse it at that point (or, alternatively, parse it first time it's needed, but then memoize it). Then you save the function that is the result of that currying, and use it. I.e.:

// Core functionality

type ParsedFormatString = ...

let ParseFormatString s = ...

let FormatPreparsed parsedFormatString args = ...

// BCL-style Format on top of that, with currying and memoization

let Format formatString = FormatPreparsed (ParseFormatString formatString)

...

// Parse as usual

for x = 1 to 10 do

for y = 1 to 10 do

Format "{0} {1}" x y

...

// Memoize and reuse

let FormatPair = Format "{0} {1}"

for x = 1 to 10 do

for y = 1 to 10 do

FormatPair x y

Qué es más rapido: String.Format o String.Concat?

.NET a 2.860 metros de altura — Thu, 09 Oct 2008 17:28:29 GMT

Esta es una pregunta que he tenido pendiente mucho tiempo. En general yo prefiero usar String.Format

re: Formatting strings

skeet — Thu, 09 Oct 2008 15:15:08 GMT

@Richard: I certainly wouldn't suggest doing that. But I'd suggest doing:

sb.Append(x);

sb.Append(":");

sb.Append(y);

instead of

sb.AppendFormat("{0}:{1}", x, y);

(If performance were an issue, of course.)

re: Formatting strings

Richard — Thu, 09 Oct 2008 15:06:43 GMT

As for the relative efficiency of String.Format versus StringBuilder.AppendFormat, have a look at the code for the String.Format(IFormatProvider, string, params object[]) method:

public static string Format(...)

{

...

StringBuilder builder = new StringBuilder(format.Length + (args.Length * 8));

builder.AppendFormat(provider, format, args);

return builder.ToString();

}

Clearly, if you already have a StringBuilder, it's more efficient to call AppendFormat than Append(String.Format).

The only caveat is if the format string is invalid: AppendFormat will append the start of the format string, and then throw an exception, whereas Append(String.Format) will throw an exception without modifying the StringBuilder instance.

Interesting Finds: 2008.10.08~2008.10.09

gOODiDEA.NET — Thu, 09 Oct 2008 00:52:59 GMT

.NET Richmond Code Camp 2008.2 - Functional C# Recap ASP.NET MVC with NHaml - F# Edition Formatting strings

re: Formatting strings

ffpf — Tue, 07 Oct 2008 13:25:11 GMT

I would like to see the format string compiled like Regex can be; possibly broken into an expression tree so that it only needs to get parsed once and is thereafter faster to run. I've often wondered why we don't have the concept of a compiled format string so that calls like string.Format will be more efficient in repeated calls.

re: Formatting strings

skeet — Tue, 07 Oct 2008 08:57:55 GMT

@James: Gosh, that's an interesting idea. I like that. I think it would require some extra support above and beyond what the current interfaces express, but it's still a neat plan.

re: Formatting strings

James Hart — Tue, 07 Oct 2008 08:45:19 GMT

How about strongly-typing compiled format strings as delegates, in the manner of F#? Maybe not going so far as to have the compiler actually parse the format string and infer the types, but how about:

var format = Formatter.Compile<string, double>("{0} ({1:0.00})");

string formatted = format("Hello", Math.Pi); // "Hello (3.14)"

Gives you the opportunity to fail at Formatter.Compile if the format string tries to use a format item that isn't specified or with an incompatible format string for a given type.

Reflective Perspective - Chris Alcock » The Morning Brew #195

Reflective Perspective - Chris Alcock » The Morning Brew #195 — Tue, 07 Oct 2008 07:04:14 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #195

re: Formatting strings

skeet — Mon, 06 Oct 2008 18:55:59 GMT

@David: No, I haven't. Will do :)

re: Formatting strings

skeet — Mon, 06 Oct 2008 18:40:34 GMT

As I suspected, it was the blog engine. <sigh>

Oh, and I'm looking forward to the DNR show tomorrow too. It'll be interesting to see if they've managed to edit my drivel into something which makes me sound intelligent!

re: Formatting strings

David Nelson — Mon, 06 Oct 2008 18:38:50 GMT

It certainly makes sense to me. The Regex class has static methods for performing regular expression matching (similar to String.Format), but you can also create an instance of the Regex class with your regular expression and the options you want to use, which can be optimized for reuse. I don't see any reason not to have something similar for String.Format.

Have you made this suggestion to the BCL team directly?

re: Formatting strings

skeet — Mon, 06 Oct 2008 18:31:25 GMT

That's very strange. It should, of course, be "ret = (char) ('A' + rng.Next(26));". I'll fix it in a minute. I wonder how that got past the formatter though. Very strange. It could be yet another case of the blog engine "fixing" things for me :(

The performance issue is a general one though - you can always rewrite a call to String.Format as a (potentially large) call to Concat, but that's not as readable. It would be nice if the framework provided a way to have our cake and eat it - in the form of a "parse once, use often" object.

re: Formatting strings

Kalpesh — Mon, 06 Oct 2008 17:26:20 GMT

Surprisingly, the code doesn't compile.

Line: ret = (char) ('A' + rng.Next(26));

Cannot implicitly convert type 'char' to 'char[]'

The point here is - one should use Concat against Format (in this case). The format will be useful where it does some real formatting operation (e.g. {0:c}

BTW, I am waiting to hear your DNR show ;)