Long ago I started defining my own tex document classes and I came across the sty/cls dilemma. I've always used the answer described here as my rule of thumb:

If [new] commands could be used with any document class, then make them a package; and if not, then make them a class.

Everything was doing great when I finally started to develop my custom beamer theme. The most comprehensive guide I've found so far is this one, and it looks like that beamer has a rather complicated built-in inner/outer theme schema defined by .sty files.

This clearly neglects the rule of thumb, in fact we have 4 .sty files for the same theme, which can only be used with beamer (hence there should be a .cls file)

What is the advantage of this design? Could I ignore beamer convention and stick to my misplaced good habit? Should I?

  • 3
    You have different themes, enhancing the color/layout of standard beamer. Would you prefer 53 different classes for each theme? Beamer is a very very complex and modular project. It is good the way it is.
    – Johannes_B
    Apr 9, 2015 at 12:07
  • 1
    One could discuss if the sty should have another extension, e.g. .btf ("beamer theme file") or .bco ("beamer configuration option"). But there certainly should not go in a class. There are accompaigning files. And why add another file extension? Apr 9, 2015 at 12:31

1 Answer 1


Beamer (and from the same author TikZ/PGF) follows the compartmentalization scheme. What you are describing is still following that scheme actually but in a larger scale.

It is both a class and it has its internal packages (themes actually).

  • Why is it a document class ?

Because, it alters the page size, page elements, typical title and author placement mechanism, figures and captions etc. Hence you cannot use it together with other classes. It fundamentally replaces many common LaTeX mechanisms. enumitem package is an unfortunate loss for example in beamer as usually they don't play nice together. Thus, it is necessarily a document class.

  • Why are there so many .sty files?

That's because of the bottom/up design, every page has internally comprise of a few choices, in beamer lingo; templates. You can select different templates for different components, say, I need a split footer and a header with section dots and also that color scheme. This is possible since every sub component is a pseudo-package that you can combine and call it inside an encapsulating theme with \usetheme{foo}. Then it will go and grab the necessary contents from those .sty files. But I can make another theme {foo2} and change only the colors and it would be a matter of a one-liner. Had it been as you have quoted. It would be a huge mess. Notice for example that if you only need a for loop. You only need to say \usepackage{pgffor} instead of loading the whole TikZ suite.

I think that manual is rather a guideline instead of a PEP8 type of forcing. So you don't need to setup a religious view around it. And the authors know exactly how difficult to keep track of package conflicts hence it is a conservative approach.

  • I see, their design was really good in this aspect. I still don't think there is much benefit for me if I follow this modular design instead of providing myself a new class. I imagine that if someday my theme was released, it would be poorly compatible/customizable though, so I'll try to stick with their schema. Thank you very much.
    – villasv
    Apr 9, 2015 at 12:36

You must log in to answer this question.

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