«A», «an» и «the» в именах методов и функций: что вы думаете? [закрыто]

Я уверен, что многие из нас видели такие имена методов в тот или иной момент:

• UploadTheFileToTheServerPlease
• CreateATemporaryFile
• WriteTheRecordToTheDatabase
• ResetTheSystemClock

То есть имена методов, которые также являются грамматически правильными английскими предложениями и включают в себя дополнительные слова исключительно для того, чтобы они читались как проза. Лично я не большой поклонник таких «буквальных» имен методов и предпочитаю быть лаконичными, но при этом быть максимально ясным. Для меня такие слова, как «a», «an» и «the», выглядят просто неуклюже в именах методов, и это делает имена методов излишне длинными без реального добавления чего-либо полезного. Я бы предпочел следующие имена методов для предыдущих примеров:

• UploadFileToServer
• CreateTemporaryFile
• WriteOutRecord
• ResetSystemClock

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

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

Я согласен, что прозаические методы отстой за одним исключением:

Модульные тесты

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

• AddingACustomerOrderFailWhenCustomersIdIsInvalid: Failed
• OutOfBoundsPriceReturnsAnError: пройдено
• CanDeleteAnEventFromASeason: пройдено

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

Перефразируя Лоуренса из офисного пространства ...

Нет, нет, чувак, я верю, что если бы кто-то, с кем я работал, назвал функцию «UploadTheFileToTheServerPlease», он бы его ... ударил, чувак.

Такие «длинные» имена не звучат как проза . В одиночестве - возможно, но в сопровождении остальной части кода, они просто создают больше беспорядка. Проверьте это:

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Yuuuuk! ..

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

С точки зрения программистов, «UploadFileToServer» более понятен и легок для чтения и понимания, чем «UploadTheFileToTheServerPlease».

Больше, чем грамматика английского языка, читаемость и понятность важнее в программировании!

Учитывая, сколько опечаток в моей жизни, я бы в конечном итоге

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

Серьезно, я бы даже посмотрел на то, как назывался мой класс. Если бы мой класс назывался «Файл», я бы, вероятно, просто

*UploadToServer
*DownloadFromServer

Так было бы

   File file = new file;
   file.UploadtoServer(ServerAddress);

Просто тривиальный пример, но, надеюсь, это достаточно наглядно.

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

И я бы предпочел увидеть это, чем "UL_FlToSrv".