I often see people creating new macros where the macro token is surrounded by braces. For example,


This is unnecessary and I find the extra braces make it harder to read. Why do people do this?

(As an aside, I've even seen people try to use \let{\foo}{\bar} which, of course, doesn't work.)


8 Answers 8


With my LaTeX3 'hat' on, I'd like to give a slightly different perspective. This will overlap with the other answers, but hopefully will be useful. To follow this you need to understand 'tokens', I'm afraid. TeX turns input into tokens, and in particular control sequences such as \bar are single tokens.

When Leslie Lamport designed LaTeX, he decided that all LaTeX arguments should be wrapped in braces. This is in contrast to TeX, where many of the primitives require arguments without braces. However, when only a single token is begin passed you can omit the braces, hence the fact that




both work.

There are really two different cases where you can omit braces:

  1. Cases where the argument is always a single token. This is the case for \newcommand, where you have to have a macro name as the argument. The braces will never be needed as the argument is always \<something>. I do not use braces for these.

  2. Places where you are passing a single token to an argument that will accept more. The classic example would be a subscript, where a_i will work but you'd need a_{ii}. I would always use braces here, so favour a_{i}.

The LaTeX3 part to this answer is that we are trying to be much more rigourous about which arguments are single tokens and which are multiple tokens. At the moment this is only happening at a code level, but I'd anticipate a similar approach for users. So if the argument must be a single token, then make this clear by not using braces. On the other hand, it the argument can take multiple tokens then you must use braces even if only passing a single token.

  • 11
    Interesting. I'm not sure how I feel about mandating braces or their absence. I find that when I want to write simple fractions like 2/3, I tend to use \frac23 since I understand how TeX is going to parse its input into tokens. In this case, it's not that that is more or less readable than \frac{2}{3}, it's simply that it's many fewer characters to type.
    – TH.
    Aug 18, 2010 at 7:25
  • 1
    One of the things that we need to do for LaTeX3 is be more well-defined in terms of input structure. (There is a school of thought that everything should be XML, perhaps generated from a LaTeX-like input format.) Obviously, as TeX will tokenise \frac23 and \frax{2}{3} in the same way it is ultimately up to the user. However, I think the 'official guidance' is going to be 'always use braces for arguments which take more than one token'.
    – Joseph Wright
    Aug 18, 2010 at 7:32
  • 17
    I am not sure I really like this. T find x^2 much more readable and much easier to type than x^{2}, especially in situations where I use a lot of exponents. Of course, it happened to me many times that I quickly typed a quiz before class and after making copies, I discovered that I accidentally typed something like x^15 instead of x^{15}, which could not happen if the braces were mandatory. However, for my taste, XML is just way to verbose, and one thing that I believe contributes to popularity of TeX is that it allows certain sloppiness in its input, which I believe should be preserved. Aug 26, 2010 at 6:57
  • 6
    Luckily for you TeX is not about to change how it accepts arguments! So as long as LaTeX is parsed by TeX then you are safe. As I said, on this particular point it's 'guidance' to use braces. A classic place where this can be important is something like x_{\macro{a}}, which sometimes works without braces but is not reliable.
    – Joseph Wright
    Aug 26, 2010 at 7:06
  • 1
    @JosephWright What is the recommended style for xparse commands such as \NewDocumentCommand? Dec 28, 2013 at 22:51

Code should be readable and understandable. Using braces for all arguments, even if they aren't necessary, is more consistent. So, I prefer to use braces to not confuse unexperienced users.

Leslie Lamport writes in LaTeX - A Document Preparation System: "Macho TeX programmers sometimes remove the braces around the first argument of \newcommand; don't do it yourself."

Leslie Lamport is the initial developer of LaTeX. In the reference manual he specified the syntax of \newcommand to have braces: \newcommand{cmd}[args][opt]{def}. That no error occurs if you deviate from a syntax doesn't mean that this deviation is correct and will work for all times and that automatic syntax checker will understand that this deviation would do no harm, for \newcommand, \renewcommand, \providecommand and their starred environments and perhaps for all places where braces belong to the syntax but aren't strictly necessary.

Since \let is not a LaTeX command, that syntax doesn't apply.

  • Shouldn't it be \newcommand{\cmd} (not \newcommand{cmd})?
    – LSpice
    Aug 19, 2021 at 21:16
  • 1
    @LSpice cmd stands for a command (as a placeholder, not as a command name) such as def for some definition. A command already starts with a backslash, so I don't add another one as a prefix. ;-) But I know what you mean and that's right that commands (or macros) start with a backslash when you define them, that's correct.
    – Stefan Kottwitz
    Aug 20, 2021 at 11:19
  • it seems different people interpret the phrase "deviate from the syntax" differently. for some people, it means "to write in a way that, although equivalent to TeX-the-program, is frowned upon by Knuth/Lamport/some-other-authority/other-users". for other people, it means "to write in such way that TeX-the-program will output something different, or halt compilation". of course the 1st definition encompasses the 2nd. it's a bit far fetched to call the 2nd interpretation "incorrect"... Nov 10, 2022 at 19:53
  • @DanielDiniz Not some authority, but the developer of LaTeX said it. It's documented that way, compiler and syntax checkers, syntax highlighting, code parsing, may rely on it now or in the future or not if they see the reference as strict or not. I did not say "incorrect"; check my wording; I took time to comment on it. Feel free to use commands without braces. Even 13 years after this post, I consider it not as very important to discuss if it's good to use braces when the implementation doesn't require (but the reference or author may require) but fine to spend time on it and on phrasing.
    – Stefan Kottwitz
    Nov 11, 2022 at 22:04
  • You said "doesn't mean that this deviation is correct", which I think is quite equivalent to "this deviation is incorrect" (which is, I argue, a bit far fetched). Uh, "the developer of LaTeX" is (also) "some authority"; they're not mutually exclusive things. As I said, some people consider that writing in a way that's frowned upon by <insert some authority, who might even be the developer of (La)TeX> qualifies as "incorrect" / "not correct", some people don't see this way. Nov 11, 2022 at 22:17

