Комментарии 38
А какова ценность этой публикации для читателей хабра (ну, кроме демонстрации нескольких хорошо известных ошибок)?
Ну всё, пиццот тыщ в час можно заколачивать
Вот, примерно такие лабораторные у нас на 1 курсе были больше 20 лет назад...
И то народ в основном GUI пытался прикручивать, или на борланде, или на дельфи.
Ну я такое же писал на просто C лет 30 назад. А, и ещё переписал на паскаль, и с турбо вижн сделал gui. Это вроде курсач был, потому два языка. И да, все разделы на месте, даже заключение с тем на чем было писано, и строк сколько. Но сама идея публиковать нечто со структурой аналогичной курсачу это дааа. Антиплагиат передаст привет всем сдающим после этого нетленного произведения )
"Для реализации полноценной работоспособности моей программы необходимо создать несколько текстовых файлов и директорий согласно диаграмме" если это нужно делать вручную, то хотябы только поэтому уже нельзя назвать программу полноценной, если я верно вычитал смысл из заголовка. Ну и вообще с++ не учится за 3-4 месяца. Достаточно 21 день. Попробуйте перечитать вашу статью еще месяца через 3 или 4.
Рекомендую рассмотреть более аккуратное и развернутое именование сущностей как альтернативу комментариям
P.S. Схемы это хорошо
А полноценная программа - это какая? Вывод "Hello World!" - это полноценная программа или нет?
Где классы, тесты? Разбиение проекта на файлы? Или сейчас так уже не пишут?:)
В первом алгоритме у вас два конца. Так не полагается делать.
Ну и конечно делать из курсача статью на таком ресурсе - перебор.
Кстати, классический UNIX-way.
Составляем файл ответов и ./proga < answers.txt
Совершенно не "юзерфрендли"... Представьте учителя что сидит и с командной строкой взаимодействует)
Внимание! Количество условных конструкций, уровней вложенности и строк в методах многократно превысило допустимый предел. Срочно пройдите в ближайший биореактор на утилизацию!
Пустил скупую слезу! А ведь не ведает молодежь своего счастья, что есть в C++ нормальные строки из коробки, воспринимает как данность )
А зачем блок-схемы в разных масштабов? И главный алгоритм некорректно немного изображен. Радует, что есть молодежь, которая не лепит сразу что попало, а хотя бы думает. Разработка - это про думать, а не на клаве клацать.
Отлично, теперь надо сделать защиту от злостных хацкеров, так и норовящих удалить текстовые файлы со всей нереально важной информацией, хотя с такой мощной субд как .txt опасность может быть только в реальной жизни, потому что такой крутой инструмент мировой важности может привлечь самые опасные мафии мира
Бессмысленные комментарии типа "объявление переменной типа bool".
Бессмысленные названия переменных.
Неструктурированная логика, смешанная с данными, хтонические бойлерплейты непонятных условий.
Спасибо, было больно.
Интересно услышать комментарии Вашего препода, но ошибок и "то как делать не надо" много, поэтому хочется их просто перечислить, чтобы исправили.
Зачем писать комментарии к переменным типа "переменная типа string" ? Это каким-то образом несет смысловую нагрузку ?!
Именование переменных не очень. choice, choice2 и т.д. а по факту в первую попадает дата, во вторую комментарий. А почему не назвать input_date и input_comment ?
Ввод от пользователя никак не обрабатывается, к примеру сразу на основе choice создается путь до файла. А что если туда ввести "..\\..\\Users\\..." можно прочитать/затереть какие-нибудь файлы пользователя ?!
fin.close() надо делать в блоке if (fin.is_open()) когда файл реально открыт, а иначе он и не открыт вовсе.
Зачем сделана куча if (choice == "X"){ ... }. Вас не учили switch/case ?
Если используете bool, то уже и пишите true/false а не 0/1 иначе для чего ?
Во всем мире путь до файла называется path, а у вас way :)
Класс без методов это struct, или это задел на будущее ?
Длинные строки вырывают глаза (все переменные std::string для пути к файлу уехали за скрол). У меня на работе так быдлокодят, задолбали oneliner'ы на килобайт, поубивал бы.
В условном блоке лучше вообще кидать эксепшн, чтобы мы даже не пытались ни закрыть ни прочитать файл, который не получилось открыть, а перешли бы сразу в конец. Покурите автоматические указатели как раз.
5. Зачем сделана куча if (choice == "X"){ ... }. Вас не учили switch/case ?
Разве C++ позволяет строки в switch/case? Насколько помню, там только целые и enum-ы можно.
Никто не мешает распарсить string в int, заодно проверить корректность ввода пользователя.
Либо на крайний случай делать так:
if (choice == "1") {
// case 1
} else if (choice == "2") {
// case 2
} else if (...) {
//....
} else {
// default
}Иначе в текущем варианте каждый раз придется разращивать if, который должен отрабатывать смысл default
Самое полезное - это наличие схем. То есть тех.задание продумано и поставлено.
А реализация - переделайте на GUI, сделайте действительно полноценную программу.
И если нет текстовых файлов, то можно же прикрутить инициализацию, чтобы пользователь не парился ?
НЯП, в начале работы нужно ввести ФИО (зачем??), логин и пароль. Если же пароль неизвестен - можно посмотреть в файле, правда же?
Можно делать программы с GUI. Можно делать многопользовательские системы. Можно использовать готовые базы данных. А то, что у вас получилось - это что-то в стиле 70-х, но на С++.
Муд: 1-й курс любой специальности с программированием, курсовая
Люди в комментариях больно много душнят. Я понимаю, что вы все опытные программисты и всё такое, но чувак сам пишет, что программирует 3-4 месяца и попробовал написать что-то довольно большое впервые, поэтому относиться к его посту с полной серьёзностью, мол "а я вот могу написать программу получше, с тестами и классами" – это просто смешно.) Как-будто вы в своё первое полугодие программирование уже идеально знали большинство его составляющих и паттернов
Скажем так, я в свое первое полугодие не выкладывал свои творения на Хабр.
Зачем это здесь?
но чувак сам пишет, что программирует 3-4 месяца и попробовал написать что-то довольно большое впервые,
а зачем тогда выкладывать это на хабр ? Чтобы что ?
А то получается из серии - посмотрите как я провел лето
Ну, если уж, тогда для досовского интерфейса лучше использовать такое:1. Поставить оценку
2. Авторизироваться
3. Выйти из программы.
... ,
а не "Если вы хотите ...".
Такая форма "общения" намного короче и понятнее бóльшему числу пользователей, потому что они наверняка пользовались USSD при общении с мобильным оператором.
Мне понравилось, что вы, перед тем, как писать код, потратили время на проектирование программы. Это полезная привычка, её стоит сохранить.
Попробуйте подумать, какая типовая, повторяющаяся, функциональность есть в вашей программе. Например, запись структурированных данных в файл и чтение из файла. Такие задачи уже решены много раз до вас. Существуют готовые библиотеки для сериализации.
Вообще, подход с чтением файла при каждом вызове функции очень неэффективен. Диск - самая медленная память на вашей машине. Так как объем данных, с которыми вы работаете, невелик, лучше сразу загрузить их все в память, сохранив в такую структуру данных, которая позволяет легко искать. А при внечении изменений можно записывать её целиком в файл. Или записывать по команде и при выходе из программы.
Я бы на вашем месте использовал формат JSON, так как он поддерживает структурированные данные и легко читаем человеком при надобности. Посмотрите на библиотеку nlohmann::json, например.
Замечания по коду:
Как уже отмечали другие, имена переменных можно улучшить. Например, переменные
flag,flag2в функции авторизации, судя по логике программы, лучше подходитloginFoundилиisLoginFoundиloginExists. Имена типаflagничего не говорят об их назначении и вы сами забудете, что к чему через пару недель.Следите за грамматикой, проверяйте русское и английское правописание. Teature, dedlin, Authon -- это очень трудно читать.
Ваши функции получились очень длинными, и каждая из них содержит операции чтения и записи в файл. Если вы последуете советам в начале комментария, то эту часть логики можно будет из функций выкинуть, и они станут гораздо проще и компактнее. Как минимум, подумайте о том, чтобы вынести повторяющиеся операции в отдельную функцию.
Попробуйте освоить pdCurses, можно делать вполне симпатичные псевдографические интерфейсы для приложений командной строки.
Нет диаграмм по idef0.
Манагеры с говном сьедят,а на код всем сейчас похер.
Авторизацию (Authon)
Authon - очень неудачное сокращение. Лучше написать полностью.
Названия всех функций - существительное. Это неправильно. Должны быть сказуемые, то есть, действия.
DataofTeacher (а не Teature) - почему of с маленькой буквы? И вообще, лучше просто TeacherData или даже Teacher, Student,...
Reg - очень неудачное название функции и вообще чего-либо, так как непонятно, что она делает. Register - гораздо лучше.
Хорошая статья. Успехов вам в дальнейшей учёбе:)
P.S
Не обращайте внимание на комментарии типа "30 лет назад я такое на Си писал..." :)
Увидел много замечаний от товарищей по самому коду, так что об этом писать не буду. Хотелось бы обратить внимание автора статьи на одну огромную ошибку. Вы совмещаете бизнес-логику и UI. Придираться к тому, что само приложение в консоли, я не собирался, но логика приложения прочно связана с UI (выводом в консоль). Это находится даже не в одном классе, а в одном методе.
Если бы Вы вынесли логику приложения в отдельный компонент, то у Вас была бы возможность в будущем использовать написанный код и в приложении с полноценным UI.
Раз уж Вы находитесь на начальном этапе изучения программирования, я не прошу сразу вас вникать в архитектурные паттерны и учить MVC/MVVM и т. д. Но если получилось бы разделить консоль и логику, даже с таким уровнем написания кода это выглядело бы как действительно полноценное приложение.
А как отсюда штатно выйти не введя ничего? Ну например по SIGINT или какому-то ещё сигналу от операционной системы? Или например если вы создадите многопоточное приложение и главный поток решит, что нужно прекратить ожидание ввода, то как штатно выйти из этого while?
while (!fin.eof())
{
std::getline(fin, data); //вывод а экран полного списка групп
std::cout << "\t\t\t" << data << "\n";
}
Первый опыт написания полноценной программы