Вопрос с целью самопросвещения. Как оформить код так, чтобы он выглядел грамотно (профессионально) оформленным. Думаю "грамотно" это тогда , когда написание кода подразумевает: - 1 Включение реакции на все возможные значения по GetLastError() - 2 Завертывание всех критичных участков (работа с памятью к примеру)в SEH-обертки - 3 Внимательное обнуление - перед использованием и освобождение после - используемой памяти Я прав или еще что-то ?
почитайте "С++ in-depth" Страуструпа, или этоже в русском варианте "Стандарты программирования на С++" Герб Саттер и Андрей Александреску
_sheva740 Нужно стараться, чтобы ошибки вобще не возникали, а не делать обработку их всевозможных вариантов. Множество try это признак как раз плохого кода.
Booster Если система работает со сторонними даннами, которые формируется кем попало и как попало, что тут поделать? Без кучи проверок на входе, имхо, не обойтись.
Пишы так, чтобы только ты его понимал и все глупые, коих по статистике 98%, будут считать тебя очень умным. Например: разбивает код в 10 килобайт на 8 модулей, обьявляешь переменные всегда не в тех модулях, в которых они используются, в именах переменных - побольше символов @,&,_,, желательно чтобы они были вперемешку... Самое главное - код должен быть таким, чтобы его невозможно было откомпилировать, а пути к библиотекам - всегда должны быть "не совсем обычными", придумай сам чегонить... разумеется небольшие ошибки и опечатки - необходимы, но в меру, компилятор не должен выдавать конкретной информации, например - забыл сделать VISIBLE ... типа этого, не ставить ret для выхода из функции - это дурной тон. Хорошие результаты даёт применение локальных переменных в тех случаях, когда функци не работает, если переменная - локальная.
Чем больше знаков подчеркивания перед именем функции/переменной тем круче программист ее писавший. Видел до 7 знаков "_"
1) masm поддерживает длину имени переменной до 200 символов поэтому называй свои переменные так, чтобы отличия начинлись где-то с 150-ого символа 2) имена меток дложны иметь сквозную нумерацию во всем проекте, типа a890012345, a890012346, ... не отступай от этого 3) ничего не комментируй -- через два-три дня сам забудешь чё там написано 4) по-чаще делай jmp из тела процедуры "наружу", а также переходи из главной программы внутрь процедуры по jmp/jcc 5) самое главное -- "забей" на ЯП -- пиши все в машинном коде, нафига нужны все эти компиляторы
