Достался мне в наследство от предыдущего программера код игры. И не просто код, а КОД, т.к. программер этот работает в компании SOT. Ничего не имею против компании — их линух (ранее скромно называемый BestLinux) хоть и кривоват немного, но вроде даже — по дошедшим до меня слухам — работает.
Так вот, КОД. Плоский, полностью монолитный, написанный почти на чистом C, без форматирования, с непонятныым разделением на заголовочные/исполняемые файлы, с кучей глобальных переменных и, наконец, подразумевающий только правильное поведение пользователя.
1) Плоский — значит его с таким же успехом можно было бы вписать в функцию main() целиком, т.к. разбивка на функции чисто условная, не говоря уже об отсутствии ОО декомпозиции. Ну ещё функции присутствуют там, где без них никак нельзя было обойтись, например callback обработчики элементов gui. Кстати, было бы намного понятнее, если бы он и был написан полностью в одной функции, т.к. см. пункт 2.
2) Монолитный — значит при выполнении функции foo(), определённой в строке 1128 файла map.cpp, подразумевается, что она вызывается из пятой строки функции bar, определённой в строке 2357 файла game.cpp, и что до неё будет инициализирован массив m[MU] из строки 579 файла struct.h. Писал он код много месяцев, щедрой рукой разбрасывая куски вставленные Copy/Paste, слегка их редактируя. В итоге получилось аж 250 КБ чистого кода (это практически без пробелов и комментариев).
3) почти на чистом С — значит на С компиляторе он уже не скомпилируется, т.к. структуры уже используются без ключевого слова struct, однако ни одна фича С++ больше не используется.
4) без форматирования — т.е. примерно в таком стиле:
5) с неверным разделением на файлы — т.е. функция объявляемая в struct.h определена в units.cpp, а в файле game.h содержатся определения переменных и структур, поэтому включать этот файл, кроме как в game.cpp, никуда нельзя.
6) с кучей глобальных переменных с одно- и двухбуквенными именами, причём без комментариев насчёт того, что же это за массивы и переменные. Из однобуквенных имён, локально можно использовать x,y,z и i,j,k, не боясь, что они перекроют какие-то глобальные имена. Про остальные сказать точно нельзя. При этом, однако, почти все локальные переменные, цедро разбавленные неиспользованными переменными, имеют однобуквенные имена.
7) подразумевающий правильное поведение — т.е. подразумевающий, что пользователь нажмёт кнопку или выберет пункт меню только тогда, когда он имеет право это делать. Иначе программа вылетит, потому что ни одна процедура обработки не проверяет состояние глобальных переменных (разнообразных курсоров, селекторов и массивов) перед их использованием.
Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
ну-ну, приведенный фрагмент это совершенно оправданное для такого алгоритма отдхождение от стандартного форматирования, читается на порядке быстрее чем колбаса вроде этой
В таком масштабе это еще не так очевидно, но когда речь пойдет уже не о "в строке 1128 на 2357" а "в строке 9973 на 18273" или файлов будет не 20 а 200 того же размера — вот тогда взвейтесь кострами темные бессонные в дебагере ночи.
Вообщем совет такой — возьми и попробуй сделать так как тебе кажется правильным. Те самые 255 кб. Хотя бы в те же сроки. И еще учти что переписать программу по новому всегда намного легче чем писать/разрабатывать ее с чистого листа без всякого образца, нормального тз, какой-либо четкой определенности что же она должна делать, тем более если кто-то умный требует все и сразу — сделать не только обработку мейнстрима но и всех исключительных ситуаций. Наверное для того чтобы когда этому умному поручат добавить в программу обработку исключительных ситуаций, там все это уже было.
Вот, ну а когда сделаешь приготовься к тому что следующий программист ничего не поняв и видимо не пожелав понимать в твоей иерархии классов/архитектуре/разбивке на файлы/"где что есть и должно быть" будет кричать что код атцтой — а то что вот ты как-то в этом коде разбирался и он почему-то работает объяснит или исключительно помощью мистической силы природы — КОД!, или уникальными особенностями мышления создателя кода, причем очевидно дегеративными дескать нормальные люди в этом мусоре разобраться не могут, на это способны только дауны.
Здравствуйте, Apostate, Вы писали:
A>ну-ну, приведенный фрагмент это совершенно оправданное для такого алгоритма отдхождение от стандартного форматирования, читается на порядке быстрее чем колбаса вроде этой
Ничего подобного. Такое форматирование не оправдано ничем. A>В таком масштабе это еще не так очевидно, но когда речь пойдет уже не о "в строке 1128 на 2357" а "в строке 9973 на 18273" или файлов будет не 20 а 200 того же размера — вот тогда взвейтесь кострами темные бессонные в дебагере ночи.
Ну-ну. Я посмотрел бы, как ты ставишь в этом фрагменте брекпоинты.
Приведенный тобой вариант показывает, что одного форматирования недостаточно. Этот код можно переписать в гораздо более понятном стиле безо всякого вреда для алгоритма. Более того, компилятору можно существенно облегчить жизнь, если не заставлять его выделять common subexpression и выносить loop constants. Прведенный код должен работать примерно втрое-вчетверо медленнее при отключенном оптимизаторе, чем при включенном. А это, как правило, симптом программерской некомпетентности. A>Вообщем совет такой — возьми и попробуй сделать так как тебе кажется правильным. Те самые 255 кб. Хотя бы в те же сроки. И еще учти что переписать программу по новому всегда намного легче чем писать/разрабатывать ее с чистого листа без всякого образца, нормального тз, какой-либо четкой определенности что же она должна делать, тем более если кто-то умный требует все и сразу — сделать не только обработку мейнстрима но и всех исключительных ситуаций. Наверное для того чтобы когда этому умному поручат добавить в программу обработку исключительных ситуаций, там все это уже было.
Ты знаешь, в моей практике я что-то не припомнб задач типа "добавить обработки исключительных ситуаций". Задачи "добавить фичу" — сплошь и рядом. В том числе и в подобный код. И вот тут то приходится выть, ибо любая вставка в какое-то место такого кода приводит к долгой и нудной отладке. A>Вот, ну а когда сделаешь приготовься к тому что следующий программист ничего не поняв и видимо не пожелав понимать в твоей иерархии классов/архитектуре/разбивке на файлы/"где что есть и должно быть" будет кричать что код атцтой — а то что вот ты как-то в этом коде разбирался и он почему-то работает объяснит или исключительно помощью мистической силы природы — КОД!, или уникальными особенностями мышления создателя кода, причем очевидно дегеративными дескать нормальные люди в этом мусоре разобраться не могут, на это способны только дауны.
Знаешь, есть некие правила. И они придуманы вовсе не для того, чтобы жизнь программистов усложнить. А товарищей, которые говорят "а я буду определять глобальные константы и код в .h файле, а .cpp буду инклудить", надо увольнять сразу же. Ибо нет им оправдания.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
[skip overquotted part ]
L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
Вах! Экая же он глыба, экий матёрый человечище!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Что тут можно сказать?
Добро пожаловать в реальный мир.
Хорошо, что ты понимаешь все проблемы, но выносить
чужую работу на всеобщее обсуждение пожалуй не стоит.
Здравствуйте, Apostate, Вы писали:
M_T>>UML диаграммы действительно не нужны, но я бы предпочел видеть рабочий, понятный, протестированный, и легко поддерживаемый код а не кусок не понятно чего.
A>Все и сразу?
A>Да вы батенька фантазер.
Я не фантазер, все дело в правильной методологии есть методологии тяжелые и медленные где нужно писать кучу документации продумывать досконально дизайн рисовать диаграммы. А есть быстрые где дизайн минимальный и большая часть времени это собственно кодированье но кодированье правильное
которое дает тот результат, о котором я написал.
A>Ну да, но еще также очень хорошо известно что на рынке остаются в основном те продукты которые успели в приемлемые сроки выпустить первые работоспособные версии. А вовсе не те у которых поддержка дешевле. A>Так что в предлагаемом вами варианте речь идет скорее не о том чтобы заработать больше, а о том чтобы не заработать вовсе.
Ну давайте посмотрим на Нетскеип к примеру им был произведен революционный продукт не имеющий аналогов.
Который занимал 80-90 процентов рынка.И где он сейчас ? Он не смог конкурировать с МС в основном из-за того
что код его был написан в стиле приведенным выше. Добавка новой функциональности или починка багов занимала
столько времени что продукт не смог оставаться конкурентно способным. В конце пришлось его просто выкинуть
и писать все заново но поезд уже ушел.
M_T>>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.
M_T>>
A>Ну вот и 3 версия "правильного кода".
A>А что следующий программист скажет?)
Не понимаю что так развеселило улучшение кода это процесс непрерывный пока код живет его надо улучшать, но дело в том что каждое послеедушее улучшение вводить проше чем предедущие.
Здравствуйте, limax, Вы писали:
L>Достался мне в наследство от предыдущего программера код игры. И не просто код, а КОД, т.к. программер этот работает в компании SOT. Ничего не имею против компании — их линух (ранее скромно называемый BestLinux) хоть и кривоват немного, но вроде даже — по дошедшим до меня слухам — работает.
да ничего не говори. Бери в руки Understand C++ & SourcePublisher (см. scitools и варезники) или SourceNavigator (см. sourceforge) или SourceInsight еще чего. и разгребай, переформатируй, превращай глобальные переменные в локальные и т.д.
и все время компили + обязательно заведи CVS, иначе похеришь свое время на 100%
Здравствуйте, limax, Вы писали:
L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
Передай ему обратно этот код...
Здравствуйте, limax, Вы писали:
L>В итоге получилось аж 250 КБ чистого кода (это практически без пробелов и комментариев).
Ну это ерунда. Неделя-две работы. А пугал то, пугал .
L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
Да ничего не надо передвать. Если тебе этот код нужен, то неспеша можно за недельку привести его в божеский вид. Если не нужен, то плюнуть и забыть.
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Готов поспорить на стакан красного и огурец, что этот программер юзал allegro для графики. Если так то тебе еще повезло, она понятная и глюков там не много, да и программу можно компилять и отлаживать в VC6.0, 7.0, 7.1
Огурец заслужил, но без красного. :-Р
По почте бандеролью выслать?
1) Во-первых, либо это в VC.NET баг, либо так влияет весьма странная многопоточность allegro (есть time-critical и high priority threads), но при отладке проги использующей аллегро, среда иногда намертво виснет и вешает комп. Единственный выход — иметь открытый FAR, при зависании переходить в него по Alt-Tab и убивать devenv.exe. Ни запустить что-нибудь, ни открыть Task Manager по Ctrl-Alt-Del в это время нельзя. Что характерно, вероятность зависания намного выше, если ставишь breakpoint близко к месту, в котором должен будет выскочить assertion failure. Единственный гарантированный метод без зависаний — наставить ASSERT-ов и запустить без отладки, а затем выбрать debug при assertion failure.
Кстати, ещё странный глюк — при выходе из программы в оконном режиме, она может закрыть окно и зависнуть на каком-то WaitForMultipleObjects при закрытии тредов ввода. Так и не разобрался — из-за невозможности отладки. Проверял на идущих с аллегро тестах и примерах — аналогично. Allegro 4.0.3.
2) Во-вторых, allegro у него используется равномерно по всему коду. Т.е. нет определённых функций вывода, скажем, информации об игроке: где вздумалось вывести инфо, там и стоит textout или textprintf на жёстко заданную координату. Со спрайтами — похожая ситуация.
Сначала я пытался ещё как-то рефакторить код (потратив до этого 4 дня на форматирование, т.к. ни один форматер не смог его нормально отформатировать — слишком много вложенных if и for), но на прошлой неделе плюнул и стал переписывать весь код начисто, используя его исходники как reference по логике игры.
S>Приведенный тобой вариант показывает, что одного форматирования недостаточно. Этот код можно переписать в гораздо более понятном стиле безо всякого вреда для алгоритма. Более того, компилятору можно существенно облегчить жизнь, если не заставлять его выделять common subexpression и выносить loop constants. Прведенный код должен работать примерно втрое-вчетверо медленнее при отключенном оптимизаторе, чем при включенном. А это, как правило, симптом программерской некомпетентности.
Если человек занимается оптимизацией сырого кода, который еще не один раз надо будет переписывать, редактировать — вот это и говорит об его некомпетентности.
S>Ты знаешь, в моей практике я что-то не припомнб задач типа "добавить обработки исключительных ситуаций".
В привиденном примере выше, программа работает только при правильных действиях пользователя, либо я ничего не понимаю, но речь о добавлении новых фич в таких случаях не идет, речь идет об обработке ситуаций когда пользователь совершает 'не правильные действия'.
S>Задачи "добавить фичу" — сплошь и рядом. В том числе и в подобный код. И вот тут то приходится выть, ибо любая вставка в какое-то место такого кода приводит к долгой и нудной отладке.
Или нужно читать код, и только после этого его править.
В привиденном примере код вполне читабельный.
S>Знаешь, есть некие правила. И они придуманы вовсе не для того, чтобы жизнь программистов усложнить.
Есть это где?
На фирме где они работают?
Или это некие "общепринятые" правила, которые не все разделяют?
S>А товарищей, которые говорят "а я буду определять глобальные константы и код в .h файле, а .cpp буду инклудить", надо увольнять сразу же. Ибо нет им оправдания.
Увольнять?- какой шустрый, сразу видно молодец! . У тебя есть люди такие какие есть и они будут работать так как они могут. И увольнять скорее всего ты захочешь тех, кто безпомощно разводит руками обвиняя в своей беспомощности других, а не тех кто пускай и не красиво, но выполняет свою работу.
Есть такое понятие как черновая работа. Здесь _очевидно_ таковая. Есть такая вещь как сложность задачи, преодолеть которую 'правильным' причесыванием кода не возможно, как не старайся. Сам я игры не писал, но насколько я слышал это как правило оченно не линейная задача, и код в них закономерно бывает соотвествующий.
Здравствуйте, Apostate, Вы писали:
A>Или нужно читать код, и только после этого его править.
Ну-ну. По-моему у кого-то просто нет опыта модификации вот таких чудес. Я лично с этим сталкивался. И сколько ты ни читай 250 килобайт — наизусть ты их не выучишь. И вроде бы ты распутал то место, в котором надо добавить строчку кода, чтобы новый пункт в меню добавился... Ан нет, где-то вылазит access violation — и поехали... Искать, где меняется эта глобальная переменная. A>В привиденном примере код вполне читабельный.
Ну-ну. И что он делает? S>>Знаешь, есть некие правила. И они придуманы вовсе не для того, чтобы жизнь программистов усложнить.
A>Или это некие "общепринятые" правила, которые не все разделяют?
Да, есть общепринятые правила. Их разделяют те, кто умеет работать в команде.
A>Увольнять?- какой шустрый, сразу видно молодец! . У тебя есть люди такие какие есть и они будут работать так как они могут. И увольнять скорее всего ты захочешь тех, кто безпомощно разводит руками обвиняя в своей беспомощности других, а не тех кто пускай и не красиво, но выполняет свою работу.
Вот уж вряд ли. У меня есть те люди, которых я взял на работу. Увольнять я захочу тех, чья работа не оправдывает потраченных на них денег. Если человеку ставится задача "написать код", то он и должен написать код. А не этот набор символов, совершенно случайно при стечениии удачных обстоятельств делает что-то, похожее на требуемую функциональность. С тем же успехом он мог отдать мне бинарник. Но такой бинарник стоит $2 — ровно за такие деньги я могу купить болванку с супер-пупер гамезой. При этом, в отличие от нашего легко читаемого при помощи многопроходного компилятора текста, эта гамеза будет хотя бы отлаженной.
И не надо противопоставлять вот таким безответственным кодописателям людей, которые разводят руками. Все толковые девелоперы, с которыми я работал и работаю, могут разобраться и в таком коде тоже. Другое дело, что им потребуется на это дополнительное время. Так что это разные оси координат. Вдоль одной отложено качество кода, от процитированного до канонического, а вдоль другой — способность решить поставленную задачу.
A>Есть такое понятие как черновая работа. Здесь _очевидно_ таковая. Есть такая вещь как сложность задачи, преодолеть которую 'правильным' причесыванием кода не возможно, как не старайся. Сам я игры не писал, но насколько я слышал это как правило оченно не линейная задача, и код в них закономерно бывает соотвествующий.
Да нету там никакой сложности задачи! Есть абсолютно безграмотный код, плохо читаемый как человеком, так и компилятором. Нет никакой причины лепить все в одну строчку.
int pictureSize = (r+1)*2;
int mapOffsetX = cit[c].x-r;
int mapOffsetY = cit[c].y-r;
for(i=1; i<pictureSize; i++)
for(j=1; j<pictureSize; j++)
if(getpixel(my_bitmap,i,j))
map[j+mapOffsetY][i+mapOffsetX].vis=2;
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
A>Вот, вот. Я и говорю проблема только в том надо что-что дополнительно делать! и это что-что дебил-предшественник почему-то не сделал раньше. В идеале его код должен содержать комментарии типа — //add your code = {AfxMessgeBox("Don't press this button");} here — находишь поиском и добавляешь.
Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.
S>>Так что это разные оси координат. Вдоль одной отложено качество кода, от процитированного до канонического, а вдоль другой — способность решить поставленную задачу.
A>Да ты че? Ну-ну. Есть одна ось координат на которую все это проецируется — время/деньги. Качество кода, а особенно его архитектуры о ней здесь в основном речь требует много времени.
Качество кода это один из важнейших факторов в оценки кода. Давно известно что собственно разработка эта самая дешевая часть она берет не больше 30% ресурсов которые тратятся на проект в течение жизни проекта после этого идет поддержка которая занимает уже 70% ресурсов а иногда и больше. Чем качественнее будет код, тем дешевле его будет поддерживать, тем дешевле будет конечная цена проекта.
A>И вот что я вам скажу. Вместо красивых UML-картинок которые не работают никак, я бы предпочел видеть как угодно коряво написанный код, работающий только в случаях когда пользователь нажимает на кнопки в правильной последовательности.
UML диаграммы действительно не нужны, но я бы предпочел видеть рабочий, понятный, протестированный, и легко поддерживаемый код а не кусок не понятно чего.
S>>Да нету там никакой сложности задачи!
A>Ну две строчки вы распарсили. А остальные 250кб? А то давайте вырвем из любого кода кусок i++; — действительно все просто, сложностей нет.
В том что код сложный виноват тот кто его писал. Проблема что человек не пытался сделать свой код луче в процессе написания. Если бы он периодически вытаскивал мелкие методы из крупных, переименовал переменные в более понятные добавлял классы по мере надобности , и сопровождал это все библиотекой тестов то он бы в конечном итоги написал бы игру за треть того времени которое у него ушло на рождение этого чудовища и оставил бы после себя 50 кб красивого легко читаемого и легко изменяемого кода.
S>>Есть абсолютно безграмотный код, плохо читаемый как человеком, так и компилятором. S>>
S>> int pictureSize = (r+1)*2;
S>> int mapOffsetX = cit[c].x-r;
S>> int mapOffsetY = cit[c].y-r;
S>> for(i=1; i<pictureSize; i++)
S>> for(j=1; j<pictureSize; j++)
S>> if(getpixel(my_bitmap,i,j))
S>> map[j+mapOffsetY][i+mapOffsetX].vis=2;
S>>
A>Ну хорошо. Вы дали именам более длинные и поверхностному взору понятные индефикаторы. Ввели дополнительные локальные переменные.
A>А тут приходит следующий и начинает орать что венгерской нотации в этих индефификаторах нет, ничего ему не понятно, код ацтой и писали его ламеры.
A>Что вы будете делать?
Венгерская нoтация это стандарт кода стандарты вводятся в административном порядке если есть причины менять стандарт то придется его менять не чего не поделаешь. Но изменить нотацию в выше приведенном куске кода уже гораздо проще, чем в изначальной мешанине.
Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.
M_T>UML диаграммы действительно не нужны, но я бы предпочел видеть рабочий, понятный, протестированный, и легко поддерживаемый код а не кусок не понятно чего.
Все и сразу?
Да вы батенька фантазер.
M_T>Качество кода это один из важнейших факторов в оценки кода. Давно известно что собственно разработка эта самая дешевая часть она берет не больше 30% ресурсов которые тратятся на проект в течение жизни проекта после этого идет поддержка которая занимает уже 70% ресурсов а иногда и больше. Чем качественнее будет код, тем дешевле его будет поддерживать, тем дешевле будет конечная цена проекта.
Ну да, но еще также очень хорошо известно что на рынке остаются в основном те продукты которые успели в приемлимые сроки выпустить первые работоспособные версии. А вовсе не те у которых поддержка дешевле.
Так что в предлагаемом вами варианте речь идет скорее не о том чтобы заработать больше, а о том чтобы не заработать вовсе.
M_T>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.
M_T>
Здравствуйте, Framer, Вы писали: F>Из чего делаем вывод все это юмористический литературный этюд.
Ура! Мне не верят!
Всегда мечтал написать что-нибудь литературное, вот только не получалось никогда. Даже оценки за сочинения в школе снижали постоянно за малое количество текста и нераскрытость темы. Не знал чего писать — "ведь и так всё понятно".
Здравствуйте, www, Вы писали:
www>Я конечно понимаю, что программисты не знают языков, но... увольте... www>такое читать невозможно. www>не знаю вашей компетенции, но судя по всему...
А может просто стоит такие куски выносить в осмысленные функции? И переменные по-человечески называть — тогда никакой "колбасы" не будет. Форматирование тут не при чем — просто криво написано .
P.S. Глянешь на кусок хорошо написаного кода — сразу понятно, о чем хоть речь-то идет. А тут — полная фигня, какое-то безликое перемалывание массивов.
Здравствуйте, limax, Вы писали:
L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
Держи себя в руках!
S>Вот уж вряд ли. У меня есть те люди, которых я взял на работу. Увольнять я захочу тех, чья работа не оправдывает потраченных на них денег. Если человеку ставится задача "написать код", то он и должен написать код. А не этот набор символов, совершенно случайно при стечениии удачных обстоятельств делает что-то, похожее на требуемую функциональность. С тем же успехом он мог отдать мне бинарник. Но такой бинарник стоит $2 — ровно за такие деньги я могу купить болванку с супер-пупер гамезой. При этом, в отличие от нашего легко читаемого при помощи многопроходного компилятора текста, эта гамеза будет хотя бы отлаженной.
=) ну вот, слово в слово про магию и дебила это написавшего
S>И не надо противопоставлять вот таким безответственным кодописателям людей, которые разводят руками. Все толковые девелоперы, с которыми я работал и работаю, могут разобраться и в таком коде тоже. Другое дело, что им потребуется на это дополнительное время.
Вот, вот. Я и говорю проблема только в том надо что-что дополнительно делать! и это что-что дебил-предшественник почему-то не сделал раньше. В идеале его код должень содержать комменатрии типа — //add your code = {AfxMessgeBox("Don't press this button");} here — находишь поиском и добавляешь.
S>Так что это разные оси координат. Вдоль одной отложено качество кода, от процитированного до канонического, а вдоль другой — способность решить поставленную задачу.
Да ты че? Ну-ну. Есть одна ось координат на которую все это проецируется — время/деньги. Качество кода, а особенно его архитектуры о ней здесь в основном речь требует много времени. Есть множество примеров когда проекты были провалены по срокам, так и не вступив в стадию программирования — люди проектировали красивую архитектуру. Ай да молодцы.
И вот что я вам скажу. Вместо красивых UML-картинок которые не работают никак, я бы предпочел видеть как угодно коряво написанный код, работающий только в случаях когда пользователь нажимает на кнопки в правильной последовательности.
S>Да нету там никакой сложности задачи!
Ну две строчки вы распарсили. А остальные 250кб? А то давайте вырвем из любого кода кусок i++; — действительно все просто, сложностей нет.
S>Есть абсолютно безграмотный код, плохо читаемый как человеком, так и компилятором. S>
S> int pictureSize = (r+1)*2;
S> int mapOffsetX = cit[c].x-r;
S> int mapOffsetY = cit[c].y-r;
S> for(i=1; i<pictureSize; i++)
S> for(j=1; j<pictureSize; j++)
S> if(getpixel(my_bitmap,i,j))
S> map[j+mapOffsetY][i+mapOffsetX].vis=2;
S>
Ну хорошо. Вы дали именам более длинные и поверхностному взору понятные индефикаторы. Ввели дополнительные локальные переменные.
А тут приходит следующий и начинает орать что венгерской нотации в этих индефификаторах нет, ничего ему не понятно, код ацтой и писали его ламеры.
Что вы будете делать?
S>Нет никакой причины лепить все в одну строчку.
Так не бывает, чтобы не было никакой причины так делать, и так все-таки делали и делали. Подумайте. Я могу привести не одну вполне объективную причину почему люди в черновых работах копипастят, почему они не создают локальные переменные pictureSize и почему порой оформляют код в одну строку.
> S>Да нету там никакой сложности задачи! > Ну две строчки вы распарсили. А остальные 250кб? > А то давайте вырвем из любого кода кусок i++; - > действительно все просто, сложностей нет.
Я в свое время написал программку, которая парсит С++ код на тот вид,
который мне нужно именно для подобного большого проекта — она выставляла
всякие скобки, табуляторы, переносы строк и т.д. Можно, конечно, было
довести ее до ума и сделать еще так, чтобы она переименовывала переменные в
венгерскую нотацию и т.д... Однако, она мне требовалась только для
одноразового преобразования чужого исходника... так она и умерла... А, ИМХО,
можно бы было написать ее сейчас с нуля, только добавив функциональности,
чтобы пользователь получал на выходе тот исходник, который хочет именно
он... Может, даже, разбитый и пересортированный по нужным файлам...
> прогони через форматировщих исходников, это немного облегчит твои
страдания. > а следующему программисту передай — "мозги компьютерные, 32 метра"
Дай ссылочку на что-нибудь подобное, и, желательно, free...
Posted via RSDN NNTP Server 1.6
Re[3]: КОД по наследству
От:
Аноним
Дата:
03.07.03 05:51
Оценка:
Здравствуйте, Anton Batenev, Вы писали:
>> прогони через форматировщих исходников, это немного облегчит твои AB>страдания. >> а следующему программисту передай — "мозги компьютерные, 32 метра"
AB>Дай ссылочку на что-нибудь подобное, и, желательно, free...
M_T>Я не фантазер, все дело в правильной методологии есть методологии тяжелые и медленные где нужно писать кучу документации продумывать досконально дизайн рисовать диаграммы. А есть быстрые где дизайн минимальный и большая часть времени это собственно кодированье но кодированье правильное M_T>которое дает тот результат, о котором я написал.
А что за методологии?
M_T>Ну давайте посмотрим на Нетскеип к примеру им был произведен революционный продукт не имеющий аналогов. M_T>Который занимал 80-90 процентов рынка.И где он сейчас ? Он не смог конкурировать с МС в основном из-за того M_T>что код его был написан в стиле приведенным выше. Добавка новой функциональности или починка багов занимала M_T>столько времени что продукт не смог оставаться конкурентно способным. В конце пришлось его просто выкинуть M_T>и писать все заново но поезд уже ушел.
Ну я ж говорю как правило. Все можно преодолеть, вопрос сколько это будет стоить. Например, надо быть монополистом в этом классе операционных систем, плюс отдавать свой продукт бесплатно.
M_T>>>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.
M_T>Не понимаю что так развеселило улучшение кода это процесс непрерывный пока код живет его надо улучшать, но дело в том что каждое послеедушее улучшение вводить проше чем предедущие.
Ну именно то что он бесконечный. Поэтому качество кода это вопрос стадии поддержка кода — в масштабе жизни проекта бесконечна. А не стадии его создания — конечная. Ошибка это пытатся засунуть бесконечное в конечное — пускай пишут как получается, после исправим если понадобится, по-моему это в некотором роде один из постулатов XP.
Здравствуйте, Apostate, Вы писали:
M_T>>Я не фантазер, все дело в правильной методологии есть методологии тяжелые и медленные где нужно писать кучу документации продумывать досконально дизайн рисовать диаграммы. А есть быстрые где дизайн минимальный и большая часть времени это собственно кодированье но кодированье правильное M_T>>которое дает тот результат, о котором я написал.
A>А что за методологии?
Самая популярная XP о который вы уже сказали, но о которой помойму знаете крайне мало.
A>Ну я ж говорю как правило.
У вас не правельное правило.
A>Все можно преодолеть, вопрос сколько это будет стоить. Например, надо быть монополистом в этом классе операционных систем, плюс отдавать свой продукт бесплатно.
Нетскеип в конечно счете проиграл по функциональносте. До тех пор пока он был функциональнее IE ему удавалось держать сильные позиции не смотря на все ухешрения отдела маркетинга МС.
M_T>>>>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.
M_T>>Не понимаю что так развеселило улучшение кода это процесс непрерывный пока код живет его надо улучшать, но дело в том что каждое послеедушее улучшение вводить проше чем предедущие.
A>Ну именно то что он бесконечный. Поэтому качество кода это вопрос стадии поддержка кода — в масштабе жизни проекта бесконечна. А не стадии его создания — конечная.
Бесконечность начинаеться с нуля тоесть с того времени когда написали первую строчку кода.
XP пытаеться как можно быстрее превести проект к стадии подержки кода.
A> Ошибка это пытатся засунуть бесконечное в конечное — пускай пишут как получается, после исправим если понадобится, по-моему это в некотором роде один из постулатов XP.
В некотором роде действительно да, только не в том роде как вы написали а в том как я написал.
Цикл написания кода в ХП это Тестированье->Кодированье->Рефакторинг.
Тоесть мы думаем что нам нужно , какой результат нам нужно получить пишем тест который проверяет что результат действительно такой который мы ожидаем
пишем самый простой вариант кода который может дат нам необходимый результат, запускаем тест проверяем что тест прошел успешно что мы действительно получили то что нужно после чего делаем небольшой рефакторинг кода чтобы сделать его более правильным и красивым, запускаем тест еще раз чтобы проверить что мы не чего не испортили нашим рефакторингом пишем еще пару тестов на проверку поведения в нетепичных ситуациях и тд.
M_T>Самая популярная XP о который вы уже сказали, но о которой помойму знаете крайне мало.
Да нет.
M_T>У вас не правельное правило.
Правильное.
M_T>Нетскеип в конечно счете проиграл по функциональносте. До тех пор пока он был функциональнее IE ему удавалось держать сильные позиции не смотря на все ухешрения отдела маркетинга МС.
Ну-ну. Не буду спорить просто не соглашусь с тем какой именно фактор был первичным, определяющим, важным. Я считаю, если бы не 'ухешрения' что выше, об этой новой функциональности массовый пользователь даже не узнал, а узнал бы то не стал бы ее юзать. Опять же повторюсь что уверен на 100% и именно поэтому спорить не буду .
M_T>В некотором роде действительно да, только не в том роде как вы написали
Помойму все-таки да
M_T>>Нетскеип в конечно счете проиграл по функциональносте. До тех пор пока он был функциональнее IE ему удавалось держать сильные позиции не смотря на все ухешрения отдела маркетинга МС.
A>Ну-ну. Не буду спорить просто не соглашусь с тем какой именно фактор был первичным, определяющим, важным. Я считаю, если бы не 'ухешрения' что выше, об этой новой функциональности массовый пользователь даже не узнал, а узнал бы то не стал бы ее юзать. Опять же повторюсь что уверен на 100% и именно поэтому спорить не буду .
Я в свое время был убежденым нетскейпшиком но с определеного момента IE просто стал луче и удобнее и я стал пользоваться им.
M_T>> а в том как я написал.
A>-) а я раньше
Вы описали совершено неверное понимание принципов ХП.
M_T>Я в свое время был убежденым нетскейпшиком но с определеного момента IE просто стал луче и удобнее и я стал пользоваться им.
Это ты. А я говорил о массовом пользователе.
M_T>Вы описали совершено неверное понимание принципов ХП.
У тебя либо педантизм либо неумение воспринимать те же мысли но другими словами — я почти тоже самое сказал что ты потом ниже. Опять же спорить не буду, потому что смысла спорить кто что сказал или не сказал вообще нет.
Вот по существу пожалуйста. Вернусь к начальной твоей реплике.
M_T>Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.
Если он разрабатывал MFC то да, а вот если писал прикладную программу у которой должно быть 2 кнопки и думал а что если завтра нужно будет поставить третью, а что для этого нужно , а не исправить ли мне сейчас на этот случай архитектуру и т.п. — то это как минимум уже не XP. С этим согласен?
Здравствуйте, Apostate, Вы писали:
M_T>>Я в свое время был убежденым нетскейпшиком но с определеного момента IE просто стал луче и удобнее и я стал пользоваться им.
A>Это ты. А я говорил о массовом пользователе.
Массовый пользователь он не такой дурак как кажеться, до пятой версии IE майкрософту не удавлось вытеснить навигатор за пределы рынка , но в любом случае мы отошли од темы.
A>Вот по существу пожалуйста. Вернусь к начальной твоей реплике.
M_T>>Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.
A>Если он разрабатывал MFC то да, а вот если писал прикладную программу у которой должно быть 2 кнопки и думал а что если завтра нужно будет поставить третью, а что для этого нужно , а не исправить ли мне сейчас на этот случай архитектуру и т.п. — то это как минимум уже не XP. С этим согласен?
ХП против введения абстрактной архитектуры но целиком за улучшение сушествуешего кода при том за непрерывное если у вас есть одна кнопка то вполне можно хранить все ее значения в обычных переменных но с понятными названиями и обрабатывать ее события в глобальной функции если же понадобилось две или больше кнопок то нужно не копи пайстеть и добовлять цифирки на конец названий а нужно вводить простенький класс Button посколько это стало необходимостью.
M_T>>>Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.
A>>Если он разрабатывал MFC то да, а вот если писал прикладную программу у которой должно быть 2 кнопки и думал а что если завтра нужно будет поставить третью, а что для этого нужно , а не исправить ли мне сейчас на этот случай архитектуру и т.п. — то это как минимум уже не XP. С этим согласен?
M_T>ХП против введения абстрактной архитектуры но целиком за улучшение сушествуешего кода при том за непрерывное
Поправки следующие — улучшение существующего кода только когда либо есть новый план релиза и там стоит чтобы было 3 кнопки — так захотел пользователь, либо когда задача сделать так чтобы в любой момент мы могли добавить 3-ю кнопку — маркетологи (ну или интуиция разработчика) говорит что клиент в любую минуту может этого захотеть. Никакого непрерывного совершенствования ради совершенствования, ради каких-то абстрактных целей. Если в задании жестко 2 кнопки и никаких подвижок что там с какого-то бока может появится третья — запрет на любые совершенствования кода, архитектуры в этом направлении — работает? — не трогай!.
M_T>если у вас есть одна кнопка то вполне можно хранить все ее значения в обычных переменных но с понятными названиями и обрабатывать ее события в глобальной функции если же понадобилось две или больше кнопок то нужно не копи пайстеть и добовлять цифирки на конец названий а нужно вводить простенький класс Button посколько это стало необходимостью.
Сомнительно. Можно привести 1000 аргументов за и не меньше против. И называется такой трюк стилем, а о стилях не спорят.
Единственно c чем могу спорить — с амбициозностью что наш стиль это супер стиль, а кто так не делает дебилы, а кто делает не_дебилы. Есть 1000 примеров успешных программистов не делающих так как ты написал и 1000 неуспешных делающих, как впрочем и наоборот. It depends. И зависит от того делают ли они свою работу — тратят свое время, нужд компании/клиента или ради_чего_то_другого, абстрактной цели совершенствования кода, например.
Например вот так. А вдруг когда нибудь в messagebox понадобится сразу 10 кнопок — "Повторить" "Повторять всегда" "Делай как в прошлый раз" "Ничего не знаю, сделай по умолчанию" "Вообще ничего не знаю, делай все по умолчанию" "Аборт" "Игнорировать" "Игнорировать Все" "Детали" "Помощь" — круто, возьму ка я и откажусь от стандартного messagebox, напишу свой похожий на стандартный но который в любой момент можно будет исправить на нечто на подобное, и вставлю его в текущий код.
Здравствуйте, Apostate, Вы писали:
A>Поправки следующие — улучшение существующего кода только когда либо есть новый план релиза и там стоит чтобы было 3 кнопки — так захотел пользователь, либо когда задача сделать так чтобы в любой момент мы могли добавить 3-ю кнопку — маркетологи (ну или интуиция разработчика) говорит что клиент в любую минуту может этого захотеть. Никакого непрерывного совершенствования ради совершенствования, ради каких-то абстрактных целей. Если в задании жестко 2 кнопки и никаких подвижок что там с какого-то бока может появится третья — запрет на любые совершенствования кода, архитектуры в этом направлении — работает? — не трогай!.
Мне не понятно почему вы воспринимаете совершенствование кода как введение дополнительной абстрактной функциональности, я говорю всеволиш про рефакторинг, тоесть как написано на обложке про "улучшение дизайна существующего кода". Рефакторинг это одна из неотемлимых практик ХП такая же как
парное программирование и разработка "тестами вперед". Конечно нету непрерывного совершенствованья одного и того же куска кода, поскольку есть конечное количеств улучшений. Но до тех пор пока кто-то работает с кодом идет совершенствованье того или иного куска.
Рефакторинг не имеет смысла только в случае если код написан по принципу написать и забыть но такого кода очень мало, большинство же кода требуется изменять, поскольку требованья меняются.
A>Сомнительно. Можно привести 1000 аргументов за и не меньше против. И называется такой трюк стилем, а о стилях не спорят.
Я не очень понимаю с чем вы спорите , вам не нравятся классы ? Мне честно говоря было бы интересно послушать два три аргумента в пользу дублирования кода.
A>Единственно c чем могу спорить — с амбициозностью что наш стиль это супер стиль, а кто так не делает дебилы, а кто делает не_дебилы. Есть 1000 примеров успешных программистов не делающих так как ты написал и 1000 неуспешных делающих, как впрочем и наоборот. It depends. И зависит от того делают ли они свою работу — тратят свое время, нужд компании/клиента или ради_чего_то_другого, абстрактной цели совершенствования кода, например.
Тратить свое время для введения не нужной функциональности это плохо , тратить его для улучшение существующего дизайна это хорошо.
Re[17]: КОД по наследству
От:
Аноним
Дата:
05.07.03 11:26
Оценка:
M_T>Мне не понятно почему вы воспринимаете совершенствование кода как введение дополнительной абстрактной функциональности, я говорю всеволиш про рефакторинг, тоесть как написано на обложке про "улучшение дизайна существующего кода". Рефакторинг это одна из неотемлимых практик ХП такая же как парное программирование и разработка "тестами вперед".
ты ничего не понимаешь в конфу,
нет это ты
не ты
ну сейчас я докажу тебе что ты ошибаешься
да давай посмотрим
тия-кия-куя-х.я-зуя-кирдык-бдымс два трупа
Вообщем, темное это дело XP, тонкости формулировок разнятся от книжки к книжке, а все дело именно в этих тонкостях .
В моем понимании XP (теперь надеюсь понятно к чему такие оговорки?), рефакторинг это инструментдоведения программы до удовлетворения тестов. Его никогда не делают просто так. Тесты тоже не придумывают с потолка. Т.е. "улучшение дизайна существующего кода" только в рамках теста типа "сделайте так чтобы завтра мы могли быстро добавить функциональность такого-то и такого рода" — а не просто дали мальчику код и сказали "как нибудь усовершенствуй его". И это имхо ОСНОВЫ XP в этом его кардинальное отличие.
M_T>Конечно нету непрерывного совершенствованья одного и того же куска кода, поскольку есть конечное количеств улучшений.
Такие модификации чтобы код стал во всех смыслах лучше действительно конечны и их мало, и есть еще такая проблема что надо уметь остановится, нащупать грань, раставить приоритеты от чего отказываться а что оставить, потому что 'улучшения' которые в одном делают его лучше а в другом хуже уже бесконечны.
M_T>Но до тех пор пока кто-то работает с кодом идет совершенствованье того или иного куска.
По определению работа с кодом это его совершенствование. Хотя я бы все-таки говорил о модификации кода.
M_T>Рефакторинг не имеет смысла только в случае если код написан по принципу написать и забыть но такого кода очень мало, большинство же кода требуется изменять, поскольку требованья меняются.
Это классика. А XP написать и, зная что потом будешь поддерживать, не сделать ничегочтобы код удовлетворял тестам которых еще нет, и лишь быть готовым психологически к любым новым требованиям в том числе и забыть про проект.
M_T>Я не очень понимаю с чем вы спорите , вам не нравятся классы ?
Мне нравятся, но я знаю людей которым не нравятся и я не согласен с теми кто говорит что они работать не умеет.
M_T>Мне честно говоря было бы интересно послушать два три аргумента в пользу дублирования кода.
Послушать? Ну-ну). Хорошо послушайте.
В пределах n-часов жизни копи-паст код удобнейсоздания функции
1. Скорость написания
— копи-паст и все
— не нужно придумывать название функции, далеко не такой простой вопрос как может показатся, не нужно описывать параметры функции, определятся с их составом, опять же придумывать их названия, типы, допустимые и не допустимые значения ,выносить все это из места употребления в соотвествующий cpp-файл, а объявление в h. файл
2. Модификация во время написания. Например, хочется чтобы все было также но в цикле проверялось еще и это условие
— копи-паст приписываешь в пастнутый код новое проверка_доп_условия и все
— как вариант не надо в функции вводить дополнительный параметр (проверять_доп_условие) и параметр(значение_доп_условия), исправлять код в фукнции более сложным образом (если проверять_доп_условию то проверить_дополнительное_условие), синхронизировать изменения в объявлении функции (h. файл cpp. файл), и главное как минимум задуматься о том что изменения в функции не скажутся на работе других уже написанных и отлаженных участков кода, которые ее вызывают
— или как другой вариант не нужно создавать для этого еще одну функцию делающую то же но с проверкой этого_доп_условия, при том что это собственно то же дублирование кода)
3. Не надо много запоминать — так случилось что мозг человек не может нормально держать в голове больше 5-7 понятий, тот же индефикатор функции и ее параметры, нужно не только придумать но еще и запомнить и держать в голове
Вся эта работа и неудобства для того чтобы сделать код которым когда-нибудь потом было бы удобно пользоватся и бывает очень обидно когда через полчаса понимаешь что этот код надо вообще убрать и написать по другому и функция эта вообще оказывается не нужна.
Поэтому вариант работы " написать код как получится а потом выделить в нем дублирующиеся участки" я считаю во многом рациональным, и тех кто им пользуется вовсе не закидывают тухлыми помидорами, как это сделал открыватель этого топика.
1. Код я бы все-таки по мере необходимости форматировал вручную. Иногда, раскапывая такой код, узнаешь нечто, что спасло бы тебя от истерического приступа после недельной отладки Скажем, я натыкался на ошибки, когда возвращался указатель на локальную переменную в стеке... И поскольку, переменных в процедуре было много, а эта находилась ближе к концу, ты вызов крохотных процедур ничего не менял... Но стоило бы усложнить...
2. Лично я сильно привык к DUnit (аналог JUnit для Delphi), во всяком случае при рефакторинге таких программ тесты бывают, имхо, полезны. Даже при условии, что наша контора ХР не использует.
P. S. А венгерскую нотацию я не переношу. Имхо, если о типе переменной можно узнать только из приставки, то нужно срочно что-то менять!
Вот читаю я такие темы и думаю, как мне однажды повезло. Год назад в институте попросили переделать прогу, которая была написана под ДОС, под Винды. Ну как там было все красиво написано. Единственное, только оформление кода я переделал под себя. А так все было понятно, кое-где были комментарии. Я брал целыми кусками и вставлял в свою версию проги. Короче, красота. Автору проги надо
<флейм поскипан без прочтения — что-то вы тут развели демагогию>
А>Поэтому вариант работы " написать код как получится а потом выделить в нем дублирующиеся участки" я считаю во многом рациональным, и тех кто им пользуется вовсе не закидывают тухлыми помидорами, как это сделал открыватель этого топика.
Если бы! Предшественник открывателя этого топика даже не пытался "выделить в нем дублирующиеся участки" и не планировал делать это в будущем — да уже и не смог бы. Он просто в очередной раз жал Copy/Paste.
Здравствуйте, limax, Вы писали:
L>Здравствуйте, Аноним, Вы писали:
L><флейм поскипан без прочтения — что-то вы тут развели демагогию>
А>>Поэтому вариант работы " написать код как получится а потом выделить в нем дублирующиеся участки" я считаю во многом рациональным, и тех кто им пользуется вовсе не закидывают тухлыми помидорами, как это сделал открыватель этого топика.
L>Если бы! Предшественник открывателя этого топика даже не пытался "выделить в нем дублирующиеся участки" и не планировал делать это в будущем — да уже и не смог бы. Он просто в очередной раз жал Copy/Paste.
Не знаю, не знаю... Может он быть, он считал что пока и так нормально, а когда понадобится легко можно сделать, работа не сложная. Ну воот открывателю топика и понадобилось — пускай делает.
И кое-какие функции там уже есть — draw_sprite . Как раз тот случай когда можно с уверенностью заранее сказать, еще не приступив к написанию кода, что такая функция будет нужна в нем не раз и не два.
Здравствуйте, limax, Вы писали:
L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
Готов поспорить на стакан красного и огурец, что этот программер юзал allegro для графики. Если так то тебе еще повезло, она понятная и глюков там не много, да и программу можно компилять и отлаживать в VC6.0, 7.0, 7.1
За это его можно оставить в живых.
Здравствуйте, limax, Вы писали:
L>Достался мне в наследство от предыдущего программера код игры. И не просто код, а КОД, т.к. программер этот работает в компании SOT.
Очень забавный юмористический рассказ.
Прямо готовое пособие как не надо писать код.
Прямо нарушение всех правил оформления проектирования и так далее.
Передать ему, что он стал героем нового анекдота.
Только я вот не верю, что такой чел существует.
Причин несколько.
Передали вам код...
При таком его состоянии я бы его выкинул, а не передавал, передали на что, на сопровождение?
ТАКОЕ не сопровождают.
При том стиле, в котором это написано, ничто большое работать не будет.
Значит, это мелкая софтина, а ее проще переписать, чем исправить.
Она якобы работает, значит, он дописал ее до конца, писал наверное долго.
За это время любой разумный человек его бы десять раз уволил еще на первом же промежуточном этапе.
Выводов несколько, либо он ее не написал, либо она не работает,
либо что-то не то с управлением развития проектов в конторе
как следствие контора такая не может существовать долго — должна была развалиться.
Из чего делаем вывод все это юмористический литературный этюд.
Здравствуйте, Apostate, Вы писали:
F>>Из чего делаем вывод все это юмористический литературный этюд.
A>
A>Эээ, ты теоретик, да?
Угадал по образованию теоретик физик
A>Или по жизни очень везло?
Да таких горбаг как описанно я не видал.
Эпизоды мне знакомы, но чтобы все вместе...
Здравствуйте, Framer, Вы писали:
F>Да таких горбаг как описанно я не видал. F>Эпизоды мне знакомы, но чтобы все вместе...
Я сбежал с прошлого места работы (был там контрактором), когда меня перевели на похожий проект — "слегка поменять" функциональность уже работающей (в продакшене огромной корпорации) системы. Только там было _намного_ больше 250К кода, думаю, где-то раз в 15-20. Чувакам, которые это писали (по-моему, году так в 90-м), похоже, платили за кол-во строчек кода — код был дублирован где только можно. А может быть, они работали на "job security" — никто их уволить не смог бы, так не было никакой возможности разобраться в исходниках. Наверное, в менеджеры пошли в период бума... Не буду утомлять вас описанием того, что я встречал в том коде, поверьте, это было не менее ужасно, чем код у автора этого топика. В общем, где-то месяц с переменным успехом пытался причесывать тот код (конечно же, никаких юнит тестов и в помине нет, зато есть горы (буквально) бумажной документации) — окончательно убила меня функция на 5000 (!) строк. Подумав, что психическое здоровье важнее, к тому же жалко гробить годы на такую хреновню — принял предложение другой компании, чему сейчас страшно рад Здесь я работаю уже почти два года, а тот проект всё "пишется" и конца-краю ему не видно
Здравствуйте, Apostate, Вы писали:
A>Не знаю, не знаю... Может он быть, он считал что пока и так нормально, а когда понадобится легко можно сделать, работа не сложная. Ну воот открывателю топика и понадобилось — пускай делает.
Спасибо, и тебе того же.
A>И кое-какие функции там уже есть — draw_sprite . Как раз тот случай когда можно с уверенностью заранее сказать, еще не приступив к написанию кода, что такая функция будет нужна в нем не раз и не два.
draw_sprite — это стандартная функция библиотеки allegro.
А его функции часто соответствуют названию, однако есть функции с похожими названиями (например слова местами переставлены), делающие совешенно другие вещи. Для полного счастья они ещё друг друга вызывают.
А зачем вам этот код ? Все что тут можно сделать без гемороя это поменять копирайты или язык игры .
L>3) почти на чистом С — значит на С компиляторе он уже не скомпилируется, т.к. структуры уже используются без ключевого слова struct, однако ни одна фича С++ больше не используется.
Ну ... я может чего незнаю но, но помоему чистый Си берёт структуры без волшебного слова (По крайней мере у меня )
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Apostate, Вы писали:
WF>А может просто стоит такие куски выносить в осмысленные функции? И переменные по-человечески называть — тогда никакой "колбасы" не будет. Форматирование тут не при чем — просто криво написано .
стоит конечно, но все сразу)
WF>P.S. Глянешь на кусок хорошо написаного кода — сразу понятно, о чем хоть речь-то идет. А тут — полная фигня, какое-то безликое перемалывание массивов.
хороший код это как правило тот который "я написал только что" а не тот который "я написал год назад" и уж тем более не тот который "написал он"
Здравствуйте, limax, Вы писали:
L>Достался мне в наследство от предыдущего программера код
У меня все намного хуже.
L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?
Я не придумал такой пытки.
A>... Не буду утомлять вас описанием того, что я встречал в том коде, поверьте, это было не менее ужасно, чем код у автора этого топика. В общем, где-то месяц с переменным успехом пытался причесывать тот код (конечно же, никаких юнит тестов и в помине нет, зато есть горы (буквально) бумажной документации) — окончательно убила меня функция на 5000 (!) строк.
Ничего себе! Мне больше 2000 строк еще не попадались. Зато много и сразу. О побочных эффектах из-за глобальных переменных, использующихся в качестве рабочих, я просто молчу.
И еще один момент: качество бумажной документации аналогично качеству кода. У меня даже был случай, когда мы полностью проигнороиовали предложенную архитектором схему, сделав по-своему. Однако в бумаги, оставленные тем архитектором, иногда заглядывают. Приходится людям объяснять ситуацию. Времени переписать ту бумагу у руководства не нашлось. "Написано — не трогай!" — переложение известного лозунга на документацию.
Здравствуйте, stalcer, Вы писали:
F>>...либо что-то не то с управлением развития проектов в конторе... S>Вот и я подумал, что в дыню надо давать не программисту, а его руководителю, допустившему такую фигню.
Это был недоходный проект, делаемый несколькими приятелями из интереса к тактическим играм и теме "а что если вот так?", и держащийся на голом энтузиазме. Программист-предшественник был "приятелем приятеля". В какой-то момент он больше не смог работать над проектом — видимо "интузазизьм" закончился, или что либо менять стало слишком сложно (монолит).
нихт ферштендлихь, вот а ю тоокин эбаут?
.
