Вниз

Posts from the ‘PHP’ Category

20
Мар

Как подключиться к MySQL используя PHP

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

1. Создайте файл с именем – config.php:

/* Настройки для подключения к СУБД MySQL */

$localhost = "localhost";
$database = "имя_базы";
$user = "имя_пользователя";
$password = "пароль";

Переменная $localhost хранить имя подключения, если подключение происходить на локальном компьютере это имя localhost, иначе если подключение к MySQL происходит на удаленном компьютере, тогда вместо localhost указывается IP адрес удаленного компьютера. Переменная $datebase хранит имя базы данных, к которой мы хотим подключиться. Переменная $user и $password соответственно хранит имя пользователя и пароль пользователя базы данных MySQL.

2. Создаем подключение к MySQL:

$result = mysql_connect($localhost, $user, $password);

Функция mysql_connect() создает новое подключение к MySQL или использует существующее. Передаем список параметров: $localhost, $user, $password в которых передается имя локального компьютера, имя пользователя, пароль. Возвращает TRUE если соединение было успешно установлено или FALSE если возникла ошибка. Результат записываем в переменную $result.

3. Проверяем, есть ли соединение с MySQL:

if(!$result)
{
    echo "<p>К сожалению, не доступен сервер MySQL</p>";
    exit();
}

Если в переменную $result попадает значение FALSE, тогда выполняется действие которое находиться в фигурных скобках. В браузере выведет текст: К сожалению, не доступен сервер MySQL. После этого сработает функция exit() остановить выполнение следующего действия. В случае TRUE PHP проигнорирует конструкцию IF и пойдет дальше читать код.

4. Выбирает базу данных MySQL:

if (!mysql_select_db($database, $result) )
  {
    echo "<p>К сожалению, не доступна база данных</p>";
    exit();
  }

Функция mysql_select_db() выбирает для работы указанную базу данных и дальше при каждом вызове mysql_query() будет работать с выбранной базой данных. Первым параметром передаем имя выбранной базы данных, в нашем случае – переменная $database. Вторым параметром передаем соединение MySQL – переменная $result. Если функция mysql_select_db() возвращает FALSE в этом случае PHP попадает в блок IF и выводит в браузер текст: К сожалению, не доступна база данных далее срабатывает функция exit() останавливает выполнение следующего действия.

В случае TRUE PHP проигнорирует конструкцию IF и пойдет дальше читать код. Важно делать проверки перед тем, как начинать работать – помогает облегчить работу устранения ошибок. Ниже полный код подключения к MySQL:

/* Настройки для подключения к СУБД MySQL */

$localhost = "localhost";
$database = "имя_базы";
$user = "имя_пользователя";
$password = "пароль";

// Создаем подключение к MySQL
$result = mysql_connect($localhost, $user, $password);

// Проверяем создалось подключение к MySQL
if(!$result)
{
    echo "<p>К сожалению, не доступен сервер MySQL</p>";
    exit();
}

// Выбираем базу данных MySQL и проверяем доступна она в базе данных
if (!mysql_select_db($database, $result) )
  {
    echo "<p>К сожалению, не доступна база данных</p>";
    exit();
  }

// Выполняем запрос...
  mysql_query("SELECT VERSION()");

Функция mysql_query() посылает один запрос (посылка нескольких запросов не поддерживается) активной базе данных MySQL. В результате выводит в браузер версию MySQL, которая используется пользователем на локальном компьютере или хостинг-провайдером.

23
Янв

PHP стандарты кодирования

Почему стандартизация так важна

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

Выбирайте правильные имена

Имена – сердце программирования. В прошлом люди верили, что если узнать настоящее имя человека, можно получить власть над ним. Если вы подберёте правильные имена, вы наделите себя и других (всех, кто придёт после вас) властью над кодом. Просьба не смеяться, всё серьёзно. Имя является результатом продолжительного осмысления мира, в котором «живёт» тот или иной объект. Только тот программист, который понимает систему в целом, в состоянии дать объектам имена, вписывающиеся в концепцию создаваемой системы. Если имя подобрано правильно, то всё стоит на своих местах, отношения между объектами ясны, значения легко угадываются и все человеческие мотивировки и ожидания срабатывают как хотелось бы. И если вы вдруг обнаружили, что все объекты вашего кода называются Фигня и Штуковина, то такой код вам стоит серьёзно пересмотреть.

