Базовые принципы при работе для разработчика

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

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

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

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

4. В теле функций (метода класса) сначала необходимо написать комментарии, а потом уже вставлять соответствующие блоки кода после каждого комментария.

Пример:

function ConvertVideo( $params, $path ){

if( strLen( $path ) <= 0 ) return "";

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

preg_match( "/width\=([0-9]+)/is", $params, $width );

preg_match( "/height\=([0-9]+)/is", $params, $height );

$width = intval( $width[1] );

$width = ( $width > 0 ? $width : 400 );

$height = intval( $height[1] );

$height = ( $height > 0 ? $height : 300 );

// Включение буферизации ввода. Вызов компонента медиаплеера с // подготовленными входными параметрами

ob_start();

this->MakeVideoStream( $path, $width, $height );

// Сохранение полученного медиапотока из буфера вывода. Выключение // буферизации вывода

$video = ob_get_contents();

ob_end_clean();

return $video;

}

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

6. Всегда понимать (и писать в комментариях) какие пред- и пост-условия необходимы для работы той или иной части приложения.

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

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

9. Слишком большое расстояние между комментарием и описываемым блоком сводит на нет полезность комментария.

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

11. Комментарий не должен описывать очевидные действия программных операторов.

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

Пример:

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

// Формируем ширину выходного видеопотока

$width = intval( $width[1] );

// Накладываем ограничение на ширину выходного видеопотока

$width = ( $width > 0 ? $width : 400 );

// Формируем высоту выходного видеопотока

$height = intval( $height[1] );

// Накладываем ограничение на высоту выходного видеопотока

$height = ( $height > 0 ? $height : 300 );

правильно писать так

// Формируем ширину и высоту выходного видеопотока

// При этом накладываем ограничение как на ширину , так и высоту

$width = intval( $width[1] );

$width = ( $width > 0 ? $width : 400 );

$height = intval( $height[1] );

$height = ( $height > 0 ? $height : 300 );

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

Примеры:

                   while( $i > 0 ){
                    Dec( $i );
                    Func( $i );
             } // while( $i > 0 )

             if( $a > $b ){
                    while( $i > 0 ){
                           Dec( $i );
                           Func( $i );
                    } // while( $i > 0 )
             } // if( $a > $b )

14. Весь код функции должен помещаться на экране монитора в целях обеспечения простоты ее отладки. Если функция/метод не помещается на экране, ее нужно разбить на несколько более маленьких.

15. Максимальная длина одной строки код должна составлять не более 80 символов.

16. Использовать пробелы. Пробел надо ставить за знаком препинания, операцией [+,-,*,/,(,),{,},=,==,!=,&,&&, |, || и пр.].

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

Пример:

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

if( $bRightTerms ){// Формируем ширину и высоту выходного видеопотока

// При этом накладываем ограничение как на ширину , так и высоту

$width = intval( $width[1] );

$width = ( $width > 0 ? $width : 400 );

$height = intval( $height[1] );

$height = ( $height > 0 ? $height : 300 );

}

правильно писать так

if( $bRightTerms ){

// Формируем ширину и высоту выходного видеопотока

// При этом накладываем ограничение как на ширину , так и высоту

$width = intval( $width[1] );

$width = ( $width > 0 ? $width : 400 );

$height = intval( $height[1] );

$height = ( $height > 0 ? $height : 300 );

}

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

19. Имена функций/методов должны быть английскими словами, описывающими действие.

20. Локальная переменная всегда лучше, чем член класса. Член класса всегда лучше, чем глобальная переменная.

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

22. Функция/метод должна решать только одну задачу.

23. Большое количество уровней абстракции так же плохо, как и маленькое. Если сделать все функции/методы по 5-6 строк, программа будет также плохо читаться, как и с функциями/методами в 200-300 строк.

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

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

26. Более короткий блок конструкции if необходимо помещать сверху. Это очень важно при отладке.

Пример:

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

if( $bRightTerms ){

$width = GetCurrentWidth();

$width = ( $width > 0 ? $width : 400 );

$height = GetCurrentHeight();

$height = ( $height > 0 ? $height : 300 );

}

else{

ErrorGeneratedFunction();

}

правильно писать так

if( !$bRightTerms ){

ErrorGeneratedFunction();

}

else{

$width = GetCurrentWidth();

$width = ( $width > 0 ? $width : 400 );

$height = GetCurrentHeight();

$height = ( $height > 0 ? $height : 300 );

}

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

28. В операторе switch обязательно должен присутствовать блок default.

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

Пример:

код

reset( $arHashLink );

while( list( $hash, $arData ) = each( $arHashLink ) ){

}

лучше переписывать в таком виде

foreach( $arHashLink as $hash => $arData ){

}

30. Сообщение об ошибке должно точно подсказывать, как ее исправить.

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

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

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

34. ООП не панацея. Там где неприменимы уровни абстракции, полиморфизм, наследование – использование ООП нельзя.

35. Необходимо избегать доступных полей объекта. Для необходимо доступа необходимо использовать функции/методы.

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

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

38. Базовые классы должны порождать более одного производного класса.

39. Возможности, определенные в базовом классе, должны использоваться всеми производными классами.

40. Стараться не строить глубокую иерархию классов.

Назад в раздел

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

Загрузка...