Как правильно оформить php файл
Создайте файл с именем hello.php в корневом каталоге веб-сервера ( DOCUMENT_ROOT ) и запишите в него следующее:
<html><head>
<title>Тестируем PHP</title>
</head>
<body>
<?php echo '<p>Привет, мир!</p>' ; ?>
</body>
</html>
Эта программа чрезвычайно проста, и для создания настолько простой странички даже необязательно использовать PHP. Все, что она делает, это вывод Hello World , используя инструкцию PHP echo . Заметьте, что файл не обязан быть выполняемым или ещё как-то отличаться от других файлов. Сервер знает, что этот файл должен быть обработан PHP, так как файл обладает расширением ".php", о котором в настройках сервера сказано, что подобные файлы должны передаваться PHP. Рассматривайте его как обычный HTML-файл, которому посчастливилось заполучить набор специальных тегов (доступных также и вам), способных на кучу интересных вещей.
Цель примера - показать формат специальных тегов PHP. В этом примере мы использовали <?php в качестве открывающего тега, затем шли команды PHP, завершающиеся закрывающим тегом ?> . Таким образом можно где угодно "запрыгивать" и "выпрыгивать" из режима PHP в HTML файле. Подробнее об этом можно прочесть в разделе руководства Основной синтаксис.
Замечание: Замечание о переводах строк
Переводы строк немногое означают в HTML, однако считается хорошей идеей поддерживать HTML в удобочитаемом виде, перенося его на новую строку. PHP автоматически удаляет перевод строки, идущий сразу после закрывающего тега ?> . Это может быть чрезвычайно полезно, если вы используете множество блоков PHP-кода или подключаете PHP-файлы, которые не должны ничего выводить. В то же время, это может приводить в недоумение. Можно поставить пробел после закрывающего тега ?> и тогда пробел будет выведен вместе с переводом строки, или же вы можете специально добавить перевод строки в последний вызов echo/print из блока PHP-кода.
Замечание: Пара слов о текстовых редакторах
Существует множество текстовых редакторов и интегрированных сред разработки (IDE), в которых вы можете создавать и редактировать файлы PHP. Список некоторых редакторов содержится в разделе » Список редакторов PHP. Если вы хотите порекомендовать какой-либо редактор, посетите данную страницу и попросите добавить редактор в список. Использование редактора с подсветкой синтаксиса может быть очень большим подспорьем в вашей работе.
Замечание: Пара слов о текстовых процессорах
Текстовые процессоры (StarOffice Writer, Microsoft Word, Abiword и др.) в большинстве случаев не подходят для редактирования файлов PHP. Если вы всё же хотите использовать какой-либо из них для тестового скрипта, убедитесь, что сохраняете файл как простой текст (plain text), иначе PHP будет не в состоянии прочесть и запустить ваш скрипт.
Замечание: Пара слов о Блокноте Windows
При написании скриптов PHP с использованием встроенного Блокнота Windows необходимо сохранять файлы с расширением .php . (Блокнот автоматически добавит расширение .txt , если вы не предпримете указанные ниже меры.) Когда во время сохранения файла вас попросят указать его имя, введите имя файла в двойных кавычках (например, " hello.php "). Кроме этого, можно кликнуть на выпадающее меню "Текстовые документы" в диалоговом окне сохранения файла и выбрать в нем пункт "Все файлы". После этого можно вводить имя файла без кавычек.
Теперь, когда вы успешно создали работающий PHP-скрипт, самое время создать самый знаменитый PHP-скрипт! Вызовите функцию phpinfo() и вы увидите множество полезной информации о вашей системе и настройке, такой как доступные предопределённые переменные, загруженные PHP-модули и параметры настройки. Уделите некоторое время изучению этой важной информации.
В данной статье рассматривается подход к написанию и оформлению PHP кода. Нижеизложенные моменты были сформированы путем анализа существующих подходов компаний и личного опыта.
Все названия для папок и файлов должны быть осмысленными и говорящими (не требующие дополнительного разъяснения).
Папки
Все папки именуются в нижнем регистре с разделением слов с использованием символа - (минус).
Если папка хранит в себе классы, которые относятся к пространству имен (namespace), то папка именуется в соответствии с названием пространства имен (namespace).
Разрешенные символы для именования папок: латинские буквы и символ - (минус).
Файлы
Все файлы, относящиеся к проекту, именуются в нижнем регистре с разделением слов с использованием символа - (минус).
Если файл является файлом класса, то именуется в соответствии с названием класса.
Все названия должны быть осмысленными и говорящими (не требующие дополнительного разъяснения).
Пространства имен
Названия пространств имен должны быть в нижнем регистре и состоять из одного слова. В случае необходимости именовать пространств имен более одного слова производится дробление на составные части, являющиеся вложенными пространствами имен.
Классы
Названия классов должны соответствовать PascalCase . В PascalCase каждое слово начинается с заглавной буквы.
Трейты имеют постфикс Trait . Интерфейсы имеют постфикс Interface . Абстрактные классы имеют префикс Abstract .
Методы
Названия методов должны соответствовать camelCase . camelCase должен начинаться со строчной буквы, а первая буква каждого последующего слова должна быть заглавной. Все слова при этом пишутся слитно между собой
К названиям методов применяются следующие правила:
- Название метода должно передавать намерения программиста
- Название метода должно сообщить, почему этот метод существует, что он
делает и как используется ( isPostRequest , getRequestType , parseSchemaElement , renderPageWithSetupsAndTeardowns ) - Название метода не должно быть коротким
- Название метода должно начинаться с глагола
- Названия boolean методов должны содержать глагол is , has или can
Переменные
Названия переменных должны соответствовать camelCase . camelCase должен начинаться со строчной буквы, а первая буква каждого последующего слова должна быть заглавной. Все слова при этом пишутся слитно между собой
Константы должны быть соответствовать UPPER_CASE_SNAKE_CASE . В UPPER_CASE_SNAKE_CASE все слова пишутся заглавными буквами, а пробелы заменяются знаками подчеркивания.
К названиям переменных применяются следующие правила:
Название переменной должно передавать намерения программиста
Название переменной должно сообщить, почему эта переменная существует, что она делает и как используется
Название переменной не должно быть коротким
В названии переменной не должен использоваться тип данных. Исключение составляет Map ( $typesMap , $statesMap ), т.к. в ином случае его не отличить от массива с данными.
Если переменная хранит признак, то он должен быть включен в название ( unpaidProject )
Переменные, отражающие свойства объекта, должны включать название объекта ( userIsAdmin , messageIsSend , figureCanBePainted , projectName )
Переменные и свойства объекта должны являться существительными и называться так, чтобы они правильно читались при использовании, а не при инициализации
Плохо:
Хорошо:
Названия boolean переменных должны содержать глагол is , has или can
Запрещены отрицательные логические названия
Плохо:
Хорошо:
При наличии свойств (пункт 8 и аналогичные), порядок имя переменной состоит из: имени объекта, по отношению к которому используется переменная), свойство и продолжение названия переменной ( userHasRoleAdmin , statusIsActive )
В первую очередь ставится пространство имен (namespace), которое используется (если есть). Далее пишется конструкции использования классов ( use ). В случае использования нескольких
классов одного пространства имен происходит группировка с помощью конструкции <. >. Далее идет объявление класса.
Фигурные скобки ставятся на той же строке и разделяются пробелом.
- Внутри не разделяются пробелом.
- Снаружи разделяются пробелами управляющие конструкции
- После названия метода/функции — пробел не ставится.
Каждая переменная должна быть объявлена на новой строке.
Условия и служебные вызовы методов разделяются переносом строки, переменные и работа с ними переносами строк не разделяются.
Внутри условий и циклов дополнительный перенос на новую строку не ставится.
Содержимое класса разделяется сверху одной пустой строкой.
Перед возвращаемым значением( return ) обязательно ставится перенос строки, если метод не состоит из единственной строки.
Если условие является большим, то обязательно выделить его в одно или несколько смысловых выражений и использовать его (их) в условии.
Плохо:
Хорошо:
Комментирование кода
В общем случае комментарии запрещены (НЕ "всегда"). Любой участок кода, который необходимо выделить или прокомментировать, надо выносить в отдельный метод.
Комментарии должны быть расположены перед объявлением классов, переменных и методов и быть оформлены в соответствии с PHPDoc. Комментарий перед классом должен содержать описание бизнес-логики и отражать его назначение с приведением примеров использования.
Однострочный комментарии обозначаются символами // , а многострочный /*. */ .
Готовые алгоритмы, взятые из внешнего источника, должны быть помечены ссылкой на источник.
Везде, где имеет смысл, должнно быть прописано declare(strict_types=1);
В функциях/методах вместо отсутствующего скалярного значения используется null . 0 и пустую строку нельзя использовать в качестве показателя отсутствия значения.
Нельзя изменять переменные, которые передаются в метод на вход (исключение — если эта переменная объект).
Нельзя нескольким переменным присваивать одно и то же значение. Для проверки наличия ключа в ассоциативном массиве используется array_key_exists , а не isset . Нельзя смешивать в массиве строковые и числовые ключи. Нельзя сортировать ассоциативные массивы.
Строки обрамляются одинарными кавычками. Двойные кавычки используются только, если:
- Внутри строки должны быть одинарные кавычки
- Внутри строки используется подстановка переменных
- Внутри строки используются спец. символы \n , \r , \t и т.д.
Вместо лишней конкатенации используем подстановку переменных в двойных кавычках
В методах должна быть использована максимально возможная типизация, включая тип возвращаемого значения( : type ). Все параметры и их типы должны быть описаны в объявлении метода либо в PHPDoc. Методы названия, которых начинаются c check и validate , должны выбрасывать исключения и не возвращать значения.
Все методы класса по умолчанию должны быть private . Если метод используется наследниками класса, то он объявляется protected . Если используется сторонними классами, тогда public .
Если метод может вернуть null , то желательно реализовать шаблон проектирования Null object, или выбросить исключение, или вернуть объект особого случая (пример: пустой массив).
При возврате из метода данных типа json — недопустимо писать return true , всегда использовать конструкцию return ['success' => ['message' => '. ']] или ['error' => ['message' => '. ']] . message приведен для примера, можно использовать любые ключи в неограниченном количестве.
Метод должен явно отличать нормальные ситуации от исключительных.
По умолчанию тексты исключений не должны показываться пользователю. Они предназначены для логирования и отладки. Текст исключения можно показать пользователю, если оно явно для этого предназначено.
В условном операторе должно проверяться исключительно boolean значение. В сравнении не boolean переменных используется строгое сравнение с приведением типа ( === ), автоматическое приведение и нестрогое сравнение не используются.
При использовании в условном выражении одновременно операторов И и ИЛИ обязательно выделять приоритет скобками.
Следование единым правилам упрощает работу программистов. Оформление кода PHP по одному стандарту помогает в командной работе и повышает уровень разработки. Понятие «качественный код» появилось не случайно, так же, как и анекдоты о неспособности спустя время прочитать даже собственный код. Понятный структурированный код сокращает время чтения, позволяет сразу приступить к поиску проблемы.
Восемь общих правил
Существуют правила, которые подойдут для написания кода на любом языке программирования. Только следование им уже повысит качество вашего кода.
- Придумывайте понятные и читаемые названия. Избегайте русских слов в латинской транскрипции. Только английские слова, обозначающие суть.
- Делайте отступы на каждом уровне и отделяйте логические блоки пустой строкой.
- Сокращайте вложенность кода и убирайте дублирование.
- Контролируйте длину. Рекомендуем для функций не более 20 строк, для метода не более 50 строк, для класса не более 300 строк, для файла — не более 1000 строк. Также ограничивайте длину одной строки до видимого значения на экране. Мягкое ограничение составляет 120 символов.
- Комментируйте и документируйте код. Это позволит зафиксировать всю необходимую информацию.
- Используйте рефакторинг. Следуйте принципу «рефакторинг — раньше и рефакторинг — чаще». Советуем также прочитать книгу «Рефакторинг. Улучшение проекта существующего кода» Мартина Фаулера.
- Работайте в системе контроля версий, например, Git. Это бесплатно и удобно. Обучиться работать в ней можно за 11 занятий на видеокурсе «Git. Быстрый старт».
- Изучайте Open Source код. Вы сможете увидеть, как пишут ведущие разработчики и воспользоваться лучшими практиками в программировании.
Правила кода PHP
На конец 2017 г. действуют стандарты PHP программирования: PSR-2 и PSR-1. Они устанавливают правила синтаксиса, именования, оформления. Весь код должен быть написан единообразно. Это касается пробелов, отступов, скобок, строк.
Чтобы не запоминать все требования стандартов, можно работать в современной среде разработки — PhpStorm, NetBeans и подобных. Они позволяют автоматически форматировать текст в соответствии с правилами.
Отступы
Правильное оформление кода PHP предполагает его простое визуальное восприятие. Оно достигается с помощью отступов и пробелов. Для формирования отступов используйте пробелы, а не знак табуляции. Каждую строку начинайте с четырех пробелов. Код должен идти лесенкой: раскрываться вправо, затем собираться обратно.
Запомните: один отступ = четыре пробела.
Выделяем отступами тело конструкции, тело метода, блоки импорта, аргументы и подобное.
Правильно
Неправильно
Пробелы
- между for ( foreach/ while / catch) и (
- после ;
- между ) и
- перед =>
- после =>
- между try и
- между > и catch
- После имени метода.
- В списке аргументов перед запятыми.
- Между ( и именем функции или метода.
Пустая строка
- После каждого логического блока.
- После определения пространства имен.
- После блока импорта. Каждая строка блока должна начинаться с use.
Правильно
Неправильно
Круглые скобки
- Не выносим на отдельные строки.
- Не ставим пробелы внутри: после ( и перед ).
- Ставим пробелы до скобок и после.
- Внутри перечисление отделяем пробелами.
Фигурные скобки
- Открывающая фигурная скобка выносится на новую строку перед телом метода, для классов.
- Открывающая фигурная скобка не выносится на отдельную строку в конструкциях и замыканиях.
- Закрывающая скобка > в конструкциях, имени метода, определении метода, классах пишется с новой строки и отделяется одним отступом.
Аргументы
Оформляются двумя способами: в одну строку через запятую или в столбик. Аргументы на одной строке пишутся через запятую внутри круглых скобок. Пробел ставится только после запятой.
Правильно
Неправильно
При оформлении в столбик каждый аргумент пишется с новой строки и отделяется двойным отступом. Первая круглая скобка остается на строке вместе обозначением метода. Вторая круглая скобка выносится в отдельную строку вместе с открывающей фигурной скобкой. Между ними пробел.
Правильно
Неправильно
Конструкция switch case
Конструкцию делим на три уровня: switch, case, echo/break. Каждый уровень начинается с отступа. Таким образом, наш код визуально выглядит состоящим из трех столбцов.
Если в конструкции не используется break, поставьте // no break.
Правильно
Неправильно
Конструкция try catch
Тело try и тело catch отделяются одним отступом. Пробелы нужно поставить:
- между try и
- между > и catch
- между catch и (
- между ) и
Catch и скобку > ставим на одну строку.
Правильно
Неправильно
Конструкция if, elseif, else
Операторы и открывающую фигурную скобку пишем на одной строке. Закрывающую фигурную скобку оператора пишем на той же строке, что и оператор. Заключительную фигурную скобку пишем на отдельной строке. Оператор else if пишем как единое слово - elseif. Тело оператора отделяем отступом.
Правильно
Неправильно
Комментарии в коде
Чистый код должен быть правильно закомментирован. К сожалению, встречаются две крайности: подробное комментирование каждой строки и полное отсутствие комментариев. И то, и другое мешает в работе. Избыточное комментирование снижает восприятие кода, отвлекает от понимания его сути. Писать очевидные вещи — тратить свое и чужое время. Иногда из-за слишком подробных комментариев объем кода увеличивается в несколько раз. Закончив с кодом, посмотрите критически. Очевидные и банальные комментарии удалите.
Обратная сторона медали — отсутствие пояснений. Коды со сложной архитектурой, скриптами, с большой вложенностью требуют пометок. В этом случае комментарии помогут быстро ориентироваться в коде другим членам команды. Часто они помогают и самому разработчику кода. Главное — придерживаться золотой середины и комментировать только важные моменты.
Больше информации о комментариях вы найдете в статье «Почему комментарии в коде — зло». А если вы считаете, что код - не место для шуток, предлагаю подборку самых забавных комментариев программистов.
Чек-лист «Инспекция кода»
Предлагаем чек-лист для самостоятельной проверки чистоты кода. Если вы будете инспектировать чужой код, помните, что программист — творческая профессия. А творческие люди обычно тяжело воспринимают критику. Будьте лояльней.
- Легко ли воспринимать код визуально?
- Присутствуют ли комментарии? насколько они необходимы?
- Соответствует ли код стандартам PSR-1 и PSR-2? Краткая выжимка стандартов приведена в разделе “Правила кода PHP”.
- Используете ли вы систему документирования phpDoc или подобную?
- Нужно ли делать перерыв в чтении, чтобы разобраться в написанном?
- Проведен ли рефакторинг?
- Есть ли дублирование в блоках, функциях и пр.?
- Понятны ли названия переменных, имена методов и пр.?
- Какова длина строк, методов, функций, классов, файла?
- Вы искали ошибки и баги?
- Как можно еще улучшить код?
- Можно ли сделать его короче?
- Можно ли сделать его эффективней?
Желательно провести тестирование. Руководствуйтесь тремя принципами:
- Тесты должны быть полными.
- Тесты должны соответствовать установленным требованиям.
- Тесты должны проводиться на нужном уровне тестирования.
Дополнительную информацию по тестированию вы найдете в материале «Тестирование кода для чайников».
Заключение
Код — это не личный захламленный ящик с грудой бумаг. Правильный код — это картотека в Ленинской библиотеке. В нем все структурировано, задокументирована важная информация, есть связи с другими каталогами и библиотеками. Чистый код может разобрать и профи, и начинающий программист. С ним приятно работать, он характеризует уровень мастерства своего разработчика.
Старайтесь следовать принятым правилам, рекомендациям и стандартам. Думайте о тех, кто будет работать с ним после вас. Всегда пробуйте сделать код короче и эффективней. Напишите так, чтобы это понимал не только Бог.
Большинство программистов пишут код как им угодно. Отступы делают табуляциями, визуальный стиль как привыкли. И это не есть плохо, если над проектом работает исключительно один человек. Но если в последствии над написанным кодом будет работать другой программист? Ему будет очень непривычно и сложно разобраться в чужом коде, поэтому рекомендуется следовать стандартам написания кода, о которых и пойдет речь в данной статье.
Разберем стандарты, стили и правила оформления кода PHP, которые необходимы для обеспечения высокого уровня технической совместимости между общим кодом PHP. Действующие стандарты PHP программирования: PSR-2 и PSR-1. Они устанавливают правила синтаксиса, именования и оформления.
- Придумывайте понятные, читаемые и обозначающие суть названия только на английском.
- Делайте отступы на каждом уровне и отделяйте логические блоки пустой строкой.
- По возможности максимально сокращайте вложенность кода и убирайте дублирование.
- Комментирование и документирование кода позволит зафиксировать всю необходимую информацию.
- Файлы должны использовать только теги <?php и <?=.
- Файлы должны использовать только UTF-8 без спецификации для кода PHP.
- Для оформления отступов должны использоваться четыре пробела (но не знак табуляции).
- Недопустимо жестко ограничивать длину строки. Мягкое ограничение должно составлять 120 символов. Следует стараться, чтобы длина строки составляла 80 символов или менее. Если строка длиннее, рекомендуется использовать конкатенацию и перенос строк. В конце непустых строк не должно быть пробелов. В одной строке не должно быть более одного выражения.
- В конце каждого файла с PHP-кодом должна быть одна пустая строка.
- В файлах, содержащих только PHP-код, закрывающий тег ?> должен отсутствовать.
- Ключевые слова PHP должны быть написаны в нижнем регистре.
- Константы PHP true, false и null должны быть написаны в нижнем регистре.
- Операторы и ключевые слова отделять пробелами.
- В файлах следует либо объявлять структуры (классы, функции, константы и т.п.), либо генерировать побочные эффекты (реализация логики, не связанной с объявлением классов, функций, констант, подключения внешнего файла). Например, следует избегать ситуации из следующего листинга, который содержит объявления структур и порождение побочных эффектов:
Следующий пример демонстрирует файл рекомендуемой реализации с объявлениями без побочных эффектов:
- Имена классов должны быть объявлены с использованием так называемой «СamelCase» (каждое слово начинается с большой буквы, между словами нет разделителей).
- Имена методов и Функций должны быть объявлены с использованием так называемой «camelCase» (первое слово пишется в нижнем регистре, далее каждое слово начинается с большой буквы, а между словами нет разделителей).
- Константы классов должны быть объявлены исключительно в верхнем регистре с использованием символа подчеркивания для разделения слов.
- Для явного указания типа переменной использовать префикс отражающий их тип:
- При множественной инициализации переменных выравнивать значения между ними по правому краю используя дополнительное пространство:
- Каждый класс должен располагаться в отдельном файле и в пространстве имен с хотя бы одним верхним уровнем (именем производителя).
- Открывающая фигурная скобка "" в определении класса должна располагаться на новой строке, а закрывающая фигурная ">" скобка должна располагаться на следующей строке после тела класса.
- Открывающая фигурная скобка "" в определении метода должна располагаться на новой строке, а закрывающая фигурная скобка ">" должна располагаться на следующей строке после тела метода.
- Тело каждой управляющей конструкции должно быть заключено в фигурные скобки " ". Это позволяет стандартизировать внешний вид управляющих конструкций и снизить риск возникновения ошибок при добавлении новых строк в тело конструкции.
- После ключевых слов в управляющих конструкциях (if, else, elseif, while, do-while, for, foreach, break, continue, switch, declare, return, require, include, require_once, include_once, goto) должен располагаться один пробел, а после вызовов функций и методов - не должен.
- Между закрывающей круглой скобкой ")" и открывающей фигурной скобкой "" должен быть один пробел.
- Открывающая фигурная скобка "" в управляющих конструкциях должна располагаться в той же строке, что и сама конструкция, а закрывающая фигурная скобка ">" должна располагаться на следующей строке после тела конструкции.
- После открывающей круглой скобки "(" и перед закрывающей круглой скобкой ")" в управляющих конструкциях не должно быть пробела.
- Список аргументов и переменных функции может быть разделен на несколько строк, каждая из которых дополнена слева одним отступом. В таком случае первый элемент списка должен начинаться с новой строки, и в каждой строке должен быть указан только один элемент.
- В конструкции Switch выражение Case должно быть смещено на один отступ от Switch, а ключевое слово Break (или иное слово, обозначающее выход из конструкции) должно располагаться на том же уровне отступов, что и тело Case. В том случае, когда в непустом теле Case умышленно не используется Break, должен быть комментарий в стиле "// no break".
- Массивы форматировать в таком виде:
Отступы улучшают читабельность кода. Для их оформления используйте четыре пробела (но не знак табуляции).
2. Ключевые слова и константы true / false / null
Ключевые слова PHP, а также константы true , false и null следует писать в нижнем регистре.
3. Определение пространств имён и блоков импорта
- Оставляйте одну пустую строку после определения пространства имён.
- Импорт пространств имён располагайте после определения пространства имён.
- Для каждого импорта пространства имён используйте отдельную строку со своим use .
- После блока импорта оставляйте одну пустую строку.
4. Методы и аргументы
- Пробел после имени метода.
После имени метода не должно быть пробела. Хорошо Плохо - Открывающая скобка.
Открывающую фигурную скобку ставьте на отдельной строке. Хорошо Плохо - Закрывающая скобка.
Закрывающую фигурную скобку ставьте на следующей за телом метода строке. Хорошо Плохо - Пробелы в определении метода.
Не должно быть пробелов после открывающей и перед закрывающей круглыми скобками в определении метода. Хорошо Плохо - Пробелы в списке аргументов.
В списке аргументов перед запятыми не должно быть пробелов, после каждой запятой – один пробел. Хорошо Плохо - Аргументы на нескольких строках.
Список аргументов можно разделять на несколько строк, каждая из которых дополнена слева одним отступом (четырьмя пробелами). В таком случае первый элемент списка аргументов нужно располагать с новой строки, и в каждой строке указывайте только один аргумент. При этом закрывающая круглая скобка и открывающая фигурная скобка должны располагаться вместе на своей отдельной строке, а между ними должен быть один пробел. Хорошо Плохо
5. Вызовы методов и функций
- Пробелы.
В коде вызова функций и методов не ставьте пробел:- между именем функции или метода и открывающей круглой скобкой;
- после открывающей круглой скобки;
- перед закрывающей круглой скобкой.
6. Конструкции switch и case
Конструкция switch должна выглядеть следующим образом. Выражение case смещено на один отступ (четыре пробела) от switch , а ключевое слово break (или иное слово, обозначающее выход из конструкции) располагается на том же уровне отступов, что и тело case . Если в непустом теле case умышленно не используется break , допишите комментарий в стиле // no break .
7. Конструкции while и do while
Конструкцию while следует оформлять следующим образом. Между while и ( ставится пробел. После ( и до ) пробелов не должно быть. ) и < разделяются пробелом. Тело конструкции отделяется одним отступом (четыре пробела). >пишется на новой строке после тела конструкции.
Конструкция do while должна выглядеть так:
8. Конструкция for
Пример оформления конструкции for представлен ниже. Между for и ( ставится пробел. После ; ставится пробел. ) и < разделяются пробелом. Тело конструкции отделяется одним отступом (четыре пробела). >пишется на новой строке после тела конструкции.
9. Конструкция foreach
Конструкция foreach должна выглядеть следующим образом. Между foreach и ( ставится пробел. Перед и после => ставится пробел. ) и < разделяются пробелом. Тело конструкции отделяется одним отступом (четыре пробела). >пишется на новой строке после тела конструкции.
10. Конструкция try catch
Оформляйте конструкцию try catch следующим образом. Между try и < ставится пробел. >и следующий за ним catch находятся на одной строке. Между catch и ( ставится пробел. ) и < разделяются пробелом. Тело try и тело catch отделяется одним отступом (четыре пробела). >пишется на новой строке после тела конструкции.
Читайте также: