Это не вопрос, а скорее крик души.
Месяца два с половиной, в свободное от работы время, мучаю проект. И вот, похоже, настал конец терпению.
Чем больше разбираюсь в этом коде, тем больше хренею (другое слово не подберешь).
Яркий пример того, как не надо писать.
По порядку:

1. Видимо, все знание автора об отличиях С от С++ сводится к наличию единственного класса, единственный экземпляр которого инстанцирован в структуру(!), что само по себе нормально, за исключением того вопроса на фига это там было нужно, для меня так и
осталось загадкой.

2. Догадайтесь как обстоят дела с выделением памяти? Именно, незабвенный malloc. По некоторому стечению обстоятельств, функций free я обнаружил меньше :\

3. С потоками такая же напряженнка, как и с выделением new. #include <stdio.h> и точка, нафиг нам стримы?

4. Собственно от чего я сегодня опупел - static-функции вне класса. Честно сознаюсь, никогда так не извращался, посему тот факт, что я её фиг увижу за пределами единицы трансляции поверг меня в уныние. Нэймспейсы, видимо, отменили специально для "аффтара". Для чего это вообще делалось, так и не понял.

5. Об RTTI тоже автору ничего не известно. Следствие - около полусотни варнингов об опасном присваивании при компиляции.

6. Никакого намека на STL. Я, конечно, рад что в программе так классно реализованы операции с массивами, массивами указателей, массивами указателей на указатели, указателями на массивы указателей на указатели. Но, блин, чтоб выбрать элемент по имени,
мне перебор прикажете делать?

7. Отдельная песня - это имена переменных и функций. Ни один шпион не догадается. Если комменты не прочитает. Вот только комменты в .h, а нужно работать с реализацией.
Вот как вы думаете, зачем нужен следующий код:
void stdexitcls(char s, float pt, float sl, int bth)
{ sexord=1; sexi=s; sexpt=ptt(pt); sexsl=ptt(sl); sexbrs=bth; };
Вот я тоже не телепат. Смотрим объявление, например:
char sexi; // standard exit id
Вот ведь, блин, а я уж было подумал... Оказывается sexi и отношения к сексу не имеет, разве что церебральному.

8. Вернёмся к классу. Убедившись, что править что-то в этом коде сродни подвигам Геракла, вместе взятым есессно, решил воспользоваться одним из базовых столпов ООП - полиморфизмом. Унаследовал класс, написал свою реализацию нужных мне методов, а вот не переопределенные методы вдруг перестали работать. Удивительно? А мне нет. Те члены класса, которыми они пользуются были объявлены в приватной секции, а совсем не protected.

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

Были ли у вас такие подлянки? Как мне дальше разгребать?

С чем я встречался:
9. Переопределение оператора new/delete -- руки отрывать.
10. switch на 10 вариантов.
11. Функции принимающие 10 (да-да, 10) параметров.

Если там всего 1000 строк лучше переписать к чертям собачьим, такое и рефакторить низзя.

Ну это я сильно поскромничал, 1000 строк - это только та часть, с которой я работаю, даже, наверное 1500-2000 будет точнее, остальное было скомпилено в либы и благопулучно забыто. Общее количество строк в проекте (только .cpp и .с файлы, без учета хидеров) 14 225. Если это дело реверсить, то придется поднимать всё. А мой неокрепший организм такого мазохизма не вынесет...



Фунция, на которой я споткнулся в п.4 принимает 13 параметров.


Здесь я натыкался на switch из 25-27 вариантов, хотя ИМХО это не страшно. Если задача отправить мессагу об ошибке, то самый приемлимый вариант.

Пинать. Аффатру явно забыли сообщить что имена переменных можно делать из >6 символов и читабельными




+1
Верни это на ту помойку из которой..... на родину вообщем.






а как же map<ErrorID, string> и exception::what()?

Посыпаю голову

ЗЫ кстати, exception отсутствует, зато есть глобальная функция FatalError. С однозначной реакцией умереть нафик, даже если это не нужно.

если ты разгребаешь opensource код, то это типичная ситуация
а вообще, хочется всем пожелать побольше внимания уделять комментариям !!!

Что делать:
если исходный код работает правильно, лучше его не трогать, а написать свой фасад или адаптер. Причем сначала спроектировать интерфейс, не глядя в это г., а потом попробовать реализовать его.

Если неправильно - забыть про него совсем и переписать.

Часто на работе сталкиваюсь с такими комментариями одного товарища:
1. // Пока не конец.
2. // В массив.
3. // Составляем запрос.
4. // Всё...

и т.д. И ни одного толкового комментария. Лучше вобще их не писать тогда .

Работает правильно.


Вот это я и делаю, но в процессе приходится выяснять логику, тут и начинается свистопляска.


Очень ценное замечание. Спасибо, так и поступлю.


14 тыс строк?

Не факт, что в результате будет столько же.
Но поскольку

то, конечно, лучше не трогать, не смотря на

А кому сейчас легко?

Earnest, а если надо что-то изменить в поведение этой функции? А рефакторинг провести нереально?

Мы живем не в идеальном мире, рефакторинг нужно проводить только когда его нужно проводить а не просто потому-что так хочеться (ну если конечно, у тебя это не хобби)

Есть прикольная книженция о том, как желательно оформлять исходный код программ.
Вот только не нашел как тут файлик присоеденить, так что если кому нужна (она небольшая *.doc),
могу скинуть или выложить где скажите

, а файл ресурсов?

, иногда в *.dll для независимости от клиента приходиться писать и больше, так что это в зависимости от задачи, на мой взгляд;

12) Hard Code (сообщения, числа и.т.д.);
13) Non Const Global Variable (просто бесит что вместо стека используется глобальная свалка - функциональное программирование);
14) Memory Leak (только стратегия владения и сборка мусора);
15) Native Implementation Dependence (бесит, когда пишут код зависимый от реализации);

Это сообщение отредактировал(а) np9mi7 - 21.3.2006, 13:38