我撰写了一篇包含代码的科学论文，最近收到了校样，即期刊的排字员从我的手稿中创建的内容。结果不可接受：缩进不一致；每个代码块的末尾都有一个句号；引号已被破坏等。请注意，所有错误都不是特定于我使用的编程语言。
现在，我明白了为什么没有编程经验和外部资源的人会犯这样的错误，但在互联网时代，任何人都不应该没有外部资源。因此，我咨询了我最喜欢的搜索引擎来搜索一些可以建议的东西，结果……什么也没有。有很多关于程序员如何在 LaTeX 或类似软件中漂亮地排版代码的指南，这一切都很好，也很恰当，但这显然不适用于必须排版别人代码的排版员。
我正在寻找一种资源：
也许真正的重点是代码不应该真正按照人们理解排版的方式排版。因此，当将代码放入文档时，应逐字逐句放入，如所有空格、制表符、特殊或非特殊字符和换行符一样。
确保您的应用程序不做任何替换！
这意味着没有连字。
此外，许多程序（如 Word 和 InDesign）应用程序将直引号更改为排版对。在将代码放入文档之前，请确保禁用此类选项。
代码不是正文，它不遵循任何印刷约定。问问自己，你会在插图中排版文字吗？
如果您是专家并且您知道所讨论的语言，那么以下内容适用。
注意：不要猜测或推断，请阅读所说的内容。许多语言看起来都一样，代码可能是一些看起来像真实代码的伪语言。那么你就可以：
当且仅当您的替换具有相同的固定宽度时，才可以对关键字进行着色/粗体/斜体等编辑器。最好让编辑器为您执行此操作（说 scintilla 之类的编辑器可以导出格式化的代码）。请记住，编辑器需要了解语言，也许还需要了解库。
请注意，如果您做错了，则弊大于利。
如果您是领域专家。如了解语言和库并了解相关代码：
然后，如果它不适合您的布局，您可以将代码重新排列成几行。除非您真的知道自己在做什么，否则不要这样做，否则您最终可能会造成无法弥补的伤害。
试金石是您是否编写了有问题的代码。如果不是那么你无法判断。问作者。
如何处理？程序员了解代码风格标准。只需在提交指南中写下每行只能容纳 X 个字符。然后程序员可以自己做这件事。代码编辑器经常为此提供工具。使用等距字体的另一个原因。
但后来你知道这一切，你毕竟是专家。最好让作者编辑代码。
一些编程语言和用例可能会受益于行号。不过在这里要小心，因为这在某些语言中是失礼的。
请注意，无论您做什么，实际上都可能遇到不可能的技术障碍。代码不应该真正排版，它应该只是未格式化的文本。这会导致令人惊讶的问题。
例如：许多 PDF 查看器（如 Adobe Acrobat）无法处理 Python 等语言。如果您从 PDF 文件中粘贴代码，编辑器会决定在复制粘贴时不包含前面的空格。这破坏了将代码从 PDF 粘贴到编辑器的能力。实在是没有什么好办法处理！
答案当然可能取决于许多因素，但如果我们从正确、格式良好的纯文本代码开始，那么在这里或多或少可以概括事物。
源文本中的初始“格式”将是： 换行符、空格和制表符。请注意，新行和手动换行符（如在 DTP 软件中）不是一回事，反之亦然，一些罕见的语言可能 允许其他格式字符，尽管我从未听说过这样的。
注释不是代码的可执行部分，因此如果知道它是否真的是注释，则可以重新格式化它们而没有太大风险。所以首先要看的是如何标记评论。
关于初始纯文本格式的一些基础知识很高兴知道。例如，对于 Python，有PEP8 风格指南。虽然是为 Python 制作的，但此格式指南可用作 C/C++ 和 Java 等主要语言的参考。有疑问时，查看各种示例项目会有所帮助。
因此，第一个原则是：不要更改源文本。 我会通过一个清单 - 确保：
实际上，如果原始源格式正确，则根本不应该换行。如果绕线仍然出现并且是不可避免的，那么一级悬挂缩进是最常见的解决方案（参见上面链接的 PEP）。如果需要换行 - 最好咨询样式指南或作者。
仍然有一些小的“空白”字符可能需要替换。由于源可以包含制表符，这当然意味着排版员必须确保每行开头的所有制表符都是一致的，即嵌套缩进在视觉上保留并且每个下一级缩进具有相同的宽度（大约四个x 每一级缩进的宽度）。
理想情况下，使用空格字符或混合空格和制表符制作的缩进应该替换为制表（或 DTP 软件可以更好地处理嵌套缩进），因此，如果需要，调整缩进可能会更容易。
当然，可能会留下空格，但在更改字体时可能更难管理它们的宽度，并且更难对齐表格列中的内行缩进。
请注意，如果源文件有意使用空格进行格式化，并且仅打算以等宽字体阅读（例如 ASCII 图表或 ASCII 艺术），则应完全保持空格不变，但应从一开始就做出此决定。“Courier New”字体在这种情况下最常见。如果不是真的需要，我建议不要使用等宽字体，因为如今越来越少的新人选择等宽字体进行编码，并且在校对的情况下，比例字体将提供更好的阅读体验。
一般而言，精简（例如 Arial 窄）或更小的字体可能效果更好：与正文相比，它更加强调，它会使代码更紧凑，因此不太可能出现不需要的换行。
我想这里可以画一条线，如果以上都做了，那么有 99% 的概率一切都应该没问题，至少对于没有颜色的纯单字体代码块来说是这样。
此外，使用语法突出显示可以显着改善外观。
彩色打印或屏幕查看：在全彩布局中，突出显示的每个功能都可以使用，因此这是最好的情况，但打印可能会产生一些颜色变化。
灰度或黑白打印：这里当然可以使用粗体（例如关键字）或斜体（例如注释），但请注意颜色将被转换为灰色并产生所有后果。例如，灰色的评论在显示器上可能看起来很棒，但在纸上可能会变得太苍白。
最重要的问题是，布局制作者是否有可以以可读形式表示代码的工具。幸运的是，有很多免费的代码编辑工具，最突出的（适用于 Windows）是：Notepad++、VSCode、Visual Studio。但是请注意可能隐式自动将制表符自动转换为空格。
在 Notepad++ 中有一个将代码导出为RTF的选项，这将保留源的所有格式和语法突出显示。
如果布局不需要改变代码呈现的文本流向，可以直接使用图片（截图）——它不像文本那么灵活，但会保留100%的格式和行号，可以节省很多时间。例如，行号可能很难以文本形式保存。导出为PDF也是一个不错的选择 - 但并非所有 DTP 软件都可以嵌入 PDF，并且在打印为 PDF 时可能会丢失某些格式。
例如，我在 Notepad++ 中的 Python 代码设置如下所示：
这只是为了说明，可以直接使用屏幕截图，这实际上可能是最简单的方法。有多种工具可以帮助进行屏幕捕获——可能需要“拼接”屏幕以获得更高分辨率的图像。
颜色方案当然是个人的，在编辑器的样式配置器中定义，它已经知道支持的语言，因此即使不知道语法也很难做出错误的格式。这里一般的排版规则应该起作用：颜色不要太多，字体一致，缩进，舒适的行距。
用于自定义语言定义的其他工具/插件也很常见，但需要语法知识。
在 HTML 中，有一个标签集 <code>...</code> 告诉阅读器/解释器绝对按字面意思对待内容。此外，<pre>...</pre> 的作用也差不多。作为一个经常需要排版公式、方程式和代码以进行发布的人，我也提倡使用 IMAGES 来执行此操作……将有问题的项目制作成 .gif 或 .jpg 或 .png。
另一个因素是代码传统上以 Courier 等宽字体或其他等宽字体呈现，因为它向读者发出信号或电报它不是正文。我赞成这种风格选择，我认为这很有意义。
在大多数“传统”排版系统中，相当复杂的数学方程式非常耗时……而且充满错误。