Поскольку мы определили messages как тип maybe , мы разрешаем ему быть null или undefined . Но это не даёт нам права проводить операции с ним (вроде.length или.map) без осуществления проверки на null , потому что если значение messages на самом деле null или undefined , то выскочит ошибка типа при попытке проведения операции с ним.

Так что вернёмся и обновим нашу функцию для просмотра примерно таким образом:

Const MyComponent = ({ messages, isFetching }: AppState) => { if (isFetching) { return } else if (messages === null || messages === undefined) { return

Преимущество № 7: Уменьшение количества юнит-тестов

Например, вернёмся к нашей функции calculateAreas с динамическими типами и обработкой ошибок.

Const calculateAreas = (radii) => { // Handle undefined or null input if (!radii) { throw new Error("Argument is missing"); } // Handle non-array inputs if (!Array.isArray(radii)) { throw new Error("Argument must be an array"); } var areas = ; for (var i = 0; i < radii.length; i++) { if (typeof radii[i] !== "number") { throw new Error("Array must contain valid numbers only"); } else { areas[i] = 3.14 * (radii[i] * radii[i]); } } return areas; };
Если бы мы были прилежными программистами, то могли бы подумать о тестировании недействительных передаваемых параметров для проверки, что они корректно обрабатываются нашей программой:

It("should not work - case 1", () => { expect(() => calculateAreas()).to.throw(Error); }); it("should not work - case 2", () => { expect(() => calculateAreas(undefined).to.throw(Error); }); it("should not work - case 2", () => { expect(() => calculateAreas("hello")).to.throw(Error); });
… и так далее. Но очень вероятно, что мы забудем протестировать какие-то граничные случаи, - и наш заказчик будет тем, кто обнаружит проблему. :(

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

С другой стороны, когда нам требуется установить типы:

Const calculateAreas = (radii: Array): Array => { var areas = ; for (var i = 0; i < radii.length; i++) { areas[i] = 3.14 * (radii[i] * radii[i]); } return areas; };
… мы не только получаем гарантию, что наша цель соответствует реальности, но такие тесты попросту надёжнее. В отличие от тестов на эмпирической основе, типы универсальны и их труднее обойти.

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

Преимущество № 8: Инструмент моделирования предметной области

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

Итак, сначала применим псевдонимы типов для трёх платёжных методов:

Type Paypal = { id: number, type: "Paypal" }; type CreditCard = { id: number, type: "CreditCard" }; type Bank = { id: number, type: "Bank" };
Теперь можно установить тип PaymentMethod как непересекающееся множество с тремя случаями:

Type PaymentMethod = Paypal | CreditCard | Bank;
Теперь составим модель состояния нашего приложения. Чтобы не усложнять, предположим, что данные приложения состоят только из платёжных методов, доступных пользователю.

Type Model = { paymentMethods: Array };
Это приемлемо? Ну, мы знаем, что для получения платёжных методов пользователя нужно сделать запрос к API и, в зависимости от результата и этапа процесса, приложение может принимать разные состояния. В реальности, возможно четыре состояния:

1) Мы не получили платёжные методы.
2) Мы в процессе получения платёжных методов.
3) Мы успешно получили платёжные методы.
4) Мы попытались получить платёжные методы, но возникла ошибка.

Но наш простой тип Model с paymentMethods не покрывает все эти случаи. Вместо этого он предполагает, что paymentMethods всегда существует.

Хм-м-м. Существует ли способ составить модель, чтобы состояние приложения принимало одно из этих четырёх значений, и только их? Давайте посмотрим:

Type AppState = { type: "NotFetched" } | { type: "Fetching" } | { type: "Failure", error: E } | { type: "Success", paymentMethods: Array };
Мы использовали тип непересекающегося множества для установки AppState в одно из четырёх состояний, описанных выше. Заметьте, как я использую свойство type для определения, в каком из четырёх состояний находится приложение. Именно это свойство type и является тем, что создаёт непересекающееся множество. Используя его мы можем осуществить анализ и определить, когда у нас есть платёжные методы, а когда нет.

Вы также заметите, что я передаю параметризованный тип E и D в состояние приложения. Тип D будет представлять собой платёжный метод пользователя (PaymentMethod , определённый выше). Мы не установили тип E , который будет нашим типом для ошибки, так что сделаем это сейчас:

Type HttpError = { id: string, message: string };
Теперь можно смоделировать предметную область приложения:

Type Model = AppState;
В целом, подпись для состояния приложения теперь AppState , где E имеет форму HttpError , а D - это PaymentMethod . И у AppState есть четыре (и только эти четыре) возможных состояния: NotFetched , Fetching , Failure и Success .

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

Более того, код документирует сам себя - достаточно посмотреть на непересекающиеся множества, и немедленно становится понятно, как структурирован AppState.

Недостатки использования статических типов

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

Вот некоторые из этих соображений:

Недостаток № 1: Статические типы требуют предварительного изучения

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

Изучение эффективного использования типов - это была половина успеха в изучении самого языка. В итоге, из-за статических типов кривая обучения Elm круче, чем у JavaScript.

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

Недостаток № 2: Можно увязнуть в многословии

Например, вместо этого:

Async function amountExceedsPurchaseLimit(amount, getPurchaseLimit){ var limit = await getPurchaseLimit(); return limit > amount; }
Нам приходится писать:

Async function amountExceedsPurchaseLimit(amount: number, getPurchaseLimit: () => Promise): Promise { var limit = await getPurchaseLimit(); return limit > amount; }
А вместо этого:

Var user = { id: 123456, name: "Preethi", city: "San Francisco", };
Приходится писать такое:

Type User = { id: number, name: string, city: string, }; var user: User = { id: 123456, name: "Preethi", city: "San Francisco", };
Очевидно, что добавляются лишние строки кода. Но есть парочка аргументов против того, чтобы считать это недостатком.

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

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

Сложно сказать, является ли многословность реальным аргументом против типов, но стóит держать его в уме.

Недостаток № 3: Требуется время для достижения мастерства в использовании типов

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

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

Недостаток № 4: Статические типы могут задержать быструю разработку

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

Дело не только в этом. Контролёры статических типов тоже не всегда идеальны. Иногда возникает ситуация, когда вы знаете что делать, а проверка типов вмешивается и мешает.

Уверена, что я упустила какие-то ещё недостатки, но это самые важные для меня.

Нужно использовать статические типы в JavaScript или нет?

Первыми языками программирования, которые я изучила, были JavaScript и Python, оба языка с динамической типизацией.

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

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

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

В конечном счёте, здесь нет универсального решения. Лично я предпочитают использовать статические типы при следующих условиях:

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

1. Код недолговечный и не является критически важным.
2. Вы делаете прототип и стараетесь продвигаться как можно быстрее.
3. Программа маленькая и/или простая.
4. Вы единственный разработчик.

Заключение

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

Веб-разработка

Vue.JS: особенности, преимущества и недостатки

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

Введение

Реализация web UI сталкивается со все более сложными задачами, требующими использования все более сложных инструментов. Добавим сюда тренд ухода от MVC архитектуры приложений и получим довольно интересную тенденцию. Современные разработчики стремятся использовать отдельные библиотеки под каждый слой задач. На фоне этих изменений появился и стал завоевывать популярность фреймворк Vue.JS.

Чисто теоретически он является альтернативой jQuery. Но в реальности Vue.JS довольно успешно конкурирует с React.JS — очевидным лидером в области View. Из современных популярных технологий, решающих схожие задачи можно также выделить Angular и Ember. У каждой из них есть свои преимущества и недостатки. Однако все эти фреймворки можно привести к одному общему знаменателю — относительная сложность освоения.

Особенности Vue.JS

Vue.JS создавался с оглядкой на лучшие практики перечисленных технологий. Из React.JS команда Vue позаимствовала идею виртуального DOM. Этот подход исключает прямое взаимодействие с узлами интерфейса. Изначальная работа ведется с его легковесной копией (virtual DOM). И только после этого изменения применяются к реальным узлам интерфейса. Параллельно происходит сравнение реального DOM дерева и его виртуальной копии. Таким образом выявляется разница и перерисовывается только то, что претерпело изменения.

Из Angular Vue.JS позаимствовал two-way data binding. Это позволяет проектировать интерфейсы: во-первых, декларативно; во-вторых, с использованием Vue в шаблонизаторах. Таких как Haml или Pug. Правда, отметим, что такой подход практиковался и раньше. Например, во фреймворке Knockout.JS.

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

Кроме того, Vue доступен ряд подключаемых модулей, реализующих современный подход к разработке веб-приложений. О чем речь? К примеру, практически все React приложения проектируются в тандеме с технологией контроля состояний Redux, которая является отдельной библиотекой и реализует flux-архитектуру. Подход, практикуемый библиотекой Redux оказался довольно удобным и успешным. Поэтому для Vue.JS была разработана своя технология контроля состояния приложения — Vuex. Vuex полностью заимствует идеи Redux, но степень интеграции этой библиотеки с Vue гораздо выше, чем в случае React и Redux. А это трансформируется в быстродействие и удобство.

Не стоит забывать и о том, что успешность технологии напрямую зависит от активности ее пользователей. То есть — сообщества разработчиков. Так React, являясь, пожалуй, самой популярной технологией, имеет огромное количество расширений основного функционала. Они создаются участниками сообщества, и у React разработчиков имеется инструментарий на все случаи жизни. У Vue.JS в этом плане дела не так хороши. Во всяком случае — пока. Впрочем, эта технология набирает обороты и уже имеет множество полезных библиотек, решающих большинство насущных проблем разработчиков.

Опыт использования на реальном проекте

Перед нами стояла задача разработки интерфейса, содержащего на одной странице карту, фильтры, результаты фильтрации и ряд элементов взаимодействия. Мы прекрасно понимали, что использование простого Vanilla JavaScript или jQuery может обернуться сложностями в разработке. Почему не React.js? Потому что Vue.JS проще и легковеснее. Зачем связываться с более “тяжелым” фреймворком для разработки одного-единственного интерфейса?

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

Вот небольшой пример инициализации Vue приложения.

В app.js создается переменная app как Vue объект. Конструктор проходится по шаблону template.haml и производит необходимые связывания.

Декларативность в Vue настолько проста, что это позволило нам интегрировать его в монолитное веб-приложение, использующее шаблонизатор Haml.

Здесь в зависимости от правдивости флага ‘filtersOpen’ к элементу добавляется или удаляется класс ‘rentbuy__filters—open’

Vue.JS помимо того, что реализует все современные подходы в разработке web UI, является невероятно легким в освоении, гибким и высоко интегрируемым со сторонними технологиями фреймворком. Шаблонизация Vue дала нам возможность связать элементы полей фильтра с полями одного-единственного объекта. А это позволило всегда иметь под рукой актуальные опции выбора, облегчило валидацию и очистку фильтра.

Здесь значения полей ввода привязываются к полям объекта ‘data’ с помощью двустороннего связывания. Это приводит к изменению поля объекта при изменении значения в поле ввода и наоборот.

Благодаря реактивности Vue.JS, мы избавились от дублирования кода. Как это произошло? В целом ряде случаев набор полей фильтра частично совпадал (в зависимости от состояния приложения). Возникла реальная угроза массового дублирования кода. Однако с помощью простых предикатов, определенных в шаблоне, можно быстро и удобно переключаться между наборами полей.

Здесь блок с полем для ввода виден на странице, когда выполняется условие

Также благодаря гибкости Vue.JS, нам удалось использовать преимущества компонентной разработки в элементах списка результатов фильтрации. Как вы помните, наш фреймворк практикует технологию виртуального DOM. Соответственно, с приходом новых результатов актуальные компоненты просто не перерисовываются. Что выливается в быстродействие и комфорт для пользователей.

Элементы из массива ‘properties’ рендерятся в виде Vue компонента ‘proposal’. Набор элементов на странице изменяется автоматически, согласно изменениям в массиве. Компонент ‘proposal’ представляет собой обыкновенный HTML шаблон, код которого заключен в тег script с типом ‘text/x-template’

Еще отметим, что Vue отслеживает жизненный цикл компонентов. То есть к ним можно применять какие-либо методы (изменение, удаление и т.д.) после инициализации и присоединения к DOM дереву. В частности, мы можем легко инициализировать приложение при загрузке страницы в браузере. Например, запросить начальную выборку элементов, в зависимости от текущего размера карты на странице пользователя.

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

Преимущества Vue.JS

Изучив ключевые особенности технологии и опробовав их на практике, мы можем перечислить основные преимущества фреймворка Vue:

• Библиотека довольно проста и функциональна. Для того чтобы разобраться в ней, нужен минимальный багаж знаний.
• Требования к стеку отсутствуют, поэтому Vue.JS можно использовать на любом проекте.
• Фреймворк совсем немного весит. Мы экономим время загрузки страниц и получаем целую кучу плюшек: плюс к конверсии, плюс к UX, плюс к поисковому ранжированию и т.д.
• Довольно высокая скорость разработки. Благодаря использованию любых шаблонов и доступности документации, большинство возникающих проблем решаются довольно быстро. В том числе по сравнению с React, так как в большинстве приложений, не имеющих сложных интерфейсов, вся мощь этого фреймворка является немного избыточной.
• Возможность найти и подключить к проекту практически любого разработчика, кто хоть немного знаком с фронтенд разработкой. Низкий порог вхождения позволяет работать с фреймворком, как фронтендщикам, так и бэкэндщикам.

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

Недостатки Vue.JS

Есть и минусы. В частности, по сравнению с React.JS.

• Работа над состоянием приложения происходит “под капотом”. В масштабных проектах это может вылиться в неочевидность работы компонентов, что зачастую создает проблемы с отладкой и эффективной разработкой.
• Компонентный подход во Vue.JS не так гибок и очевиден, как в React.
• Система рендеринга React более функциональна. Она предоставляет больше возможностей для отладки.
• Шаблонизация React значительно гибче (JS vs DSL).

Вывод

Vue.JS реализует все современные подходы к разработке web UI и является легким в освоении, гибким и высоко интегрируемым со сторонними технологиями фреймворком. Безусловно, в плане создания сложных интерфейсов (например, для корпоративных сайтов) React его превосходит. Но для решения относительно простых задач использование Vue выглядит не только оправданным, но и предпочтительным.

Статью подготовил

Отдел веб-разработки

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

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

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

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

Общая информация

Многие люди, даже не имеющие никакого отношения к IT-сфере, слышали слово Java . Революционный независимый от платформ язык, на котором активно пишут приложения для мобильных систем. Он был разработан перспективной компанией Sun , которая затем перешла «под крыло » Oracle . Но ни та, ни другая компании не имеют никакого отношения к JavaScript :

От Sun потребовалось лишь разрешение на использование части названия. Удивительно, но JavaScript вообще не принадлежит ни одной фирме.

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

• Объектно-ориентированность. Выполнение программы представляет собой взаимодействие объектов;
• Приведение типов данных проводится автоматически;
• Функции выступают объектами базового класса. Эта особенность делает JavaScript похожим на многие функциональные языки программирования, такие как Lisp и Haskell ;
• Автоматическая очистка памяти. Так называемая, сборка мусора делает JavaScript похожим на C# или Java .

Если говорить о сути применения JavaScript , то этот язык позволяет «оживлять » неподвижные страницы сайтов с помощью кода, который можно запустить на исполнение (так называемые, скрипты ). То есть, можно провести аналогию с мультфильмами, где html и css – это прорисованные герои, а JavaScript – это то, что заставляет их двигаться.

Если говорить о синтаксисе JavaScript , то ему присущи следующие особенности:

• Регистр важен. Функции с названиями func() и Func() – совершенно разные;
• После операторов необходимо ставить точку с запятой;
• Встроенные объекты и операции;
• Пробелы не учитываются. Можно использовать сколько угодно отступов, а также переводов строки, чтобы оформить свой код.

Простейший код на JavaScript выглядит следующим образом:

Сфера применения

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

• Разработка веб-приложений. Хотите установить простой счетчик, организовать передачу данных между формами или поместить на своем сайте игру? Тогда JavaScript выступит верным помощником в этом деле;
• «Активное участие» в AJAX . Эта технология позволила значительно ускорить работу приложений, осуществляя обмен данными с сервером в «фоновом » режиме:

• Операционные системы. Возможно, кто-то не знал, но Windows , Linux и Mac имеют своих браузерных конкурентов, львиная доля кода которых написана на JavaScript ;
• Мобильные приложения;
• Сфера обучения. Любая программистская специальность в университете включает в себя изучение JavaScript в том или ином объеме. Это обусловлено тем, что язык изначально разрабатывался для не очень сильных программистов. Уроки JavaScript логически вплетаются в базовый курс HTML , поэтому освоение проходит достаточно просто.

Преимущества и недостатки

Не стоит думать, что JavaScript – это какая-то панацея от всех проблем, и каждый программист с улыбкой на лице пользуется этим языком. Всё на свете имеет свои положительные и отрицательные стороны. Для начала, отметим недостатки.

• Необходимость обеспечивать кроссбраузерность. Раз уж JavaScript выступает как интернет-технология, то приходится мириться с правилами, которые устанавливает всемирная паутина. Код должен корректно выполняться во всех, или хотя бы самых популярных, браузерах;
• Система наследования в языке вызывает трудности в понимании происходящего. В JavaScript реализовано наследование, основанное на прототипах. Люди, изучавшие другие объектно-ориентированные языки программирования, привыкли к привычному «класс потомок наследует родительский класс ». Но в JavaScript такими вещами занимаются непосредственно объекты, а это не укладывается в голове;
• Отсутствует стандартная библиотека. JavaScript не предоставляет никаких возможностей для работы с файлами, потоками ввода-вывода и прочими полезными вещами;
• Синтаксис в целом затрудняет понимание. Красота кода – явно не конёк JavaScript , но главное правило программистов соблюдено: «Работает? Не трожь! ».

Теперь стоит отметить некоторые преимущества

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

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

Для тех, кто хочет изучать

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

• Прежде всего, HTML . Нельзя начинать делать что-либо для интернета без основы основ. Каскадные таблицы стилей (CSS ) также очень сильно пригодятся;
• Использовать новую литературу. Программирование – это не физика, законы которой нерушимы, а новые учебные пособия – это урезанные старые. IT-технологии постоянно развиваются, и не стоит пренебрегать полезными обновлениями;
• Стараться самостоятельно писать все участки программы. Если что-то ну совсем не получается – можно позаимствовать чужой код, но лишь предварительно уяснив для себя каждую строчку;
• Отладка – ваш верный друг. Быстро находить ошибки – один из важнейших моментов в программировании;
• Не игнорируйте нормы форматирования. Конечно, код не станет лучше или хуже от разного количества отступов и пробелов, но легкость чтения и понимания программистом – тоже немаловажный момент. Код, приведенный ниже? очень трудно воспринимается, особенно если вы не его

• Имена переменных должны иметь лексическое значение. В процессе написания простых программ это кажется вовсе не важным, но когда количество строк кода переваливает за тысячу – все черти ломают ноги;