Что такое программный код, применение, ошибки

Имена переменных и выявление ошибок

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


Очень важно уделять большое внимание своевременному устранению ошибок. Что такое программный код, который исполняется идеально? Это код, в котором нет ошибок. То есть любое ветвление цикла или изменение переменной, или вовсе какие-либо непредвиденные действия пользователя, всегда приведут к ожидаемому результату

Это достигается за счёт тестирования готового программного продукта по несколько раз

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

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

Оптимизация имеет колоссальное значение для написания работоспособной программы, которая будет экономно использовать ресурсы компьютера и при этом не допускать ошибок выполнения программного кода. Что такое оптимизированная программа? Это продукт, который способен выполнять весь заявленный функционал, ведя себя при этом «тихо» и экономно.

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

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

DecodeIt. На самом деле на полноценная программа, а отдельный сайт. Сюда можно загрузить скриншоты с интересующим кодом и просмотреть, что в нём зашифровано. Не требует никакой установки и абсолютно бесплатен. Недостаток: требуется подключение к интернету.

В целом, на этом вопрос исчерпывается. Просто количество реально рабочих приложений крайне мало. Также следует отметить, что вариант с сайтом предпочтительнее. Почему загрузить установочный пакет с хостинга у CodeTwo в странах СНГ не удаётся.

Приложения для чтения QR-кода в браузере

При навигации по глобальной сети также можно столкнуться с QR. Можно установить приложения для браузера, которые помогут считывать такой контент при встрече. И тут выбор ещё меньше, чем для ОС.

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

Собственно, это единственное дополнение, которое читает, а не генерирует коды.

Совет 3. Не давайте переменным имена, способные ввести в заблуждение.

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

Один из основных способов достижения этой цели состоит в том, чтобы давать переменным, процедурам и т.д. хорошие, т.н. «говорящие» имена. Если упомянутый выше гипотетический читатель вашего кода, посмотрев на имя переменной, подумает: «Ага, я понимаю, что это такое», это сэкономит ему пять минут – ему не придется просматривать вашу программу на предмет объяснений, что, в конце концов, по мысли автора должно означать имя .

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

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

#define		MAX_ALIENS_ON_SCREEN_AT_ONCE		5

я, скорее всего, написал бы следующее:

#define		MAX_NUM_ALIENS		5

Любое недоразумение, обусловленное более коротким именем, будет устранено очень быстро, а «читаемость» кода улучшится.

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

// Переместить всех инопланетян
for (short i  = 0; I < MAX_NUM_ALIENS; i++)
	if (aliens.exists()) // Существует ли этот инопланетянин 
	                        // в данный момент времени?
		aliens.move_it();

Обратите внимание, что массив для всех инопланетян так и называется –. И это очень хорошо

Данное имя передает именно то, что я хотел сказать, однако при этом оно достаточно короткое, чтобы я мог ввести его с клавиатуры тысячи раз и не сойти при этом с ума. По всей вероятности, вы будете использовать этот массив ОЧЕНЬ ЧАСТО. Если вы назовете этот массив , ваш программный код станет на десять миль длиннее и настолько же непонятнее.

Кроме того, параметру цикла я без каких-либо дополнительных комментариев дал простое имя . Если вы только начали осваивать стратегию описательного именования переменных, у вас может возникнуть искушение дать этой переменной «говорящее» имя counter (счетчик) или что-то вроде этого. Это совсем не обязательно. Цель именования переменной состоит в том, чтобы немедленно вызвать у читателя реакцию: «Ага, я знаю, что это значит». Если я дам этой переменной имя i, j и т.д., любой читатель сразу поймет, что это параметр цикла. Каких-либо дополнительных разъяснений не требуется.


Несомненно, к именованию переменных можно относиться гораздо серьезнее. Например, существует т.н. венгерская нотация. Эта концепция имеет множество вариантов, однако ее основная идея состоит в том, что каждое имя переменной должно начинаться с префикса, указывающего на тип этой переменной. (Например, все переменные типа unsigned long variable должны начинаться с префикса и т.д.). На мой взгляд, это уже перебор, однако вам надо знать о существовании и такого варианта. Можно потратить достаточно много времени на то, чтобы сделать вещи понятнее, однако решение этой задачи также требует определенных усилий.

Качество

В отличие от человека, для компьютера нет «хорошо написанного» или «плохо написанного» кода. Но то, как написан код, может сильно влиять на процесс сопровождения ПО. О качестве исходного кода можно судить по следующим параметрам:

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

Выделяй методы

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

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

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

Компьютерный код

Скрыть рекламу в статье

Компьютерный код

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

