Технологии программирования. Ошибки, тестирование
Типичные ошибки программирования.
Использование необъявленных переменных
int main()
{
cin >> y; int y;
cout << y;
}
Допустим, вы написали этот код, компилируете программу и тут компилятор сообщает об ошибках. и тут у вас возникает вопрос: «Почему я получаю сообщение об ошибке?». Ответ предельно прост: «Ваш компилятор не знает, что означает y. И перед тем как использовать y, вы должны объявить его как переменную». Ниже показан код, в котором исправлена данная ошибка.
Использование неинициализированных переменных
int ct;
while(ct < 100)
{
cout << ct;
}
Мы объявили переменную ct, но не инициализировали начальным значением, значит там содержится какое-то значение — мусор. Оно может быть огромным или очень маленьким. Поэтому могут быть два случая:
если значение ct меньше 100, то программа попадет в цикл;
чаще всего ct огромное число, поэтому скорее всего программа не попадет в цикл.
Инициализация переменной мусорным значением
int num1, num2;
i
nt
sum = num1 + num2;
cout << "Введите два числа для суммирования: ";
cin >> num1;
cin >> num2;
cout << "Сумма = " << sum;
Часто начинающие программисты считают, что переменные и выражения работ — это как уравнения — если присвоить переменной результат операции с несколькими другими переменными (num1, num2, в данном примере), которые изменятся позже, предполагают, что значение переменной тоже изменится. C++ не работает таким образом! В примере программы, num1 и num2 не инициализируются перед выполнением операции сложения, поэтому сумма будет равна случайному значению.
Использование одного знака равенства для проверки равенства
char ch = 'Y';
while(ch = 'Y') ==
{
//какой-то код
cout << "Продолжить? (Y/N)";
cin >> ch;
}
Если вы используете один знак равенства для проверки равенства, ваша программа будет вместо сравнения, присваивать значение в правой части выражения, переменной в левой части. В этом случае, значение 'Y', которое рассматривается как истинное всегда будет присваиваться переменной ch. Таким образом, цикл никогда не закончится. Используйте == для проверки равенства, кроме того, чтобы избежать случайного присвоения, поменяйте местами переменную ch и значение 'Y'. Так, вы получите ошибку компиляции, если случайно использовали один знак равенства, поскольку вы не можете присвоить значение тому, что не является переменной.
Необъявленная функция
int main() void print();
{
print();
}
void print()
{
//что-то печатаем
}
Компилятор не знает, что такое print(), так как определение функции print выполнено после main и не объявлен прототип. Всегда помните, нужно указать либо прототип функции, либо все определение функции выше строки, в которой будет вызов этой функции.
Лишние точка с запятой
Точка с запятой не ставится, после определения, циклов, или функций. Если вы случайно поставите точку с запятой в любом из этих мест, ваша программа будет работать некорректно.
Нарушение границ массива
int array[10];
//код...
for(int ix = 1; ix <= 10; ix++) ix=0; ix < 10;
cout << array[ix];
Элементы массива индексируются, начиная с 0, а значит, общая длинна на 1 меньше. Например, если у вас есть десять элементов массива, первый элемент находится в положении нуля, а последний элемент в позиции 9.
Тестирование. Программа, которая не прошла тестирование, не работает. Идеал, чтобы после проектирования программа заработала с первого раза, недостижим для всех, за исключением самых тривиальных программ. Следует стремиться к идеалу, но не заблуждаться, что тестирование простое дело. "Как проводить тестирование?" - на этот вопрос нельзя ответить в общем случае. Однако, вопрос "Когда начинать тестирование?" имеет такой ответ - на самом раннем этапе, где это возможно. Стратегия тестирования должна быть разработана как часть проекта и включена в реализацию, или, по крайней мере, разрабатываться параллельно с ними. Как только появляется работающая система, надо начинать тестирование. Откладывание тестирования до "проведения полной реализации" - верный способ выйти из графика или передать версию с ошибками. Если вопросы тестирования полностью игнорируются на этапе проектирования, возникнут проблемы с тестированием, временем поставки и сопровождением системы.
Трудно определить необходимый объем тестирования. Однако, очевидно, что проблему представляет недостаток тестирования, а не его избыток. Сколько именно ресурсов в сравнении с проектированием и реализацией следует отвести для тестирования зависит от природы системы и методов ее построения. Однако, можно предложить следующее правило: отводить больше ресурсов времени и человеческих усилий на тестирование системы, чем на получения ее первой реализации.