Home/ Questions/Q 7735437
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T07:30:07+00:00

I was thinking about the old holy war that is curly brace placement ,

  • 0

I was thinking about the old holy war that is curly brace placement, and decided that it really wasn’t so much an issue with programmers as an issue with the IDE.

Most C-style programming languages* support a mishmash of whatever spacing and alignment the programmer would like:

foo(bar, baz) {
  fizz();
  buzz();
}

is functionally identical to:

foo(bar, baz)
{
    fizz();
    buzz();
}

is functionally identical to:

foo(bar,baz){fizz();buzz();}

No one questions this, but programmers are still apt to disagree over the correct formatting.

Because it’s such a user preference, I thought it would be convenient if there was an IDE that would automatically re-flow the written code into the format specified by user preferences while leaving it as written:

foo
(
bar
,
baz
)
{
fizz();
buzz();
}

would be auto-formatted to look like:

foo(bar, baz)
{
    fizz();
    buzz();
}

or whatever your preference is, without changing the original code (or maybe auto converts it to a different format on save)…

And then I realized it’s not likely that I’ve got an original idea.

So the crux of the matter is whether this functionality already exists, and I simply haven’t found it, or whether it doesn’t exist and I need to make it.

* I typically write in JavaScript, CSS, C#, and PHP; obviously this would be useless for a language such as Python.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    They’re called (code) “formatters” or “beautifiers”, and there’s a bunch around, some even built into your favorite IDE(s).

    The biggest problem they suffer from is people that insist on microscopic formatting properties, and the almost religious-war disagreement among programmers on what good layout is. I call this the “art” problem: everybody likes his, and dislikes other’s tastes.

    Usually what this means is a that group can’t agree on a format, and so formatting doesn’t happen, and you end up with, well, badly formatted code. I personally find this astonishing; choosing nearly any style for an organization to use I think is a win because now everybody knows what to expect. Considering that programmers spend 50% of their time reading code, this seems to me like a serious waste.

    AStyle is widely used. It has lots of options so that even cranky people can kind of get the format they want.

    Most of these are based on ad hoc string hacking tricks.e.g., using regexps to find keywords and special syntax such as curly braces. Its pretty easy to build a basic formatter this way. To the extent that such string hacking doesn’t understand the language syntax perfectly (what if a curly brace is escaped in a string literal or some such), they can damage your code (usually by inserting a spurious syntax error, sometimes by breaking the code in more subtle ways), so it is important after formatting to recompile and verify the formatted module.

    My company makes an unusual variety of formatters for programming languages based on parsing and regenerating the language text. These tools have the property that they can’t break your code (unless we’ve made an error in building our parser front ends, which is a lot less likely than somebody with a regular expression). So you can run them across your complete code base without fear of breaking anything.

    We tend to have fewer options than Astyle, although many of these will let you place braces (if important in that language, e.g., PHP or Java) in various “typical” places. But even braceless langauges such as Python can have layout rules about things other than braces, such as how to indent compound conditional expressions, etc. Our tools usually have these.

    • 0