Что нужно и что нельзя делать с файлами

Question

Я готовлю лекцию по файлам для младших школьников в классе программирования. Один из моментов, которые я хочу уточнить, - это хорошие практики с файлами.

Что следует иметь в виду при использовании файлов на любом языке программирования?

Answer 1

• Можно считать, что файлы содержат набор записей , каждая из которых фиксированной длины или заканчивается разделителем .

• Файлы обычно оптимизированы для последовательного доступа , а не произвольного доступа . Трудно вставить данные в середину файла, и, как правило, быстрее обрабатывать файлы линейно (например, на кассете), чем случайным образом (например, компакт-диск в режиме «перемешивания»).

• Файлы с произвольным доступом обычно содержат записи фиксированной длины, большинство из которых содержат пустое пространство, что делает их больше, чем файлы с последовательным доступом.

• Файлы - темпераментные и непредсказуемые существа. Они могут изменять длину, исчезать, изменять права доступа, и т. Д. . между доступами, поэтому тщательно проверяйте ваших операций и проверяйте коды возврата .

• Файлы могут использоваться как буферы , если вы читаете с начала (хвост) и пишете до конца (голова).

• Очистите свои буферы!

Поскольку еще ни у кого не было плохого вкуса сказать это: это должно помочь вашим студентам разобраться в предмете.

Answer 2

Я обнаружил, что начинающие программисты часто имеют слабую интуицию или усваивают неправильные уроки о скорости доступа к файлам.

Очень новые программисты предполагают, что файлы очень быстрые и нуждаются в помощи, чтобы понять, почему чтение одного байта за раз из небуферизованного файла - плохая идея. Точно так же доступ к информации каталога может быть очень медленным и должен быть кэширован, если это возможно.

К сожалению, некоторые более опытные программисты усваивают неправильный урок и предполагают, что все всегда должно кэшироваться в ОЗУ, иначе это будет слишком медленно. Современные операционные системы имеют очень сложные дисковые кэши, поэтому второй раз, когда вы обращаетесь к одной и той же части файла, может быть значительно быстрее.

Наконец, интерактивные программы должны выполнять все файловые операции в другом потоке, чтобы ваше приложение не замедлялось до сканирования и не прекращало работу, когда диск занят или когда удаленный том временно недоступен.

Answer 3

Всегда монтируйте обезьяну-царапину.

http://catb.org/jargon/html/S/scratch-monkey.html

Answer 4

• Не очищайте после каждой записи.
• не беспокойтесь о небольших записях и чтениях. ОС довольно хороша в их буферизации. Не пытайтесь заново изобрести свой собственный буферный сценарий. в лучшем случае это ничего не даст. наихудшее, что оно действительно будет работать против буферизации ОС.
• не создавайте каталоги с тысячами файлов.
• Если есть изменение, человек захочет посмотреть или отредактировать данные. убедитесь, что он читается человеком.
• Прежде чем рассмотреть возможность использования собственного формата, рассмотрим XML.

Answer 5

В Vista есть новые функции разрешений в каталоге программ, поэтому программы, создающие файлы, могут иметь проблемы при установке в Vista (легко исправить, но все равно раздражает).

Answer 6

Если вы пишете серверный или параллельный код, обратите пристальное внимание на блокировку файлов: слишком мало, и вы будете иметь повреждение данных, слишком много, и ваше приложение заблокируется.

Answer 7

Do:

• Удалить временные файлы, когда нет дольше они нужны

Не

• Не создавать случайные файлы в пользователе каталоги (например, My Документы). Использовать временную / программу папка для этого
• Не хранить конфиденциальную информацию в текстовых файлах

Answer 8

Всегда закрывайте файл и утилизируйте все ресурсы, когда закончите с ними.

Используйте чтение двоичных файлов в двоичных файлах и чтение текстовых файлов. (Не могу вспомнить, сколько раз я помогал людям, чей код не прочитал весь файл, потому что они читали двоичный файл с текстовой конструкцией, а в середине файла оказалось ^ Z). *

Answer 9

Файл всегда небезопасен

Как и любой другой ввод, файлы могут увеличивать риски безопасности. Кроме того, он может быть поврежден либо потому, что он был создан устаревшим приложением, либо потому, что конечный пользователь попытался изменить их сам.

Либо полностью игнорируйте такой файл, либо получите столько, сколько сможете, и отбросьте остальные.

Answer 10

Не забудьте закрыть их, когда вы закончите с ними.