What's easy to read for one person is not necessarily easy to read for another. Personally I find:


much easier to read than:


In particular, it clearly reveals what the two arguments to the function are, which the latter does not.

  • 6
    Interesting. In general, there's no way to know how many arguments a macro takes. If I write \foo{a}{b}{c}{d}, there's no real indication of how many of those are arguments to \foo. For example, \newcommand takes no arguments, TeXnically speaking.
    – TH.
    Aug 17, 2010 at 22:55
  • @TH.: Nor do most of the user-level macros in datatools -- instead, they do a check for a * and then dispatch to one or another internal macro depending on whether or not there was a star, and those take the arguments.
    – SamB
    Dec 19, 2010 at 6:09
  • @SamB: It's also true of every macro that takes an optional argument.
    – TH.
    Dec 19, 2010 at 7:03
  • @TH.: But it's not usually so glaringly obvious in the source code ;-)
    – SamB
    Dec 19, 2010 at 7:14

Contra Stefan (and therefore contra Leslie Lamport), and at the risk of weighing in on a matter involving personal style, I very much prefer the forms

\newcommand\foo{...\baz{\bar}...} to \newcommand{\foo}{...\baz{\bar}...}


\newcommand*\foo[n]{...\baz{\bar}...} to \newcommand*{\foo}[n]{...\baz{\bar}...}.

My reasons are as follows:

  • When standing in this position, \foo is a distinguished entity with a very different role to to play than \bar. For that reason, I like to lexically distinguish it as such.
  • To run with TH's point above, the pattern \newcommand*{\foo}[n]{...} is, for someone who must regularly interpret and sometimes produce TeX and LaTeX-interspersed code, ... well, let's say, a little 'over-ornate'.

