"A", "an" і "the" у назвах методів та функцій: що ви приймаєте? [зачинено]

Я впевнений, що багато хто з нас в той чи інший момент бачили такі назви методів:

• UploadTheFileToTheServerPlease
• CreateATemporaryFile
• WriteTheRecordToTheDatabase
• ResetTheSystemClock

Тобто назви методів, які також є граматично правильними англійськими реченнями, включають зайві слова виключно для того, щоб вони читалися як проза. Особисто я не є великим прихильником таких "буквальних" назв методів, і вважаю за краще бути чіткими, все ще будучи максимально зрозумілими. Для мене такі слова, як "a", "an" та "the", просто виглядають незручно в назвах методів, і це робить назви методів зайвими довгими, не додаючи нічого корисного. Я вважаю за краще такі назви методів для попередніх прикладів:

• UploadFileToServer
• CreateTemporaryFile
• WriteOutRecord
• ResetSystemClock

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

Отже, ви перебуваєте в таборі "назви методів, які читаються як проза" чи "назви методів, які говорять про те, що я маю на увазі, але читаються вголос, як поганий переклад з іноземної мови на англійський"?

Я погоджуся, що прозові методи смокчуть за одним винятком:

Одиничні тестові випадки

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

• Додавання ACustomerOrderFailWhenCustomersIdIsInvalid: Failed
• OutOfBoundsPriceReturnsAnError: Пройдено
• CanDeleteAnEventFromASeason: Пройдено

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

Перефразовуючи Лоуренса з офісних приміщень ...

Ні, ні.

Такі "довгі" імена не звучать як проза . Коли вони наодинці - можливо, але у супроводі решти коду, вони просто заважають. Перевір:

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Юууук! ..

Це не дійсний англійський текст, і жодна мова програмування не буде виглядати як одна. Тож немає сенсу витрачати байти на статті.

З точки зору програмістів, "UploadFileToServer" має більше сенсу і легше читати та розуміти, ніж "UploadTheFileToTheServerPlease".

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

З огляду на те, скільки помилок у моєму житті я би закінчив

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

Серйозно, я навіть хотів би поглянути на те, яким було і ім’я мого класу. Якби мій клас називався «Файл», я, мабуть, просто пішов би

*UploadToServer
*DownloadFromServer

Так було б

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

Просто тривіальний приклад, але, сподіваємось, це досить наочно.

Мені особисто все одно. Я бачив їх, і вони мене не турбують. Я навіть не думав про них, поки інший програміст не роздував про них. Мені здається шокуючою, що хтось так піклується про щось, що так мало має значення. Я маю на увазі, що він насправді сердився на це. Але це було на початку моєї кар'єри, приблизно 11 років тому, і з тих пір я виявив, що розробники гніваються на незначні речі насправді досить поширені. Саме тому менеджерам розробників так добре платять. Вони мають стикатися з розробниками щодня.

І я вважаю за краще це, ніж "UL_FlToSrv".