Враховуючи, що програмісти є авторами і пишуть код, щоб висловити абстрактні думки та концепції, а хороший код повинен читати інші програмісти без труднощів і непорозумінь, чи повинен програміст брати уроки письма, щоб написати кращий код?

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

Я думаю, що це також може допомогти уникнути написання коду з більш ніж одним значенням, що часто є причиною непорозуміння між різними програмістами. Кодекс повинен завжди чітко виражати свою функцію однозначно.

1. Уроки письма? Не зовсім.

Написання вихідного коду досить відрізняється від написання книги.

Хоча обидва переслідують однакові цілі: будучи максимально однозначними і легко зрозумітими, вони роблять це зовсім по-різному, і речі, які повинен вивчити автор, не є такими ж, як речі, які повинен вивчити розробник програмного забезпечення.

Приклад 1: фігури мови

Цифри мови є цінними при написанні романів, віршів тощо, оскільки вони підвищують виразність написаного.

Який останній раз ви бачили оксиморон або літоту у вихідному коді ? Чи допомогло б це мати, або це було б надзвичайно шкідливим для будь-якого розробника, якому доведеться підтримувати такий вихідний код пізніше?

Приклад 2: словниковий запас

Багатий словниковий запас високо оцінюється в літературі. Лексика Вільяма Шекспіра, наприклад, становить двадцять тисяч до двадцяти п’яти тисяч слів. Багатій лексиці робить цікавіше читати роман чи вірш.

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

Зверніть увагу на важливий аспект: хоча Google Translate може бути корисною для мови, яка не є носієм мови, у будь-якого перекладача є дві проблеми:

• Пара мов не обов'язково має відповідати 1: 1 між словами. Деякі слова не мають жодного перекладу на інші мови, або декілька слів можуть перекласти на одне слово іноземною мовою. Наприклад, російською мовою є величезна кількість слів, націлених на конкретні стани снігу та холодної погоди, і перекласти їх французькою чи іспанською мовами, як правило, неможливо, не втрачаючи своєї специфіки.

• Слово іноді має кілька значень, а значення виводиться з контексту. Google Translate, незважаючи на високу якість, зазвичай не в змозі вказати значення для будь-яких, але найпростіших ситуацій.

Приклад 3: вирази

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

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

Наприклад, англійська мова не є моєю першою мовою, і я щодня зустрічаю вирази, в тому числі тут, на StackExchange, які я не знаю. Я намагаюся відгадати їх значення, а іноді маю рацію. Але іноді я помиляюся, і гугл цих виразів не допомагає.

Користувач у своєму коментарі нагадав мені приклад, який змусив мене довго страждати, коли я щойно розпочав програмування: голка та сіна PHP . Мені не було відомо про відповідну фігуру мови, тому щоразу, коли я читав документацію, мені було цікаво, що це таке. Зайве говорити, що C # sequence.Contains(element)або відмінний Python element in sequence- це набагато краща альтернатива. Ну, принаймні, розробники, які не знають івриту, теж повинні були страждати від PHP , але це вже інша історія.

Приклад 4: культурні посилання

Культурна література. У літературі заманливо включити елементи даної культури, і це теж робить книгу багатшою, а часом і цікавішою для читання.

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

Той самий користувач, який розповідав про голку та сіно, подав чудовий приклад такої культурної орієнтації: Грааль. Хто не знає, що таке Грааль? Ну, я маю на увазі, це "Graal" по-французьки, "Grial" по-іспанськи і ... "Kutsal Kâse" по-турецьки, але все ж. Однак наскільки американські чи європейські розробники знають середньовічну історію Китаю чи Індії? Чому хтось припускає, що кожен китайський та індійський програміст повинен знати посилання на Святий Грааль?

2. Уроки написання виразного вихідного коду? Звичайно.

• Будь-який розробник повинен навчитися писати виразний вихідний код.

• Будь-який розробник повинен пояснити, чому коментар у:

  int j = i + 1; // Creating i and adding 1 to it.
  

  це погано, навіть убік того, що це абсолютно неправильно.

• Будь-який розробник повинен мати можливість зрозуміти основний рефакторинг і як це допомагає зробити вихідний код більш виразним.

• Будь-який розробник повинен пам’ятати, що 20% часу витрачається на розробку коду, а 80% часу - на його підтримку. Для деяких проектів це більше як 5% - 95%.

• тощо.

По суті, програмування близьке до технічної документації. Чи потрібно людині, яка пише аркуш на болт, брати уроки письма? Не зовсім. Те саме стосується розробників. Будь-хто повинен писати, не роблячи орфографічних помилок у кожному слові, і будь-хто повинен мати можливість донести її ідеї досить чітко. Окрім цього, я не впевнений, як уроки письма були б кориснішими, ніж, скажімо, курс інформатики, інформатики та іншої безпеки.

Виразність вихідного коду можна дізнатися іншими способами. superM згадав про одну з них у своїй відповіді : читання хорошого коду. Я можу згадати кілька інших:

• Читання книг, таких як Beautiful Code або Code Complete,

• Попросивши досвідченішого розробника переглянути ваш код,

• Розуміння шаблонів, як і коли їх використовувати.

чи повинен програміст взяти уроки письма, щоб написати кращий код?

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

Це не означає, що програмісти не повинні приймати уроки письма. Вони повинні! Деякі причини:

• Писання - важливий навик для будь-якої освіченої людини. Ви будете здаватися розумнішими, якщо зможете добре писати.

• Незважаючи на свої зусилля, програмістам часто потрібно спілкуватися з іншими людьми, часто використовуючи написане слово.

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

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

Літературне поняття виразності не те саме, що програмування поняття виразності. У багатьох випадках неоднозначність у мові може бути використана як літературний пристрій, навіть у нехудожній літературі, у формі, що збільшує виразність, бо це спровокує у читача різні культурні, мовні та символічні асоціації, як задумані, так і ненавмисні. Цей вид виразності небажаний у програмуванні; абстракція цінніша за неоднозначність. У програмуванні абстракція збільшує гнучкість, можливо, з деякою вартістю когнітивного навантаження. Абстракція в літературній формі може мати протилежний ефект, який вона має в програмуванні: чим абстрактніше ваше письмо, тим більше шансів у читача сприйняти, що ви нічого не говорите. Усі ті символи та асоціації, які є результатом конкретної промови, мають значення,

Однак програміст - це не машина. Люди виграють часто несподіваними шляхами від інтелектуального та емоційного зростання. Поліпшення вашої писемності може призвести до більшої співпереживання клієнтів, оскільки ви змушуєте себе боротися з комунікаційними проблемами; можливо, ви відчуєте себе тим клієнтом, який каже те, що вони хочуть, тоді ви доставите це, і вони зрозуміють, що це не те, що їм потрібно. Можливо, ти просто навчишся зосереджуватися на тому, що залишилося без уваги.

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

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

Що я того вартий, я майже був спеціалістом з літератури; Я закінчила перехід на студії в Східній Азії, тому що мене більше цікавили заняття, які я проходив на цьому кафедрі. Є ймовірність, що я не міг би бути у цій галузі, якби я не вивчав східноазіатські студії, тому що побічний ефект вивчення японської мови зробив мене більш цінним у той час, коли програмна компанія найняла мене частково через знання мови. Мені все-таки довелося скласти більш глибокий спектр технічних навичок, але ненавмисні побічні ефекти навчання чому-небудь можуть зробити вас кращим, більш відповідним фахівцем з програмного забезпечення.

Коли програми програмування провалюються, це зазвичай відбувається через невдале спілкування, як правило, навколо вимог. Хоча посереднє розуміння англійської мови може бути достатнім для фактичного написання коду, для створення правильного коду важливим є хороший комунікатор. У цей вік віддаленого, текстового спілкування, англійська мова - це дуже важлива навичка спілкування.

Однак, ваше запитання написано дуже чітко і стисло - краще, ніж більшість програмістів, з якими я працював. Не бачивши свого коду, я б запропонував вам зосередитись на тому, щоб висловити себе на вибраній вами кодувальній мові. Для Java я рекомендую книгу Джошуа Блоха "Ефективна Java".

Як письменники вчать читати світові класики, так і програмістів навчають, читаючи хороший код. Але є одна маленька проблема. Хоча в літературі є визнані гіганти, їх мало в програмуванні. І якщо є, вони можуть "розмовляти" іншою мовою. (Я навіть не впевнений, що розумно радити читати вихідний код Minix від Tanenbaum)

Існує багато популярних способів зробити код більш читабельним (=> ремонтопридатним), наприклад, писати коментарі, давати змістовні імена тощо. Крім того, багато компаній встановлюють свої правила написання коду, і це робить все набагато простіше.

У будь-якому випадку, як і багато чудових письменників, програмісти ніколи не задоволені власним кодом. Тому знати, коли зупинитись так само важливо, як і написання коду якості.

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

Ще краще - попросити знайомого з програмуванням друга прочитати ваш код, не розповідаючи їм, що він робить.

Я не думаю, що це допоможе; креативне написання - це про сюжети та розвиток персонажа та діалог, а не про чітке вираження технічних концепцій. Технічне написання може допомогти, але я сумніваюся - це просто дуже різні види написання!

і зауважте, що "читабельний" код є суб'єктивним, і в першу чергу є питанням синтаксичного стилю та загальних ідіом (які різняться між мовами та навіть серед команд)

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

експертні оцінки можуть допомогти вам створити словниковий запас та впевненість

Існує велика різниця між написанням коду та написанням прози.

У прозі речення пов'язані (або відокремлені) часом (способом, яким вони слідують одне за одним, щоб досягти мети чи значення), але в (ефективному) коді ви можете (повторно) завантажувати частини «розповіді» з таблиць із повторюваними дії / відповіді. Отже, взаємодія з читачем (у прозі) або користувачем (кодом) зовсім інша.

Іншим способом написання «приємної» прози та написання «приємного» коду схожі: навчитися писати (код або прозу) - це процес, який передбачає багато помилок (або мислення / тестування щодо вдосконалень, або переформулювання), щоб отримати його » елегантний '.

Я думаю, хімічна періодична система елементів є елегантною, тому що вона дуже компактно описує основні властивості основних матеріалів, які ми використовуємо, трохи схожий на ефективний код, але це, звичайно, не проза. Жарт має багато прозових якостей (змусити вас до певного настрою, зберегти його настрій, а потім змінити його, коли це несподівано), але це шикарна практика кодування.

Але обидва типи писемності просять майстерності.

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