Имена классов

  • Давайте классу имя тогда, когда вы знаете, что этот класс будет делать, как и для чего.
Если вы этого не знаете, то вполне возможно, вы не продумали до конца концепцию модуля;
  • Наличие имён, составленных более чем из трёх слов, может привести к тому, что
система будет путать различные объекты программы. Пересмотрите код программы. Прогоните код через контроль циклически избыточного кода CRC и посмотрите, не берут ли ваши объекты на себя больше задач, чем вы планировали;
  • Не поддавайтесь искушению присвоить производному классу имя производное от
имени родительского класса. Лучше будет, если класс будет жить своей жизнью, кто бы ни был его родительским классом;
  • Иногда помогают суффиксы. Например, если в вашей системе используются
различные агенты, то имя типа DownloadAgent несёт достаточную смысловую нагрузку;
  • В качестве разделителей слов используйте заглавные буквы, строчные – для остальной части слов;
  • Первая буква в имени – заглавная;

Никаких underscore-ов (‘_’).

Обоснование

Из всех других вариантов многие выбрали этот как лучшее компромиссное решение.

Пример:

class NameOneTwo
class Name

Имена методов

Как правило функция или метод совершают какое-либо действие, поэтому желательно, чтобы
из имени было понятно, какое именно действие будет совершаться: CheckForErrors()
[ИщиОшибки()] вместо ErrorCheck() [ПоискОшибок()]; DumpDataToFile()
[СваливайДанныеВФайл()] вместо DataFile()[ФайлДанных()]. Кроме того, так легче будет
отличить метод от класса.
Иногда помогают суффиксы:
  • Max – чтобы показать максимальное значение;
  • Cnt [count: количество, подсчёт] – чтобы показать текущее значение какого-либо
счётчика;
  • Key – чтобы показать ключевое значение. Например: RetryMax содержит
максимальное количество возможных попыток, а RetryCnt – номер текущей попытки;
Префиксы тоже иногда нелишни:
  • Is – для обозначения вопроса. Где ни встретится вам Is, вы всегда будете знать, что это
вопрос;
  • Get – получить значение;
  • Set – установить значение.

Например: IsHitRetryLimit() [примерно: это ли последняя попытка?].

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

Правильно: GetHtmlStatistic().

Обоснование
При формировании имён, содержащих сокращения, люди используют свои интуитивные
системы по-разному, поэтому лучше придерживаться единой стратегии формирования имён
для всех случаем и добиться тем самым предсказуемости именования. Возьмём, к примеру,
NetworkABCKey. Заметьте, что C от ABC и K от Key воспринимаются больше как буквенное
сочетание. В принципе, некоторые не возражают против аббревиатур целиком из заглавных,
другие же их просто ненавидят; так что в разным проектах люди придерживаются разных

стратегий.

Пример

function FluidOz() //а не FluidOZ
function GetHtmlStatistic() //а не GetHTMLStatistic
class NameOneTwo
{
    function DoIt() {};
    function HandleError() {};
}

Имена аргументов в методах

  • Первая буква – всегда строчная;
  • Все остальные слова в имени начинаются с большой буквы, как при именовании

классов.

Обоснование

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

Пример
class NameOneTwo
{
function StartYourEngines(&$someEngine, &$anotherEngine) {
$this->mSomeEngine = $someEngine;
$this->mAnotherEngine = $anotherEngine;
}
var $mSomeEngine;
var $mAnotherEngine;

}

Имена переменных

  • Используйте только строчные буквы;
  • В качестве разделителя слов используйте underscore (‘_’).
Обоснование
  • При таком подходе область действия переменных более уловима;
  • Все переменные кода выглядят по-разному и легко распознаются при чтении.
Пример
function HandleError($errorNumber)
{
$error = new OsError;
$time_of_error = $error->GetTimeOfError();
$error_processor = $error->GetErrorProcessor();

}