Ответ на этот вопрос очень прост. Все операции компьютер выполняет в кодированном виде, не используя хорошо нам знакомых букв и цифр. То есть компьютеры работают и общаются между собой на специальном кодированном языке. Этот язык называется бинарным кодом и состоит из двух цифр, 1 и 0, называемых битами. Определенные сочетания 0 и 1 используются вместо известных нам цифр от О до 9. Компьютер преобразует в бинарный код и буквы в соответствии со специальными правилами. Каждому знаку, который имеется на клавиатуре компьютера, в том числе знакам препинания и символам, соответствует свое семизначное число в двоичном коде. Так, например, заглавной букве «А» английского алфавита соответствует число 1000001, малой букве «а» — число 1100001, восклицательному знаку — число 0100001, а символу & — число 0100110 в бинарном коде.

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

Многие люди уверены, что компьютеры были придуманы недавно. Однако в действительности скоро они будут праздновать свой 200-й день рождения.

Первый компьютер, который назывался Differece Endine № 1, сконструировал английский изобретатель и математик, а также известный разгадыватель шифров Чарльз Бэббидж (Charles Babbage, 1791–1887). И было это еще до восстания декабристов в России, а именно в 1823 году. Его машина представляла собой сложный механизм, который мог выполнять сравнительно сложные математические расчеты и состоял из 25 000 деталей. Стоил этот аппарат 17 470 фунтов стерлингов, что по тем временам представляло просто астрономическую сумму.

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

Рис. 2.7 Внешний вид машины Ч. Бэббиджа

Следующий шаг вперед в развитии компьютерной техники произошел более чем через 100 лет. В 1937 году Алан Тюринг (Alan Turing, 1912–1954), прославившийся разгадкой секретов немецкой шифровальной машины «Энигма», написал известную научную работу, в которой привел описание занимательной машины. Эту машину можно было запрограммировать так, чтобы она отвечала на любой вопрос, который требует логического мышления. Автор без лишней скромности назвал ее «Универсальная машина Тюринга». Через шесть лет его машина была построена, поскольку была необходима в условиях войны.

Через несколько месяцев один из сотрудников, Макс Ньюман (Max Newman), предложил построить на основе универсальной машины Тюринга более мощный аппарат. И такая машина была создана. Благодаря своим сравнительно огромным размерам она получила название «Колосс». «Колосс» был построен на 1500 радиоэлектронных лампах, а программировался с помощью перфорированной ленты.

Следует отметить, что вся информация, касавшаяся «Колосса», англичанами хранилась в строжайшей тайне. В результате после окончания войны в 1945 году машина была уничтожена, а ее чертежи сожжены.

Поэтому долгое время считалось, что первым компьютером был так называемый ENIAC (Electronic Numerical Integrator And Calculator), сконструированный в 1945 году специалистами Пенсильванского университета в американской Филадельфии. Этот компьютер имел 18 000 электронных ламп и за секунду мог выполнить 5000 операций. В США компьютер ENIAC считают прародителем всех современных компьютеров.

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

Оглавление книги

Как научиться?

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

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


Вполне вероятно, что задача, с которой вы столкнулись, уже решена и это решение где-то лежит. Иногда разобраться с тем, как оно работает, сложнее, чем написать заново. Это стандартная программистская проблема, но для этого у нас есть Stack Overflow, одно из главных изобретений человечества в сфере программирования. Это сайт, где разработчики делятся опытом и отвечают на вопросы друг друга. У каждого участника свой уровень репутации, все очень удачно спроектировано, поэтому на простые вопросы можно получить ответ в течение десяти секунд. Это очень помогает. В современном мире вы не просто пишете программу — вы одновременно используете огромное количество программ и инструментов, уже созданных другими людьми.

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

Самый лучший способ что-то понять — найти работающий кусок кода, начать его модифицировать и изучать, что получится. Это нужно сделать после того, как вы разобрались с базовым синтаксисом. Подгоняйте код под свои задачи или просто экспериментируйте.

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

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

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

Есть мнение, что на фоне развития искусственного интеллекта и машинного обучения программисты скоро будут не нужны: компьютеры сами научатся себя программировать. Но мне кажется, что это не так. До тех пор, пока есть задачи и пока нужно объяснять, как их решать, программирование будет существовать. Безусловно, программирование сильно эволюционирует, за последние 20 лет оно изменилось очень сильно. Но от того, что компьютеры стали умнее, разработчиков меньше не стало — наоборот, их стало гораздо больше. И мне кажется, что дальше будет происходить то же самое.

Качество кода

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

  • Читаемость кода. Одного взгляда на него должно хватать, чтобы обобщенно понять, что реализуется участком кода.
  • Присутствие понятных и ёмких комментариев. Данный параметр очень сильно влияет на читаемость, легкость в отладке, тестирование поддержки и устранение ошибок программного кода.
  • Низкая сложность.
  • Оптимизация кода. Организовать его стоит таким образом, чтобы программа использовала как можно меньше системных ресурсов, таких как память, время процессора и пространство жёсткого диска.
  • Отсутствие мусора. То есть не используемых переменных или блоков кода, в которой никогда не заходит управление программой.

