lazaryan / oaip_var9 Goto Github PK

1. Проверьте отступы, межстрочные интервалы и т.п.

2. Заключение должно выходить из цели работы

1. см https://github.com/lazaryan/OAiP_labs_Lazaryan/issues/11

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

А так же если основные функции логики программы вызывались именно из главной, а не запускали за собой дальнейший цикл вызовов. Тогда глядя на функицию мы понимает что она делает и делает она только что-то одно, а не массу доплнительного:)

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

Есть такое понятие как детерминизированные и чистые функции, очень близко к тому о чем у нас речь
https://habrahabr.ru/post/149086/

main сейчас выглядит так

main() {
    Открыли файл для чтения
    Открыли файла для записи
    проверили файл для чтения()
    считали файл()
}

эммм... у любого программиста читающего код, возмникнет вопрос, а что же дальеше?

main() {
    Открыли файл для чтения
    Открыли файла для записи
    проверили файл для чтения()
    если его нет вышли()
    объявили строковую переменную 
    считали файл в эту переменную()
    создали массив строк
    записали в массив все найденные строки()
    вывели массив строк в файл()
}

1. Тут очень большую часть программы занимает проверка на корректность, и наличие этих проверок - это замечательно! Значит Вы отлично понимаете, что пользователь может дать на вход практически что угодно и нам как программисту никогда нельзя выпускать ситуацию из под контроля:)

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

В основной программе оставляем логику работы, а функции вызываем по мере необходимости

2. Неплохо бы дать пользователю возможность самому задавать имя файла вместо использования предустановленного

#define SOURCE_FILE		"SourceFile.txt"

Можно сделать это в консоле прямым запросом, можно передать в качестве параметров функции main()

3. CheckSourceFile - именование функций

4. for (i = 0; StringText[i]; i++); - нагляденее хоть и не так компактно будет если использовать while
   а переменную назвать соответсвенно lenght

кстати, а зачем вообще понадобилась такая функция, если есть strlen ?

5. FormRequest - тут придирка к имени, начинаем с глагола, к тому же тут же не происходит реально никакого запроса. тут просто выводится меню
   так и назовем функцию showMenu
   чем проще, тем лучше

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

int СhoiceRequest(int max) {
	int	request = 0;
	bool	error = true;

	do {
		scanf("%d", &request);

		if (getchar() != '\n') {
			printf("Ошибка ввода. Повторите попытку: ");
			while (getchar() != '\n');
		}
		else (request < 1 || request > max) ? printf("Ошибка. Данный запрос отсутствует. Повторите попытку: ") : error = false;

	} while (error);

	return request;
}

всегда думаем о том как наш код будет читаться

7. EnterStructs() - тут лучше бы мы не открывали никаких файлов, а передали бы в нее уже открытый файл из главной функции

EnterStructs()
и
EnterStruct(); - очень легко запутаться в названиях и начать потом ненароком править не то

8. EntryFile - не совсем явно из названия что тут проихсодит

может быть лучше что-то вроде
printCarInFile()

9. FormStructTex, делает почти тоже самое FormRequest
   лучше расположить их в коде рядом
   и назвать похоже и начинающимися с глагола вместо существительного

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

по баллам, тут достойно и на 4/4

но пока поставлю 3/4 чтобы больше мотивации для доработки))

Есть еще идея как всю эту штуку сделать более красивой. Но и это будет не очень легко

Отдельный заголовочный файл с функциями проверки данных пользователя (validation.h)
Отдельный заголовочный файл, где будут объявляться функции с различными меню, сообщениями об ошибках и тому прочему (user-interface.h)
Главный файл с основной логикой работы, который вызывает нужные функции из заголовчных