Как написать код программы

Что нужно чтобы начать программировать на C++? Вы можете скачать себе текстовой редактор, скачать IDE или воспользоваться онлайн компиляторами.

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

3 IDE для написания кода :

Лично я пользуюсь Visual Studio.

Как написать первую программу?

После того как вы создали проект у вас в текстовом редакторе появится краткая инструкция о возможностях языка.

Примерно она выглядит так:

Краткая инструкция

Теперь мы можем все стереть и написать свою первую программу.

Будет она выглядеть примерно так:

Первая и самая простая программа

using namespace std ;

После того как вы завершили написание программы нажмите клавишу: F5

У вас откроется консоль и вы учите следующие:

Первая программа на JavaScript. Как выполняется код на JavaScript

Hello world!

Почему примерно, потому что нужно поставить перед include знак решётки. Лучше всего посмотрите картинку, которая над кодом. Сейчас подробно разберём каждую строчку кода. Разберём комментарии и как включить русский язык в вашем коде. И так, начнём:

1 строчка кода

*знак решетки*include

Данная строчка является директивой препроцессора. Препроцессор — это программа, которая выполняет обработку файла исходного файла перед началом собственно компиляции. Говорится о препроцессоре, обрабатывающем директивы, имена которых начинаются со *знак решетки*. Эта директива заставляет препроцессор добавить содержимое файла iostream в вашу программу. Часть io в iostream означает ввод и вывод.

2 строчка по 7 строку кода

Данные строки говорят о том, что существует функция по имени int main(), и они описывают её поведение. Этот маленький код образует определение функции. int main() — заголовок функции. Часть которая заключена в фигурные скобки — тело функции. Операторы — выражение C++ завершаемое точкой с запятой. Оператор return 0 — оператор возврата.

Его назначение завершить выполнение функции.

4 строка

using namespace std ;

Данная строка говорит, о том что существует директива using. Пространство имён — предназначено для упрощения разработки. Средство пространства имён позволяет поставщику упаковать свой продукт в модуль — пространства имён. Эта строка не обязательна.

5 строка

Esacape последовательность

И в консоли мы получаем следующие:

Hello
World!

Endl — манипулятор. «n» — символ новой строки.

Как «включить» русский язык?

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

Как писать простой код

Добавили новую строку

И вот что нам выдаст консоль:

Hello world!

Что-то такое непонятное. Так вот как раз функция setlocale решает эту проблему. Напишем ее

Добавили функцию Setlocae

Консоль выводит следующее:

Hello world!

Привет мир

Теперь все верно. Правда если вы напиши setlocale после cout, то вам также вылезет что-то непонятное. Так что, setlocale нужно использовать до cout.

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

Источник: dzen.ru

С чего начать: документация по стилю оформления кода

Все дороги программиста ведут к документации. В каждом языке существует свой стандарт оформления кода. Для Python используется документ PEP-8, для PHP – стандартные рекомендации PSR-1 и PSR-2, для Java – Java Coding Conventions, для JavaScript – Airbnb JavaScript Style Guide или Google JavaScript Style Guide. Документ для вашего языка вы найдете по поисковому запросу Code Style.

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

В популярных IDE заложена возможность автоматической настройки стиля кода под стандарты – общие или предложенные командой. Разберитесь, как настроить среду под необходимое оформление. Потраченное время сэкономит многие часы рутинной работы.

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

Роберт Мартин «Чистый код. Создание, анализ и рефакторинг»

Как Библиотека программиста, мы не могли обойтись без упоминания замечательной книги Роберта Мартина о чистом коде и анализе программ. В книге приводятся примеры для языка Java, но большинство идей справедливы для любых языков.

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

Главное правило чистого кода: выразительные имена

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

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

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

