Имена переменных, которые содержат имена файлов? - PullRequest
3 голосов
/ 30 ноября 2008

Если у меня есть переменная, которая содержит полное имя файла (например, файла проекта), должно ли оно называться projectFile, projectFileName или projectPath? Или что-то еще?

Ответы [ 9 ]

7 голосов
/ 30 ноября 2008

Я обычно хожу с этим:

  • FileName только для имени файла (без пути)
  • FilePath только для родительского пути (без имени файла)
  • FileFullName для полного имени с путем

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

РЕДАКТИРОВАТЬ: мои мысли об этих конкретных соглашений об именах таковы:

  • Интуитивно, «Имя» - это строка, как и «Путь» (и «Имя файла»)
  • a «Имя» является относительным, если это не «FullName»
  • имена связанных переменных должны начинаться с того же префикса («Файл» + ...), я думаю, что это улучшает читабельность
  • конкременты / свойства разветвляются вправо: «Файл» -> «Имя файла»
  • специализации имеют разветвление слева: «FileName» -> «ProjectFileName» (или «ProjectFileFullName»)
  • a «Файл» - это объект / дескриптор, представляющий физический объект, поэтому «ProjectFile» не может быть строкой

Я не всегда могу придерживаться этих соглашений, но я стараюсь. Если я решил использовать конкретный шаблон именования, я согласен, даже если это означает, что мне нужно написать более описательные (= более длинные) имена переменных. Код чаще читается, чем пишется, поэтому небольшая дополнительная печать не беспокоит меня слишком сильно.

2 голосов
/ 30 ноября 2008

System.IO.Path, по-видимому, ссылается на полное имя файла как path, имя самого файла как filename, а содержащий его каталог - directory. Я бы предположил, что в вашем случае projectPath наиболее соответствует этой номенклатуре, если вы используете в контексте System.IO.Path. Затем я бы назвал имя файла fileName, а каталог с ним - parentDirectory.

1 голос
/ 30 ноября 2008

Обратите внимание, что « имя файла » это одно слово на английском языке! Нет необходимости использовать заглавную букву «n» в середине идентификатора.

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

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

1 голос
/ 30 ноября 2008

Некоторые мысли:

  • projectFile может не быть строкой - это может быть объект, представляющий проанализированное содержимое файла.
  • projectFileName может быть не полностью квалифицированным. Если файл на самом деле "D:\Projects\MyFile.csproj", то он может содержать "MyFile.csproj".
  • projectPath может рассматриваться как полный путь к файлу или как имя родительской папки, содержащей файл.
  • projectFolder может считаться хранящим имя родительской папки, или это может быть реализация некой абстракции Folder в коде.

.NET иногда использует path для ссылки на файл, а иногда использует filename.

1 голос
/ 30 ноября 2008

Не думаю, что по этому поводу есть консенсус, просто постарайтесь быть последовательным.

Примеры из .NET Framework:

  • FileStream (путь строки ...);

  • Assembly.LoadFrom (строка assemblyFile)

  • XmlDocument.Load (строка имени файла)

Даже регистр имени файла (filename / fileName) несовместим в рамках, например ::

  • FileInfo.CopyTo (строка destFileName)
1 голос
/ 30 ноября 2008

Вы должны озаглавить его после файла, который он может содержать, то есть:

system_configuration_file_URI
user_input_file_URI
document_template_file_URI

«файл» или «имя файла» в большинстве случаев бесполезны

Кроме того, «файл» может означать «Я являюсь точкой файла», что является неоднозначным, «имя файла» не указывает, имеет ли он контекст (то есть: каталоги), fileURI является контекстно-однозначным, поскольку говорит «это идентификатор ресурса, который при наблюдении указывает на ресурс (файл) "

0 голосов
/ 30 ноября 2008

Это зависит от соглашений об именах, используемых в вашей среде, например, в Python ответ будет projectpath из-за соглашений об именах модуля os.path .

>>> import os.path
>>> path = "/path/to/tmp.txt"
>>> os.path.abspath(path)
'c:\\path\\to\\tmp.txt'
>>> os.path.split(path)
('/path/to', 'tmp.txt')
>>> os.path.dirname(path)
'/path/to'
>>> os.path.basename(path)
'tmp.txt'
>>> os.path.splitext(_)
('tmp', '.txt')
0 голосов
/ 30 ноября 2008

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

0 голосов
/ 30 ноября 2008

Все это частично зависит от размера метода и от того, являются ли переменные переменными класса.

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

Если это небольшой служебный метод, который, скажем, удаляет файл, не называйте его "projectFileName". Назовите его просто «имя файла».

Я никогда бы не назвал бы его "путь", поскольку это подразумевает, что он ссылается на папку , в которой он находится.

Называть его "файл" было бы нормально, , если бы не было и другой переменной, такой как "fileID" или "filePtr".

Итак, я бы использовал «папку» или «путь», чтобы определить каталог, в котором находится файл.

И «fileID» для представления объекта файла.

И, наконец, «имя файла» для фактического имени файла.

Happy Coding,
Randy

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...