Судоку

[Proxy]

Альфа или около того. Код открою когда приведу его в культурный вид, хотя сомневаюсь, что он кому-то может понадобиться.
Пока решает рекурсией, поэтому прожорливо расходует время на выделение памяти и память (кто-то даже утверждает, что виснет навечно, но не особо верю), на досуге буду переделывать в цикл и оптимизировать перебор.
Загадывает (Обычная Cудоку 9x9. Допускает несколько решений), проверяет решение, может наоборот решать загаданную пользователем головоломку (ну мало ли...) перебором (через рекурсию).
Да, версия очень ранняя и параметры проекта пока частично случайные. Решил вспомнить VB6, начал с простого.

[Хакер]

од открою когда приведу его в культурный вид,

Без малейшего намёка на попытки придраться и оскорбить: в чём мотивация писать изначально некультурный код, а потом приводить его в порядок, вместо того, чтобы изначально писать культурный код?

[Proxy]

Без малейшего намёка на попытки придраться и оскорбить: в чём мотивация писать изначально некультурный код, а потом приводить его в порядок, вместо того, чтобы изначально писать культурный код?

Только в том, что не хотелось тратить время на причёсывание кода (например кое-где предположительно есть избыточное обнуление. И не очень удачно организован выход из перебора, т.к. почти сразу сообразил, что зря делаю рекурсией и делал "лишь бы работало, потом перепишу"). Хотелось как можно быстрее сделать работоспособную версию и потом или забросить проект за ненадобностью или наоборот: довести до ума. Хотел написать максимально быстро, чего и добился. Не тот проект, на который хочется тратить время. Просто вспоминал VB6.

[Antonariy]

Написание изначально культурного кода занимает меньше времени, чем разгребание авгиевых конюшен потом.
В универе не принимали криво набранные на паскале лабы несмотря на наш лютый баттхерт и вопли "работает же!!11". В результате это стало даже не привычкой, а рефлексом, который я уже не раз оценил.

[Proxy]

Написание изначально культурного кода занимает меньше времени, чем разгребание авгиевых конюшен потом.

Архитектура приемлема, весь разбор — заменить содержимое в паре процедур. В целом проект писать в виде "наброска" я тоже считаю глупым, но отдельные компоненты, которые затем могут быть оптимизированы вполне допускаю писать из соображений функциональности. Если работает, то и пускай будет так, потом постепенно после завершения всех более важных работ возвращаться. Притом это никак не скажется на взаимодействии между отдельными компонентами проекта, т.к. архитектура остаётся неизменной.

[iGrok]

потом постепенно после завершения всех более важных работ возвращаться

Тут есть два минуса.
Во-первых, это "потом" может и не наступить. У меня обычно так и получается, т.к. после завершения одних более важных частей появляются другие более важные части. Конечно, рано или поздно приходит время переделать изначально кривонаписанное, но это может время может прийти и через три года после написания. А тут уже действует второй минус:
Пока ты пишешь код - ты его хорошо знаешь. Через три года тебе уже придётся тратить время на то, чтобы вспомнить, "а это вообще что такое?". Особенно много времени придётся тратить, если код написан криво. Ну и вообще писать изначально хорошо - не дольше, чем писать криво.
А вот писать криво, потом разбираться, что написал, и потом переписывать хорошо - отнимает в сумме как минимум в полтора-два раза больше времени, чем писать сразу хорошо.

Поэтому я очень стараюсь больше так не делать, хоть иногда и получается из-за недостатка времени на планирование.

[Proxy]

Пока ты пишешь код - ты его хорошо знаешь. Через три года тебе уже придётся тратить время на то, чтобы вспомнить, "а это вообще что такое?". Особенно много времени придётся тратить, если код написан криво. Ну и вообще писать изначально хорошо - не дольше, чем писать криво.

Частично решается стилем. Например у меня gui максимально независим от основного кода, даже если gui требуется.обратиться к массиву в модуле (VB6), то это делаю не через публичный массив, а через функции ввода/вывода. И так со всеми модулями. Чаще всего проигрыш в производительности не ощутим при правильном разбиении. но затем отдельные модули без особого разбора можно переписать просто, от чего не страдают остальные. Например gui едва ли придётся часто трогать, максимум добавить пару кнопочек, т.е. весь код, который касается пользовательского интерфейса при его наличии размещается исключительно в модуле формы. Тут конечно можно и до парадигм дойти, т.к. ООП так или иначе (VB6 полноценным ООП не является) предполагает исключение подобной каши, которую потом требуется разгребать. Но кто следует этим принципам? Ни в один сорц на OP невозможно быстро вникнуть, например, т.к. серьёзные кодеры с опытом (кто уже понимает в важности комментариев в коде, адекватной архитектуры и т.д.) почти не интересуются им.
Самое оптимальное имхо для более-менее серьёзных проектов — это вообще предварительное моделирование в UML или IDEF0/IDEF3/DFD, а это лишь так, мелкий проект без каких-либо целей, которому суждено стать заброшенным ещё при разработке.