Имена элементов в массивах

  • Именование элементов массивов происходит по правилам именования переменных;
  • В качестве разделителя слов используйте underscore (‘_’);
  • И не используйте в качестве разделителя дефис (‘-’).
Обоснование
Если в качестве разделителя используется дефис, то при включении опции Magic Quotes вы

получите сообщения об ошибках.

Пример
$myarr['foo_bar'] = ‘Hello’;
print «$myarr[foo_bar] world»; // выведет: Hello world
$myarr['foo-bar'] = ‘Hello’;

print «$myarr[foo-bar] world»; // получим warning

Одиночные и двойные кавычки

Осуществляя доступ к элементам массива, можете использовать как одинарные, так и

двойные кавычки. Не используйте кавычки при включённой опции Magic Quotes.

Обоснование
За исключением случаев использования Magic Quotes, некоторые конфигурации PHP выдают

сообщение об ошибке, если при доступе к элементам массива кавычки опускаются.

Пример
$myarr['foo_bar'] = ‘Hello’;
$element_name = ‘foo_bar’;
print «$myarr[foo_bar] world»; // выведет: Hello world
print «$myarr[$element_name] world»; // выведет: Hello world
print «$myarr['$element_name'] world»; // parse error

print «$myarr["$element_name"] world»; // parse error

Глобальные переменные

  • В именах глобальных переменных рекомендуется использовать префикс ‘g’.
Обоснование

Такой префикс необходим для определения области действия переменных

Пример
global $gLog;

global &$grLog;

Имена функций

  • Для функций PHP используйте правила C GNU: имена из строчных букв с underscore-

ами (‘_’) в качестве разделителей.

Обоснование
Такой стиль позволяет делать различие между функциями и любыми именами, связанными с

классами.

Пример
function some_bloody_function()
{

}

Правила расстановки фигурных скобок

Из трёх существующих стилей расстановки фигурных скобок допустимы два, причём
первому рекомендуется отдавать предпочтение:
1. открывающая скобка ставится под соответствующим оператором и на одном отступе с
ним:
if ($condition) while ($condition)
{ {
… …

} }

2. Unix-стиль расстановки фигурных скобок, когда открывающая скобка ставится на
одной строке с соответствующим оператором, а закрывающая – на одном отступе с
оператором:
if ($condition) { while ($condition) {
… …

} }

Обоснование
Ещё одна религиозная война, где мир установился с принятием компромиссного решения.
Допускаются оба стиля, однако многие находят первый стиль более эргономичным и
эстетичным. Почему – это целая тема для отдельного психологического исследования.
Преимущество первого стиля заключается не только в психологии. Если вы используете
текстовый редактор (например, vi), поддерживающий проверку на парность скобок, первый
стиль будет более удобен. Почему? – спросите вы. Допустим, вы наткнулись на большой блок
кода и желаете узнать, где же он заканчивается. Наводите курсор на открывающую скобку,

жмёте нужную кнопку и редактор находит парную скобку.

Пример
if ($very_long_condition && $second_very_long_condition) //два очень длинных условия
{
…
}
else if (…)
{
…

}

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

открывающую скобку.

Правила расстановки скобок () рядом с операторами и функциями

  • Не ставьте скобки сразу за операторами. Разделите оператор и скобки пробелом;
  • Ставьте скобки непосредственно сразу за именем функции;
  • Не используйте скобки в блоке return, если нет в этом необходимости.
Обоснование
Операторы – это не функции. Если поставить скобки сразу за оператором, функции и

операторы будут выглядеть почти одинаково.

Пример
if (condition)
{
}
while (condition)
{
}
strcmp($s, $s1);

return 1;

Правила по отступам/табуляциям/пробелам

  • Отступ для каждого нового уровня – 3-4 пробела;
  • Используйте не табуляцию, а пробелы. Большинство редакторов в состоянии пробелы заменить табуляцией;
  • Делайте столько отступов, сколько вам нужно, но не более того. Если вы делаете отступ более, чем четвёртого-пятого уровня, стоит подумать о вынесении кода в отдельный блок.
Обоснование
  • Когда люди используют разные значения табуляции, код бывает невозможно
прочитать или распечатать, поэтому пробелы предпочтительнее;
  • Никто никогда не договорится об оптимальном количестве пробелов. Просто будьте
