When including a package using the \usepackage command that has a lot of options, are there:

  1. Any restrictions on how the options can be split across multiple lines?
  2. Any best practices for formatting the options across multiple lines?


% Example #1

% Example #2
  • 3
    Aside from not having any \par token (blank line) in the list of options, I don't think there is any particular restrictions. I usually use one line for each package option---the first option should be on the line following the one that contains \usepackage---so they can be commented in/out easily. Also, if I have many key=value pairs, I find that aligning the equal signs horizontally helps code readability. – jubobs Jan 23 '14 at 20:07
  • 1
    biblatex sometimes reacts badly to spaces but only between certain options and I've yet to figure out the pattern. I've not tried it multiline, though. – cfr Jan 23 '14 at 21:49
  • @cfr TeX reports the newlines as spaces to the package so whatever happens newlines are the same as spaces (apart form two newlines being \par) – David Carlisle Jan 24 '14 at 0:24

The standard processing runs the entire argument through \zap@space before processing the comma list, so all white space is ignored (except that a blank line would be turned into \par and generate an error before the processing starts.

However you show examples of geometry with a key=value list. You don't want to remove all white space in keyval parsing as the value might (in general) need spaces, Any package that has such a syntax has inserted its own option handler, so the answer in principle depends on the package used, however most will be using keyval or xkeyval or l3keys based systems in which case white space around the , and around the = will be ignored.


Aside from not leaving any blank line within the list of options (equivalent to a \par token), I don't think there is any particular restriction.

My preferred formatting style for loading packages is shown below.

    left        = 1in,
    right       = 1in,
    top         = 1.5in,
    headheight  = 1in,
    headsep     = .3in,

Let me rationalise it, lest my answer be perceived as primarily opinion-based.

  1. Each option should be on a line on its own, so it can be easily commented/uncommented without having to reformat the code or delete stuff. For this to work, the first option should be on a dedicated line (i.e. not on the same line as \usepackage), and the last option too should be on a dedicated line (i.e. not on the same line as the closing ]).
  2. Package options should be indented by one tab stop to make the options stand out.
  3. If there are many key=value pairs, aligning the equal signs vertically usually makes the code much easier to read.

Addendum (by Speravir)

There’s a variation, where the commas are set in front of all, for people, who too easily tend to delete them at the end when changing a value:

    ,left       = 1in
    ,right      = 1in
    ,top        = 1.5in
    ,headheight = 1in
    ,headsep    = .3in

You could even have commas before and after each key-value pair, because empty strings are stripped, as well.

  • You could add the version, where the commas are in front of all. Some people like this more (me not), because they tend to delete them too easily otherwise. – Speravir Jan 24 '14 at 0:52
  • @Speravir Meh, I don't really like that. Feel free to add is as an answer if you believe in that style, though. – jubobs Jan 24 '14 at 0:53
  • Having the commas at front also easily allows commenting out options. – Martin Schröder Jan 24 '14 at 9:50
  • @MartinSchröder More than when you put them at the end? Why? – jubobs Jan 24 '14 at 9:54
  • 1
    @Jubobs \usepackage[]{package} is equivalent to \usepackage{package}; I like better \usepackage[, new line, options, new line, ]{package} that shows more clearly the start and end. – egreg May 13 '14 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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