• Если возможно, следует использовать менее 80 символов в строке. Это позволит просматривать данные в терминальном окне обычного размера. Если многие записи должны содержать более 80 символов, то следует обратить внимание на формат с использованием строф (см. ниже).
• Использовать символ # как начало комментария. Полезно иметь способ внедрения замечаний и комментариев в файлы данных. Еще лучше, если они фактически являются частью структуры файла и поэтому будут сохраняться инструментами, которые распознают формат данного файла. Для комментариев, которые не сохраняются во время синтаксического анализа, знак # является стандартным начальным символом.
• Следует поддерживать соглашение об использовании обратной косой черты. Наименее неожиданный способ поддержки непечатаемых управляющих символов заключается в синтаксическом анализе еэсаре-последовательностей с обратной косой чертой в стиле С: \n для разделителя строк, \r для возврата каретки, \t для табуляции, \b для возврата на один символ назад, \f для разделителя страниц, \е для ASCII-символа escape (27), \nnn или \onnn, или \Onxm для символа с восьмеричным значением nnn, \xnn для символа с шест-надцатеричным значением пп, \dnnn для символа с десятичным значением nnn, \ \ для буквального использования обратной косой черты. В более новом, но заслуживающем внимания соглашении последовательность \unnnn используется для шестнадцатеричного Unicode-литерала.
• В форматах с использованием одной строки для одной записи в качестве разделителя полей следует применять двоеточие или серию пробелов. Соглашение об использовании двоеточия, вероятно, возникло вместе с файлом паролей Unix. Если поля должны содержать экземпляры разделителя (или разделителей), то следует использовать обратную косую черту как префикс для буквального представления этих символов.
• Не следует делать важными различия между символами табуляции и пробелами. Это может привести к серьезным проблемам, в случае если настройки табуляции в пользовательских редакторах отличаются. В более общем смысле они препятствуют правильному зрительному восприятию. Использование одного символа табуляции в качестве разделителя полей особенно чревато возникновением проблем. С другой стороны, хорошая практика допускает использование любой последовательности символов табуляции и пробелов в качестве разделителя полей.
• Шестнадцатеричное представление предпочтительнее восьмеричного. Шестна-дцатеричные пары и четверки проще для зрительного преобразования в байты и современные 32- и 64-битовые слова, чем восьмеричные цифры, состоящие из трех битов каждая. Кроме того, этот подход несколько более эффективен. Данное правило необходимо подчеркнуть, поскольку некоторые старые средства Unix, такие как утилита od(1), нарушают его. Это наследие связано с размерами полей команд в машинных языках для давних мини-компьютеров PDP.
• Для сложных записей рекомендуется использовать формат со "строфами": несколько строк в записи, причем записи разделяются строкой, состояний из последовательности %%\п или %\п. Разделители создают удобные видимые границы для визуального контроля файла.
• В форматах со строфами следует использовать либо одно поле записи на строку, либо формат записей, подобный заголовкам электронной почты RFC 822, где поле начинается с отделенного двоеточием ключевого слова (названия поля). Второй вариант целесообразно использовать, когда поля часто либо отсутствуют, либо содержат более 80 символов, или когда плотность записей невысока (например, часто встречаются пустые поля).
• В форматах со строфами следует обеспечивать поддержку продолжения строк. В ходе интерпретации файла необходимо либо игнорировать обратную косую черту с последующим пробелом, либо интерпретировать разделитель строк с последующим пробелом эквивалентно одному пробелу так, чтобы длинная логическая строка могла быть свернута в короткие (легко редактируемые) физические строки. Также существует соглашение, рекомендующее игнорировать завершающие пробелы в таких форматах. Данное соглашение защищает от распространенных ошибок редакторов.