Блоки if, else, while должны иметь минимальный размер, чтобы информацию о них можно было держать в уме. Старайтесь избегать отрицательных условий – на их восприятие обычно уходит чуть больше времени, чем на положительные. То есть запись if (buffer.shouldCompact()) предпочтительнее записи if (!buffer.shouldNotCompact() .

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

Функция должна выполнять только одну операцию, выполнять ее хорошо, и ничего другого она делать не должна.

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

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

Бьёрн Страуструп, создатель языка С++

Исключения вместо кодов ошибок. Используйте исключения ( try-catch , try-except ) вместо возвращения кодов ошибок. Возвращение кодов приводит к слишком глубокой вложенности.

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

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

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

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

Комментарии

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

Однако есть несколько видов комментариев, которые выглядят достаточно оправданными.

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

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

Предупреждения о последствиях. Иногда бывает полезно предупредить других программистов о нежелательных последствиях:

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

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

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

F.I.R.S.T. Качественные тесты должны обладать пятью характеристиками, первые буквы которых образуют указанный акроним:

• Fast. Тесты должны выполняться быстро.
• Independent. Тесты не должны зависеть друг от друга и выполняться в любом порядке.
• Repeatable. Тесты должны давать воспроизводимые в любой среде результаты.
• Self-validating. Результат выполнения теста – логический признак: тест пройден или нет. Иначе результаты приобретают субъективный характер.
• Timely. Тест должен создаваться своевременно. Тесты нужно писать непосредственно перед написанием кода.

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

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

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

Не нужно бездумно следовать догмам. Не переусердствуйте с сокращением кода функций и классов. Всегда руководствуйтесь здравым смыслом.

Заключение

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

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

Расскажите нам о правилах, которые вы применяете для написания своего программного кода. Какие open source программы, на ваш взгляд, имеют лучшее качество кода?

Больше полезной информации вы найдете на наших телеграм-каналах «Библиотека программиста» и «Книги для программистов».

Источник: proglib.io

Правила написания кода: от создания системы до работы с объектами

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

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

Ну, не всем вот так сразу хочется вгрызаться в книги типа Clean Code, так как написано в них много, а поначалу понятно мало.

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

Система

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

Этапы проектирования системы

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

Главные принципы и концепции проектирования системы

1. Выразительность — необходимость чётко выраженной цели класса, достигается путём правильного именования, небольшого размера и соблюдения принципа single responsibility (немного ниже рассмотрим подробнее).
2. Минимум классов и методов — в своём стремлении разбить классы на как можно более мелкие и однонаправленные можно зайти слишком далеко (антипатерн — стрельба дробью). Этот принцип призывает всё же сохранять компактность системы и не заходить слишком далеко, создавая по классу на каждый чих.
3. Отсутствие дублирования — лишний код, который путает, — признак не лучшего проектирования системы, выносится в отдельное место.
4. Выполнение всех тестов — система, прошедшая все тесты, контролируема, так как любое изменение может повлечь за собой падение тестов, что может показать нам — изменение внутренней логики метода потянуло и изменение ожидаемого поведения.

Interface

Пожалуй, один из самых важных этапов создания адекватного класса — это создание адекватного интерфейса, который будет представлять хорошую абстракцию, скрывающую детали реализации класса, и при этом будет представлять группу методов, чётко согласующихся между собой. Рассмотрим подробнее один из принципов SOLID — interface segregation : клиенты (классы) не должны реализовывать ненужные методы, которые они не будут использовать.

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

Класс

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

1. public static константы;
2. private static константы;
3. private переменные экземпляра.

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

Размер класса

Теперь хотелось бы поговорить о размере класса. Вспомним один из принципов SOLID — single responsibility . Single responsibility — принцип единственной ответственности. Он гласит, что у каждого объекта есть лишь одна цель (ответственность), и логика всех его методов направлена на ее обеспечение.

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

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

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

Объекты

Инкапсуляция

Тут мы в первую очередь поговорим об одном из принципов ООП — инкапсуляции . Итак, скрытие реализации не сводится к созданию прослойки метода между переменными (бездумное ограничение доступа через одиночные методы, геттеры и сеттеры, что не есть хорошо, так как весь смысл инкапсулирования теряется). Скрытие доступа направленно на формирование абстракций, то есть класс предоставляет общие конкретные методы, посредством которых мы работаем с нашими данными. А знать, как именно мы работаем с этими данными, пользователю не обязательно — работает да и ладно.

Закон Деметры

• методов самого объекта Car (иначе говоря — this);
• методов объектов, созданных в move ;
• методов переданных объектов в качестве аргументов — arg1 , arg2 ;
• методов внутренних объектов Car (тот же this).

Структура данных

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

Ключевое отличие от обычного объекта заключается в том, что объект — это набор методов, которые работают с элементами данными, существование которых подразумевается неявно. Понимаете? В обычном объекте главным аспектом являются методы, и внутренние переменные направлены на их правильную работу, а в структуре данных наоборот: методы поддерживают, помогают работать с хранимыми элементами, которые здесь и являются главными. Одна из разновидностей структур данных — Data Transfer Object (DTO) . Это класс с открытыми переменными и без методов (или только методами для чтения/записи), которые передают данные при работе с базами данных, работают с парсингом сообщений из сокетов и т. д. Обычно в таких объектах данные долго не хранятся и почти сразу конвертируются в сущность, с которой и работает наше приложение. Сущность, в свою очередь, тоже получается структурой данных, но ее предназначение — участвовать в бизнес-логике на разных уровнях приложения, а у DTO — транспортировать данные в/из приложения. Пример DTO:

Всё вроде бы понятно, но тут мы узнаем о существовании гибридов. Гибриды — это объекты, которые содержат методы для обработки важной логики и хранят внутренние элементы и методы доступа к ним (get/set). Подобные объекты сумбурны, и усложняют добавление новых методов. Не стоит использовать их, так как непонятно, для чего они предназначены — для хранения элементов или выполнения какой-то логики. Про возможные типы обьектов можно почитать тут.

Принципы создания переменных

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

1. В идеале нужно объявлять и инициализировать переменную непосредственно перед её использованием (а не создали, и забыли про неё).
2. По возможности объявлять переменные как final, чтобы предотвратить изменение её значения после инициализации.
3. Не забывать про переменные-счётчики (обычно мы их используем в каком нибудь цикле for , то есть нужно не забывать их обнулить, иначе это может сломать нам всю логику).
4. Нужно стараться инициализировать переменные в конструкторе.
5. Если существует выбор между использованием объекта со ссылкой или без ( new SomeObject() ), делайте выбор в пользу без , так как этот объект после использования удалится во время следующей сборки мусора и не будет использовать ресурсы зря.
6. Делайте время жизни переменных как можно короче (расстояние между созданием переменной и последним обращением).
7. Инициализируйте переменные, используемые в цикле, непосредственно перед циклом, а не в начале метода, содержащего цикл.
8. Начинайте всегда с самой ограниченной области видимости и расширяйте её только при необходимости (нужно стараться делать переменную как можно более локальной).
9. Используйте каждую переменную только с одной целью.
10. Избегайте переменных со скрытым смыслом (переменная разрывается между двумя задачами, значит для решения одной из них её тип не подходит).

Методы

Перейдём непосредственно к реализации нашей логики, а именно — к методам.

1. Первое правило — это компактность. В идеале один метод не должен превышать 20 строк, поэтому если, скажем, public метод значительно “разбухнет”, нужно задуматься о выносе отделяемой логики в приватные методы.
2. Второе правило — блоки в командах if , else , while и так далее, не должны иметь большую вложенность: это значительно понижает читаемость кода. В идеале вложенность должна быть не более двух блоков <> . Код в этих блоках тоже желательно делать компактным и простым.
3. Третье правило — метод должен выполнять только одну операцию. То есть, если метод выполняет сложную разнообразную логику, мы его бьём на подметоды. В итоге сам метод будет фасадом, цель которого — вызов всех остальных операций в правильном порядке. Но что если операция кажется слишком простой для создания отдельного метода? Да, иногда это может показаться пальбой из пушки по воробьям, но небольшие методы обеспечивают ряд преимуществ:
4. облегченное чтение кода;
5. методы имеют свойство усложняться с течением разработки, и если метод изначально был простым, усложнение его функционала будет немного проще;
6. сокрытие деталей реализации;
7. облегчение повторного использования кода;
8. более высокая надёжность кода.
9. Правило понижения — код должен читаться сверху вниз: чем ниже — тем большее углубление в логику, и наоборот, чем выше — тем более абстрактные методы. Например, команды switch довольно-аки некомпактны и нежелательны, но если без использования переключателя никак, нужно постараться вынести его как можно ниже, в самые низкоуровневые методы.
10. Аргументы метода —какое их количество идеально? В идеале их вовсе нет)) Но разве так бывает? Однако нужно стараться иметь их как можно меньше, ведь чем их меньше, тем проще использовать данный метод и легче его протестировать. Если сомневаешься, попробуй угадать все сценарии использования метода с большим количеством входящих аргументов.
11. Отдельно хотелось бы выделить методы, имеющие входящим аргументом некий boolean флаг , так как это само собой подразумевает, что данный метод реализует более одной операции (если true то одна, false — другая),. Как я писал выше, это не есть хорошо и по возможности этого следует избегать.
12. Если у метода большое количество входящих аргументов (крайнее значение — 7, но стоит задумываться уже после 2-3), необходимо сгруппировать некоторые аргументы в отдельном объекте.
13. Если есть несколько похожих методов (перегруженных) , то похожие параметры необходимо передавать в одном и том же порядке: это повышает читаемость и удобство использования.
14. Когда вы передаёте в метод параметры, вы должны быть уверены, что они все будут использованы, иначе зачем нужен этот аргумент? Выпилите его из интерфейса да и всё.
15. try/catch выглядит по своей природе не очень красиво, поэтому неплохим ходом было бы вынести его в промежуточный отдельный метод (метод для обработки исключений):

public void exceptionHandling(SomeObject obj) < try < someMethod(obj); >catch (IOException e) < e.printStackTrace(); >>

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

Источник: javarush.com