Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

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

\newcommand{\foo}{foo}

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.)

share|improve this question
8  
I disagree that this question should be closed. –  Will Robertson Aug 18 '10 at 10:06
8  
I can just imagine someone in the 3rd century BC saying "Why I wonder would anyone use punctuation it just makes things harder to read" –  naught101 Jul 24 '12 at 6:38
1  
Related question How bad for TeX is omitting braces even if the result is the same. –  Kurt Feb 15 '13 at 15:22
add comment

8 Answers

up vote 27 down vote accepted

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

\newcommand{\bar}

and

\newcommand\bar

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.

share|improve this answer
8  
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 '10 at 7:25
    
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 '10 at 7:32
10  
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. –  Jan Hlavacek Aug 26 '10 at 6:57
4  
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 '10 at 7:06
    
@JosephWright What is the recommended style for xparse commands such as \NewDocumentCommand? –  Lover of Structure Dec 28 '13 at 22:51
add comment

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...

share|improve this answer
add comment

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.)

share|improve this answer
add comment

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.

share|improve this answer
    
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 '10 at 12:44
add comment

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.

share|improve this answer
4  
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 '10 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 '10 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 '10 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 '10 at 15:33
    
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. –  Mike Shulman Oct 7 '10 at 19:12
add comment

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.

share|improve this answer
add comment

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}...}

and

\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 :))

share|improve this answer
11  
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. –  Taco Hoekwater Aug 18 '10 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 '12 at 18:06
add comment

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

\newcommand{\foo}{foo}

much easier to read than:

\newcommand\foo{foo}

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

share|improve this answer
5  
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 '10 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 '10 at 6:09
    
@SamB: It's also true of every macro that takes an optional argument. –  TH. Dec 19 '10 at 7:03
    
@TH.: But it's not usually so glaringly obvious in the source code ;-) –  SamB Dec 19 '10 at 7:14
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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