Difference between revisions of "Publications/verna.11.tug"
From LRDE
Line 5: | Line 5: | ||
| title = Towards LaTeX Coding Standards |
| title = Towards LaTeX Coding Standards |
||
| booktitle = TUGboat |
| booktitle = TUGboat |
||
− | | pages = |
+ | | pages = 309 to 328 |
| editors = Barbara Beeton, Karl Berry |
| editors = Barbara Beeton, Karl Berry |
||
| volume = 32 |
| volume = 32 |
Revision as of 18:58, 4 January 2018
- Authors
- Didier Verna
- Where
- TUGboat
- Type
- inproceedings
- Projects
- Software"Software" is not in the list (Vaucanson, Spot, URBI, Olena, APMC, Tiger, Climb, Speaker ID, Transformers, Bison, ...) of allowed values for the "Related project" property.
- Date
- 2011-01-01
Abstract
Because LaTeX is only a macro-expansion system, the language does not impose any kind of good software engineering practice, program structure or coding style. Maybe because in the LaTeX world, collaboration is not so widespread, the idea of some LaTeX Coding Standards is not so pressing as with other programming languages. Over the years, the permanent flow of personal development experiences contributed to shape our own taste in terms of coding style. In this paper, we report on all these experiences and describe what we think are good programming practices.
Documents
Bibtex (lrde.bib)
@InProceedings{ verna.11.tug, author = {Didier Verna}, title = {Towards {\LaTeX} Coding Standards}, booktitle = {TUGboat}, pages = {309--328}, year = 2011, editor = {Barbara Beeton and Karl Berry}, volume = 32, number = 3, abstract = {Because \LaTeX{} is only a macro-expansion system, the language does not impose any kind of good software engineering practice, program structure or coding style. Maybe because in the \LaTeX{} world, collaboration is not so widespread, the idea of some \LaTeX{} Coding Standards is not so pressing as with other programming languages. Over the years, the permanent flow of personal development experiences contributed to shape our own taste in terms of coding style. In this paper, we report on all these experiences and describe what we think are good programming practices.} }