последовательны. 3-4 пробела – наиболее распространённое явление;
  • С того момента, когда люди вознамерились ограничить количество уровней отступа,
кажется, что ни разу они так ничего и не добились. Мы надеемся, что программисты

сами примут мудрое решение о достаточной глубине отступов.

<address><strong><span style="color: #333399;">function</span> func()</strong></address> <address><strong>{</strong></address> <address><strong><span style="color: #333399;">if</span> (something bad)<span style="color: #008000;"> //не подходит</span></strong></address> <address><strong>{</strong></address> <address><strong><span style="color: #333399;">if </span>(another thing bad)<span style="color: #008000;"> //тоже не подходит</span></strong></address> <address><strong>{</strong></address> <address><strong><span style="color: #333399;">while </span>(more input) <span style="color: #008000;">//ещё код</span></strong></address> <address><strong>{</strong></address> <address><strong>}</strong></address> <address><strong>}</strong></address> <address><strong>}</strong></address><strong>}</strong>

Форматирование блоков if then else

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

разный внешний вид условных блоков. Вот один из распространённых стилей:

if (condition) // Комментарий
{
}
else if (condition) // Комментарий
{
}
else // Комментарий
{

}

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

в лог.

Формат условия
При сравнении всегда ставьте константы слева.
Например:
if ( 6 == $errorNum ) …
Первая причина такому поведению – это то, что парсер найдёт ошибку, если вы поставите
только один знак равенства (‘=’) вместо двух. Вторая причина – при чтении кода вы находите
нужное вам значение сразу в начале условия, а не ищите где-то в конце. К такому формату

привыкаешь не сразу, но этот стиль действительно полезен.

Формат switch

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

внутри блоков case.

Пример
switch (…)
{
case 1:
…
// УПРАВЛЕНИЕ ПЕРЕДАЁТСЯ ВНИЗ
case 2:
{
$v = get_week_number();
…
}
break;
default:

}

Использование continue, break и ?:

Continue и break
Continue и break – это тот же самый goto, только названы по-другому. Именно поэтому они
рассмотрены в этой части документа.
Как и goto, continue и break творят всякие разные чудеса в коде, поэтому их использование
рекомендуется свести до минимума. Одним мановением руки читатель кода переносится бог
знает куда по какой-то незадокументрированной причине. При использовании continue
возникают две проблемы:
  • continue может обойти условный блок;
  • continue может обойти наращивание/уменьшение.
Пример
Представим себе ситуацию, где имеют место обе проблемы:
while (TRUE)
{
…
// Много кода
…
if (/* какое-то условие */) {
continue;
}
…
// Много кода
…
if ( $i++ > STOP_VALUE) break;

}

Note: «много кода» нужно для того, чтобы программист не смог легко
отследить проблему.
Из приведённого выше примера мы можем составить себе следующее правило:
использование continue и break в одном блоке – прямая дорога к багам.?:
Проблема обычно заключается в том, что люди пытаются запихать слишком много кода
между ? и :. Вот несколько правил:
  • Условие заключайте в скобки, тем самым отделяя его от остального кода;
  • По возможности действия, производимые по условию, должны быть простыми
функциями;
  • Если весь блок ветвления плохо читается, будучи расположен на одной строке, то

блоки else и then размещайте каждый на отдельной строке.

Пример
(условие) ? funct1() : func2();
or
(условие)
? длинный блок

: ещё один длинный блок;

Выравнивание блоков объявления

Переменных

Блок объявления переменных должен выравниваться

Обоснование
  • Прозрачность стиля;
  • Блоки инициализации переменных также рекомендуется выравнивать табуляцией;
  • Знак & должен ставиться при типе переменной, а не при её имени.
Пример
var $mDate
var& $mrDate
var& $mrName
var $mName
$mDate = 0;
$mrDate = NULL;
$mrName = 0;

$mName = NULL;

Несколько комментариев по комментариям

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

времени читателя о том, что именно вы сделали и почему.

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

выбрали и почему. Для археологов это станет самой полезной информацией.

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

больше не понадобится.

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

встроенные зарезервированные слова.

Формат описания gotchas

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

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

Пример
// :TODO: tmh 960810: возможны проблемы со скоростью работы
// Нам точно понадобится хэш-таблица, но пока
// мы используем линейный поиск.
// :KLUDGE: tmh 960810: потенциально небезопасное приведение типа
// Приведение понадобилось для восстановления производного типа. Возможно

// здесь понадобится виртуальный метод или шаблон.

Зарезервированные слова для описания gotchas

  • :TODO:
Означает, что здесь нужна доработка, простое напоминание.
  • :BUG: [id]
Означает, что здесь находится Выявленная ошибка, дайте описание и (не обязательно)
номер ошибки.
  • :KLUDGE:
Если то, что вы сделали, уродливо выглядит и работает, отметьте этот факт и
объясните, как вы поступите в следующий раз, если у вас будет время.
  • :TRICKY:
Сообщение о том, что данный отрезок кода очень сложен в исполнении и потому не
стоит ничего менять, не разобравшись предварительно во всех «коварствах»
конструкции.
  • :WARNING:
Предупреждение о чём-либо.
  • :P ARSER:
Иногда вам приходится что-то делать для успешного парсинга. Задокументируйте этот
факт. Возможно, со временем проблема исчезнет.
  • :ATTRIBUTE:
Общий вид представления атрибута в комментарии. Вы можете создать свои

атрибуты, и они тоже будут извлечены роботом.

Документация интерфейсов и реализаций

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

кода программы.

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

главу из технического руководства.

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

реализации должны предоставить ещё более подробную информацию.

Документация по директориям

В каждой директории проекта должен находиться файл README с описанием следующих
моментов:
  • Зачем была создана данная директория и что она содержит;
  • По строчке описания каждого файла этой директории. Как правило, описание берётся
из значения атрибута NAME в заголовке файла;
  • Инструкции по сборке и установке;
  • Ссылки на связанные источники: директории исходников, online документация,
документация на бумажных носителях, документация по разработке;
  • И всё, что как-либо может помочь.
Представьте себе, что полгода после ухода последнего из зачинателей проекта в команду
приходит новый человек. Этот одинокий и напуганный странник должен по кусочкам
собрать и воссоздать полную картину проекта, пройдясь по директориям исходников и

прочтя все README, make-файлы и заголовки в файлах исходников.

Повторное использование кода

Повторное использование кода за пределами одного проекта практически невозможно, если у
вас нет разработанного проектного каркаса [framework]. Объекты строятся в соответствии с
предоставляемыми сервисами. В разных проектах разные наборы сервисов, что и усложняет
повторное использование объекта.
Разработка проектного каркаса отнимает много сил и времени. Но даже если по каким-то
причинам вы не создали себе подобной системы, существует несколько приёмов поощрения

повторного использования кода.

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

использованию, библиотеки недолго остаются маленькими.

Держите свою базу библиотек [репозиторий]
Большинство компаний не имеет никакого понятия, какой код у них есть. И большинство
программистов до сих пор не сообщают о том, что они сделали и не интересуются тем, что
уже написано. Репозитории призваны изменить ситуацию к лучшему.
В идеальном мире программист мог бы зайти на сайт, посмотреть по каталогу или поиском
найти нужный пакет библиотек и закачать себе. Если вы можете наладить такую систему, в
которой программисты на добровольной основе будут поддерживать базу исходников – это
прекрасно. Если вы заведёте библиотекаря, который отслеживал коэффициент повторного
использования, то это просто роскошно.
Другой способ – автоматическая генерация репозитория из исходников. Достигается
подобный эффект через использование стандартных заголовков для классов, методов,
библиотек и различных подсистем. Такие заголовки служат одновременно техническим

руководством и пунктами в списке репозитория.

Временное комментирование больших блоков

Иногда при тестировании возникает необходимость закомментировать большой блок кода.
Самый простой способ – это заключение блока в конструкцию if(0):
function example()
{
роскошный код
if (0) {
много кода
}
ещё больше кода

}

Комментарии /**/ вы использовать не можете, потому что комментарии не могут содержать
комментарии, а большой блок вашего кода непременно будет содержать комментарии, ведь

так?