The answer of course may depend on many factors,
but if we start with correct, good formatted plain text code, then
one can more or less generalize things here.
The initial ‘formatting’ in the source text will be:
newline, space and tab characters.
Note that the new line and manual line break (as in DTP software)
are not the same thing, and vice-versa, some rare languages may
allow other formatting characters, although I've never heard of such.
Comments are not executable part of code, so those may be reformatted
without much risk, if one knows if it is really a comment.
So first thing to look at is how comments are tagged.
Some basics about initial plaintext formatting is good to know.
E.g., for Python, there is the PEP8 style guide.
While made for Python, this formatting guide can be used as a reference for major languages such as C/C++ and Java.
Looking into various example projects can help when in doubt.
Thus, the first principle would be: Don’t change the source text.
I would go through a checklist - make sure that:
- No character autoreplacing occurs on any stage.
- No edits to the text are made (unless you are 100% sure they must be done).
- No line wraps appear.
- Indentations are preserved visually and are consistent (ca. four x widths per level of indentation).
- The initial (zero) indent level should be visible.
- Defined styles do not destroy the formatting of syntax (if syntax highlighting is used).
- Have a backup of the source in plain text, so as to be able to recheck the original formatting or start anew.
- Line numbers, if present, should be intact especially if they are referenced in explanations.
Actually if the original source is properly formatted, there should be
no line wrapping at all.
If wrapped lines still appear and are unavoidable, then a one-level
hanging indent is most common solution (see above linked PEP).
If line breaking is necessary – better consult the style guide or the author.
Still some minor ‘white space’ characters may require replacement.
Since the source can include tab characters, this means of course that the typesetter must ensure that all tabs in the beginning of each line are consistent, i.e. nested indentations are preserved visually and every next
level of indentation is of same width (ca. four x widths per one level of indentation).
Ideally, the indentations which were made with space characters or mixed
spaces and tabs should be replaced with tabulation (or with what the DTP
software can do better for nested indentations), so, if needed, adjusting the indentations may be easier.
Of course one may leave spaces, but it may be harder to manage their width when changing the font and harder to align inner-line indentations like in table columns.
Monospaced font + spaces
Note that if the source is formatted with spaces intentionally and was intended to be read in monospaced font only, (for example ASCII-diagrams or ASCII-art) one should preserve the spaces totally unchanged, but this decision should be made from the beginning.
"Courier New" font is most common for this case. Still if not really needed, I advise against monospaced, because less and less new people choose monospaced for coding today, and in case of proofreading, proportional fonts will give better reading experience.
In general, condensed (e.g. Arial narrow) or smaller fonts may work better:
it gives more emphasis in contrast to body text, it will make code more compact, and thus less probable that unwanted line wrapping will appear.
I think here one can draw a line, and if the above is done, then there
is 99% probability that everything should be fine, at least for a
plain single-font code block without colors.
Tools and advanced formatting
Further, the look can be significantly improved by using syntax highlighting.
color print or screen viewing: in a full-color layout every feature of highlighting can be used, so it is the best-case scenario, but printing may give some color changes.
grayscale or b/w print: here of course one can use bold (e.g. keywords) or italics (e.g. comments) but note that colors will be converted to gray with all consequences. For example grayed-out comments may look great on a display, but can become too pale on paper.
The most important question is, whether the layout maker have tools that can represent the code in a readable form.
Fortunately, there are a lot of free tools for code editing, most prominent (for Windows) are: Notepad++, VSCode, Visual Studio.
But be aware of possible implicit auto-convertions of tabs to spaces though.
In Notepad++ there is an option to export the code as RTF, which will preserve all formatting and syntax highlighting of the source.
If the layout does not require change of the text flow in
code presentation, one may directly use images (screenshots) – it is not so flexible as text, but will preserve 100% formatting and line numbering, and can save a lot of time. E.g. line numbers can be tricky to preserve in text form. Also exporting to PDF is a good alternative – but not all DTP software can embed PDFs and some formatting can be lost when printing to PDF.
For example, my setup for Python code in Notepad++ look like this:
This is just to illustrate, that one can directly use screenshots and that may actually be the easiest method. There are various tools that can help with screen capturing – one may need ‘stitching’ the screens for higher resolution images.
The color scheme is of course upon individual, defined in the style configurator of the editor, which is already aware of the supported language, thus making it hard to make false formatting even if one doesn’t know the syntax.
Here general typography rules should work: not too many colors,
consistent fonts, indentations, comfortable line spacing.
Additional tools/plugins for custom language definitions are also common,
but those require syntax knowledge.