Используй комментарии в коде

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

Пример плохого комментария

Однако, у комментариев есть и отрицательные стороны. Главной из которых я считаю то, что комментарии имеют свойство устаревать, в отличие от кода. Многие программисты забывают или просто ленятся актуализировать комменты после изменения кода, что может ввести программиста в заблуждение. Кроме того, комментарии засоряют код значительно увеличивая его в объеме. Ну и здесь есть еще психологический фактор для программиста: «зачем писать легко читаемый код с хорошими именами переменных и методов, если можно нафигачить комментов?»

Поэтому могу дать следующие по использованию комментариев:

1. Для объяснения интерфейсов методов (что делает метод, входные и выходные параметры, возможные исключения)

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

2. Для разъяснения зачем нужен кусок кода

3. Для удаление ненужных участков кода

Очень спорный вариант. Для хранения устаревших вариантов кода всегда используй систему контроля версий (git, tfs, svn). Но в редких случаях для отладки или для переключения между различными конфигурации можно комментировать некоторые строки, чтобы разобраться, что да как. Но этого нужно избегать.

Также возможно использование комментариев для временных решений и костылей ))) Но потом нужно не забыть исправить на правильную и качественную реализацию. Это обязательно! Оформление кода — это не только красота, но и поддержание качества проекта в целом.

4. Для разъяснения паттерна или алгоритма

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

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

Тренажёры для простого программирования

Яндекс.Практикум. Это наш род­ной тре­на­жёр, где тебя поша­го­во про­во­дят от пер­вой строч­ки до неболь­шо­го рабо­та­ю­ще­го про­дук­та, с пояс­не­ни­я­ми и интер­ак­ти­вом. Есть тре­на­жё­ры для веб-программирования, бэкен­да, а так­же ана­ли­ти­ки и тести­ро­ва­ния. Всё на рус­ском. Бес­плат­ной вер­сии хва­тит, что­бы понять — нра­вит­ся вам это направ­ле­ние или нет.

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


Code Academy (на самом деле CodeCademy, но что?). Похо­же на Прак­ти­кум, толь­ко на англий­ском. Из осо­бен­но­стей — поме­сяч­ная опла­та за доступ к мате­ри­а­лам кур­сов.

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

Совет 4. Проверяйте свою программу на наличие ошибок. Вы ведь делаете ошибки. Да-да, именно вы.

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

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

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

Void change_score(short num_points)
{
	score += num_points;

	make_sparkles_on_score();
}

Пока все идет нормально. Теперь задайте себе вопрос: «Что в этом коде может быть не так?»

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

Этот пример был достаточно простым. Существует и менее очевидная проблема (с которой я постоянно сталкиваюсь в своих играх). Что произойдет, если переменная будет равна нулю?

Это весьма правдоподобная ситуация. Не забудьте, что по окончании каждой волны мы даем игроку бонусные баллы в зависимости от скорости ее прохождения. Что произойдет, если игрок будет действовать слишком медленно и мы решим дать ему 0 баллов? Вполне вероятно, что, работая над своим кодом в 3 часа ночи, вы решите вызвать процедуру и передать ей значение 0.

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

Void change_score(short num_points)
{
	if (num_points < 0)
	{
		// Возможно появления сообщения о какой-либо ошибке
		return;
	}

	score += num_points;

	if (num_points > 0)
		make_sparkles_on_score();
}

Ну вот. Так гораздо лучше.

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

Если вы передаете массивы или указатели, вам ОБЯЗАТЕЛЬНО нужно предусмотреть выявление ошибок или плохих данных.

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

Этот подход экономит массу времени и заслуживает регулярного применения. Время – наш самый ценный ресурс.

НазначениеПравить

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

Другое важное назначение исходного кода — в качестве описания программы. По тексту программы можно восстановить логику её поведения

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

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

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

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

Исходный код — важнейший компонент для процесса портирования программного обеспечения на другие платформы. Без исходного кода какой-либо части ПО, портирование либо слишком сложно, либо вообще невозможно.

Заключение

Недавно я написал такой код на Elixir:

result = calculate_results()
Connection.close(conn)
result

Я тут же подумал о методе в Ruby, который помог бы мне переписать этот код:

calculate_result().tap do
  Connection.close(conn)
end

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

with result = calculate_results(),
     Connection.close(conn),
  do: result

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

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

Всё что я хотел вам сказать в этой статье: Пожалуйста, пожалуйста всегда думайте о других, когда пишите свой код.

Перевод статьи Kamil Lelonek: How to write code which others will understand?


С этим читают