Должен ли программист брать уроки написания, чтобы повысить выразительность кода?

15

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

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

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

Хосе Фаэти
источник
2
Было бы неплохо, если бы люди научились четко писать после достижения возраста 18 лет, особенно когда они используют иностранный язык (как в случае с ИТ). Вопрос в том, существует ли метод обучения, который мог бы достичь хороших результатов за относительно короткое время. Я помню, когда я впервые поступил в университет, мне дали курс по научному английскому, я думаю, это мне немного помогло (да, раньше я писал хуже, чем это :)).
NoChance
1
Что такое «выразительность кода»? Я так понимаю, это нечто иное, чем выразительность языка программирования , потому что никакие уроки письма не изменят это ...
Андрес Ф.
1
blog.codinghorror.com/recommended-reading-for-developers -> См. Code Complete 2. Лучшая книга «Как правильно писать код», которую я когда-либо читал.
Мачадо
1
@JoseFaeti, тогда у вас хороший вкус в книгах, сэр. :-) Бесконечные страницы, обсуждающие, как правильно написать утверждение «если»? Посчитай меня. :-)
Мачадо

Ответы:

25

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,

  • Попросив более опытного разработчика пересмотреть ваш код,

  • Понимание моделей и как и когда их использовать.

Арсений Мурзенко
источник
+1 хороший ответ. Будучи выразительным и лаконичным является очень важным, но пишущие уроки не может быть наилучшим образом использовать время обучения. Сознательное стремление написать очевидный код с самоописанием - это то, что должен делать каждый, и я думаю, что все остальное просто встает на свои места без необходимости в реальных уроках.
Даниэль Б
Там есть документация, электронная почта, ... а также код - письменная часть общения с вашими коллегами, боссами, пользователями, будущим я и т. Д. Но, пожалуйста, никакой поэзии.
Steve314
Я понял. На самом деле, я больше думал об использовании предметно-ориентированных языков. Я достиг точки, когда я чувствую себя более комфортно в программировании на предметно-ориентированном языке вместо использования базового синтаксиса языка программирования общего назначения. Это делает ваш код более понятным и понятным даже для непрограммистов. Мне было интересно, было ли это из-за моего плохого словарного запаса английского языка, отсюда и мысль о написании уроков.
Хосе Фаети
В целом хороший ответ, но я видел фигуры речи в коде. Например, одна из немногих полезных функций PHP состоит в том, что все его функции поиска / поиска ищут иголки в стоге сена.
user949300
@ user949300: и это одна из причин, почему я так ненавидел PHP. Будучи не носителем английского языка, я не знал соответствующего выражения, и для меня эти термины были очень полезны. Сравните это с C # sequence.Contains(element)или с отличным Python element in sequence. Так что нет, фигурам речи не место в API.
Арсений Мурзенко
11

должен программист брать уроки письма, чтобы написать лучший код?

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

Это не значит, что программисты не должны брать уроки письма. Им следует! Несколько причин:

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

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

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

Калеб
источник
В этом-то и дело. Даже если ваш код не обязательно будет лучше, вы станете лучше, особенно в общении с другими программистами или коллегами. Я думаю, мой вопрос должен был быть сформулирован по-другому :)
Хосе Фаети
2
Очень это. Умение хорошо писать прозу - ключевой навык для любого профессионала
Захари К,
6

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

Литературное понятие выразительности не совпадает с понятием выразительности программирования. Во многих случаях неоднозначность в языке может использоваться в качестве литературного устройства, даже в научной литературе, в форме, которая увеличивает выразительность, потому что она вызовет различные культурные, лингвистические и символические ассоциации в читателе, как предназначенные, так и непреднамеренные. Этот вид выразительности не желателен в программировании; абстракция более ценна, чем двусмысленность. В программировании абстракция повышает гибкость, возможно, с некоторыми затратами на когнитивную нагрузку. Абстракция в литературной форме может иметь противоположный эффект, который она имеет в программировании: чем более абстрактно ваше письмо, тем более вероятно, что читатель будет воспринимать, что вы ничего не говорите. Все те символы и ассоциации, которые являются результатом конкретной речи, имеют ценность,

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

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

Изучение вещей вне вашей основной области имеет смысл, потому что любопытные люди делают лучше разработчиков, чем люди, которые этого не делают.

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

JasonTrue
источник
+1: «Мой код все больше зависит от создания общего словаря между бизнесом и технической командой.»: Очень важный момент! Многие ошибки возникают из-за недопонимания, потому что аналитики и разработчики используют определенный термин для двух разных вещей.
Джорджио
4

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

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

GlenPeterson
источник
Спасибо, я стараюсь изо всех сил! На самом деле я дошел до того, что синтаксиса языка программирования общего назначения недостаточно для самовыражения при кодировании. Сейчас я программирую инструменты препроцессора для улучшения синтаксиса языка и реализации специфичных для предметной области языков для того же вопроса, что, возможно, лучше, чем пытаться навязать выразительность в языке программирования общего назначения.
Хосе Фаети
3

Как писатели учатся читать классику мира, так и программисты учатся читать хороший код. Но есть одна маленькая проблема. Хотя в литературе есть признанные гиганты, их мало в программировании. И если они есть, они могут «говорить» на другом языке. (Я даже не уверен, что разумно советовать читать исходный код Minix от Tanenbaum)

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

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

superM
источник
2

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

Еще лучше попросить друга, который знаком с программированием, прочитать ваш код, не сказав ему, что он делает.

Элиот Болл
источник
0

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

и обратите внимание, что «читаемый» код является субъективным и, прежде всего, связан с синтаксическим стилем и общими идиомами (которые различаются в зависимости от языка и даже команды)

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

рецензирование может помочь вам построить словарный запас и уверенность

Стивен А. Лоу
источник
0

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

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

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

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

Но оба типа письма требуют мастерства.

MoonLightning
источник
-1

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

Раджеш Сингх
источник
4
Монотонная рутина программирования, возможно, будет лучше решена путем изменения карьеры, чем путем написания уроков.
Элиот Болл