Re my second point, the human brain (yes, I actually do hold a research degree in neuropsych and learning), has to manage a huge amount of information during programming and program maintenance. Personally for my tiny little brain, the more regular the patterns it has to deal with, the fewer times it must take its metaphorical eye off the ball and attend to non-problem related tasks. The converse is also true. Of course, I wish it weren't so, but (sadly even more so than in any other computer language I have encountered), this situation is very much the case with the TeX et al. family. [And, here, JW, comes my major and so far only gripe with LaTeX3 - it is layering even more lexical pattern-breaking onto an already complex lexical (let alone syntactic or semantic or pragmatic or programmatic) pattern space. Of course, I agree that there are good technical reasons for this (encapsulation/namespaces being one), however real psychological tradeoffs accrue to real programmers managing real TeX/LateX2/LaTeX3(/LuaTeX) systems. I'm afraid (actually, I'm certain) that as this sort of complexity increases, the program error rate in these systems (and the commercial and non-commercial costs of producing and maintaining them) is going to increase in complex ways as well. Thank God we don't build rocket ships or commercial systems with this code! It might be provably deterministic Turing machine complete, but for heavens sake, TeX/LateX2/LaTeX3(/LuaTeX)'s little programming idioms like \newcommand{\foo}{...} and myriad ilk add like grains of sand to our psychological ability to build robust stuff in this code. And that is why I prefer to keep lexical patterns like \newcommand\foo{...} as far as possible in harmony with the patterns that TeX has for better or worse delivered earlier to us.]

My tuppenny-ha'pence, guys and gals, sorry for taking the bait :))

  • 14
    Plus 1 from me. One of there more important reasons for developing LuaTeX is to offer an escape route from the ever increasing complexity of LaTeX/ConTeXt macros. Aug 18, 2010 at 5:33
  • 2
    I completely agree on your sentiment about state of things with TeX/LaTeX "programming" and that it runs contrary to our brain. In this particular example it your argument does not hold though. In most programming languages that are designed for humans and not computers the syntax for a function looks in general like function_name(first_parameter, second_parameter, ...) and this is roughly equivalent to \function{\first}{\second}, instead of \function\first{\second}.
    – Alexander
    Feb 3, 2012 at 18:06
  • 1
    @Alexander: Many modern programming languages use the brain-friendly syntax as this: function fname(arg1, arg2, ..), this IMO is exactly equivalent to \newcommand \foo{arg1}{arg2}{...}. In particular, \foo will be distinguishable from the args this way.
    – AboAmmar
    Apr 18, 2017 at 16:43

I use braces for all arguments to all macros in LaTeX because not to do this seems to me to be the situation requiring justification. LaTeX is designed such that its macros behave as functions, and so my mental model of something like \newcommand{\foo}{\bar} is "feed \newcommand the intended command \foo and its behavior \bar"; when I see \newcommand\foo{\bar} (or, worse, \newcommand\foo\bar, which works since \bar is a single token) I see the much less obvious "expand \newcommand; also, here is \foo, which happens to be eaten by this expansion before it is, itself, expanded; also, here is \bar, which is likewise serendipitously absorbed". If I did not know (or, in a moment of premature senility, I didn't recall) how \newcommand worked, the latter formation would not tell me. The former would. Even when reading my own document, this allows me to visually group the tokens into "part of a function" and "part of the text".

I am a little surprised that there is any support at all (much less extremely eloquent support) for \newcommand\foo{\bar}, and the nod to \frac23 baffles me (what is the twenty-third fraction command?). It seems to indicate that the respondents regularly engage in a low-level analysis of the TeX parser far beyond what is necessary to compose a structured document. I wouldn't go so far as to write directly in XML myself, but the structure imposed by the LaTeX brace style is clarifying and error-reducing (especially since LaTeX allows it to be applied consistently, unlike the poisonous behavior of TeX's \let, a command which fortunately need never be used in normal circumstances).

Basically, as I see it, \newcommand\foo{\bar} is born of vestigial habits learned from TeX and which support and require a programming mindset that is neither necessary nor desirable in everyday LaTeX. Indeed, it is never taught in references that concern only LaTeX, and I suspect the people here who use it learned to do so in earlier times or from people who themselves learned in those times (specifically in response to Geoffrey Jones: TeX's idioms are familiar to some, but hopefully becoming less so). If a newcomer should read this response, my personal opinion is that they should be aware of this phenomenon and triple-check everything they read about LaTeX on the Internet before learning it.

  • 6
    I appreciate your point about LaTeX macros looking like functions. The problem is that they really aren't functions and they don't behave like functions. I'm not sure what you mean by "poisonous behavior of TeX's \let". I don't know what you mean by normal circumstances, maybe just document writing and not style or class writing. As for omitting braces being a hold over from TeX, I can just say that for myself, I learned LaTeX first and was frustrated that I couldn't understand any of the .sty files; so I read the TeXbook.
    – TH.
    Aug 25, 2010 at 20:47
  • 1
    I was being colorful with "poisonous"; I mean that its syntax is totally different than other commands in that the braces are impossible (and sometimes an = is allowed!). By "normal circumstances" I mean precisely document writing, but I also think the packages could be improved by clear coding. They are, as you observe, completely unintelligible and probably only comprehensible to the author; most of their contents appear to be random strings of symbols and the inclusion of some coding style would probably be to their benefit.
    – Ryan Reich
    Aug 26, 2010 at 0:44
  • There are several TeX builtins that don't allow braces. \input is another. I believe \font is similar. Regarding, =, I believe that any assignment can have an optional =, so that's consistent. I guess I wasn't clear about .sty files. Before I read the TeXbook, I couldn't understand style files because using only what's described in Lamport's book is insufficient. After reading the TeXbook, I can follow most styles and classes.
    – TH.
    Aug 26, 2010 at 5:40
  • There are also TeX builtins which require braces, like \def (in the definition part), which combined with the optional use of = only for assignments is not a convincing argument for the consistency of anything. TeX is a brilliant program but its syntax makes it an awful programming language, which LaTeX tries somewhat to amend, so I think it's a mistake to intermingle TeX programming (and programming practices) with LaTeX document preparation.
    – Ryan Reich
    Aug 27, 2010 at 15:33
  • 2
    LaTeX is designed so that its macros sort of behave like functions, but if you really start to think they are functions then it will eventually bite you. At least, it bit me a lot until I eventually sort of learned how to think about macros. Oct 7, 2010 at 19:12

I use braces after \newcommand mainly to remind myself that I'm not using \def. But there is one (not very weighty) reason to keep the braces: a good LaTeX spellchecker like Excalibur looks for them, to forestall definition errors. Inserting the braces makes spellchecking painless. (Yes, I can spell, but it's best to stamp out misprints before sending files to my coauthors.)


I tend to use braces in all but a few situations, just for clarity. So in the specific case you give above, I would definitely use braces to make it clear that \foo is a separate token/entity that is part of the definition of the command. Essentially the only exception I have to the braces rule is for superscripts and subscripts consisting of a single character, so a_i rather than a_{i}. But there have been many occasions when I have regretted that as well, since I have often forgotten to add the braces back in when making the expression more complicated...


This is a form of the brace style debate in other programming languages. Having programmed both in perl and python I am beginning to favor the forced convention of the latter. Perl's philosophy is TIMTOWTDI, but personally it helps to have regularized code when you have to go back and read it years later.

  • I'm not really sure that applies. Perl forces braces for if( ... ){ ... } and forces no braces for ... if .... Python forces no braces and only has one style of if.
    – TH.
    Oct 7, 2010 at 12:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .