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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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