Где учат правильно проектировать и программировать <Anwendungen> ...???
Чтобы легко можно было что-то изменить...
можете посоветуйте литературу...
как-то написал для одной фирмы программку небольшую...на 1500 строчек..кода..
теперь попросили кое-что изменить...смотрю в код..и нечего не понимаю...
особенно всю логику ...хотя всё написал от и до сам..но 8-мь месяцев назад...
особенно непонятно зачем мне так много переменных около 50 штук...
начинаю распутывать...натыкаюсь на процедуры..вызывающие другие процедуры..и так далее...
голова кругом идёт...
как правильно оформить код...???
скажу сразу, я не программист...

так это нормально, когда смотришь на свои старые программы, впадать в шок 8-)
вообще-то, вопрос сложный.
Все зависит от того, что ты уже знаешь.
На каком хоть языке прога написана?

<VB> с некоторыми кусками из <API>

Но этот язык не собираюсь больше мучить...
на данный момент интересует <Delphi> <C++> ..освою маломальски Си перейду на <.net>...
а разве нет каких-то общих правил...

а точных правил и нет...
Есть только спецификации на уровне себя лично, на уровне проекта, на уровне фирмы...
Каждый со временем становится более опытным. В результате чего давно писаный код кажется совсем непонятным и от части бредовым. Через это все проходят.
Я часто ужосаюсь смотря на с свой старый код. Учитывая, что я только в начале карьерного пути, то ужосаться прийдется еще долго... Про тебя можно писать тоже самое. Ты еще тоже молод и неопытен.

а как вот <Murr> переписывает чужие программы...
какие-то прозрачности...у него там..

есть общие правила, но языки бывают разные, которые то поддерживают, то не поддерживают правила:-)
Ну, начни с основ ООП:
классы, обьекты, полиморфизм, интерфейсы, наследование.
Потом переходи на UML, чтобы ты мог моделировать свои приложения и потом не вспоминать, чего ты там творил.
Вот тебе ссылка на видео-уроки для нового Visual C# 2005 Express Edition:
http://msdn.microsoft.com/vstudio/express/visualcsharp/learning/default.aspx
Так что, начинай сразу с .NET 8-)
Попытайся вникнуть, что и как они создают.

прикольные уроки...но у меня <Visual Studio .Net 2003> они сильно различаются...??

сильно.
но на правила программирования эти проги не влияют.
Просто в VS 2005 больше функций и она основана на .NET 2.0

Если пишешь используя ОО и процедурные парадигмы, то прочитай книгу Мартина Фaулера "Рефакторинг" и книгу "the gangs of four": "Design Patterns". Эти две книги прочесть обязательно.
От себя добaвлю: пиши везде комментарии. Параноидально. Дaже, если они кажутся идиотскими. Второе, всегда, вообще всегда, закладывайся на то, что будешь менять программу потом. Обдумывая функциональность класса / модуля, которыe будешь использовать в программе, начинай с дизайна, т.е. думай о том, как именно клиентская часть будет использовать данныe сущности. Избегай ненужных связанностей. Каждая отдельная сущность должна в минимальной степени зависеть от других. Избегай больших методов. В иедале не более пяти строк на метод. Мозг не в состоянии одновременно концентрировать внимание более, чем на пяти-семи объектах. Избегай ненужных хаков. Признак профессионализма - лёгкое понимание кода.
В общем, вот. Удачи.

Мурр нормально переписывает чужие программы.
Только вот у Мурр'а своего написанного кода... он и не знает сколько. И в добавок еще переделанного из-под других и _разных_ наверное не меньше.
Теперь вопрос об том _как_ это делается.
1. Есть две крайние точки - информация в базе и информация на экране. Чем меньше всяких ненужных вещей между ними - тем лучше.
2. Всегда есть какая-то спецификация/документация . Что требуется на начальном этапе - определить насколько эта документация соответствует тому что реализовано. Все, что не соответствует идет не как переработка, а как разработка с нуля.
3. Выберается архитектура, которая используется в проекте, а лучше - которая может использоваться и в других проектах. Как результат - получаешь "скелет" приложения - не надо будет думать что и где - оно будет определено выбранной архитектурой, нужно будет только реализовывать то что нужно.
4. Приводишь то, что имеешь, к выбранной архитектуре. Понятное дело, что весь проект сразу ты не поднимешь, но те части, в которых ты что-то меняешь, должны выходить из твоих рук уже полностью соответтвующими выбранной архитектуре.
5. Код, который ты пишешь, должен быть простым и понятным, не должен содержать трюков, не должен использовать ничего, кроме того, что стандартизовано. Сложные, выпадающие из принятой архитектуры, вещи должны быть выделены.
и наконец - нулевое правило - ПРОЕКТ ДОЛЖЕН БЫТЬ ДОКУМЕНТИРОВАН. Кроме того, документация на проек разрабатывается не по факту написанного кода, а поэтапно разрабатывается. Кодинг же входит как составная часть создания проектной документации и на него приходится отнюдь не основная часть работы.
Вроде все.

Если пишешь используя ОО и процедурные парадигмы, то прочитай книгу Мартина Фaулера "Рефакторинг" и книгу "the gangs of four": "Design Patterns". Эти две книги прочесть обязательно.
Рано ему ещё об этом.
От себя добaвлю: пиши везде комментарии. Параноидально
Не согласен. В самом коде комментарии практически никогда не нужны. Где они действительно нужны - это описание функции: Vor- und Nachbedingungen, аргументы.
В иедале не более пяти строк на метод.
Да ты экстремал. Функции бывают разные, моё правило - должна помещаться на экран.

В самом коде комментарии практически никогда не нужны.
------
Если есть нормальная документация на проект - нужны только ссылки на нее.
Но! В случае автора вопроса - писать коментарии, параноидально, можно даже
без кода. По одной из методик обучения, которую я когда-то практиковал в
той стране где сейчас маршируют СС-овцы и уже ищут как остановить поток
эммигрантов, делалось так:
- в "темную", т.е. так, чтобы не видел "сосед", давалось качественное задание и
время на его изучение и задавание вопросов.
- затем задание отбиралось и требовалось не делая код, написать своими словами
что и как должно считаться (повторить постановку задачи).
- затем эти описания просто передавались "соседу" и уже он должен был делать
код.
Разумеется на певый-второй раз ничего не получалось, но была возможность
в живую выяснить что именно было упущено в описании. По прошествии 3-4
занятий люди уже не имели проблем с написанием качественных комментариев
к своему коду.

Монитор у тебя надеюсь не 30 дюймовый

Нет, всего лишь 18-дюймовый TFT.

От себя добaвлю: пиши везде комментарии. Параноидально
Не согласен. В самом коде комментарии практически никогда не нужны. Где они действительно нужны - это описание функции: Vor- und Nachbedingungen, аргументы.

А по мне -- так лучше параноидально комментировать, чем уже на следующий день смотреть грустными глазами и ничего не понимать. Есть задачи, которые в принципе нельзя раздробить на маленькие, которые по пять строчек кода. Напишешь, например, восемь вложенных ветвлений, а потом смотришь на них и думаешь "мать моя, где ж какое кончается". И в следующий раз, уже помудревший, начало и конец каждого комментируешь.

о, *Рефакторинг* у меня даже на русском есть:-)
По *Design Patterns'ам* вот ету книгу очень хвалят:
http://www.amazon.com/gp/product/0596007124

Не согласен. В самом коде комментарии практически никогда не нужны.
Не согласен 8-)
Даже потому, что после тебя возможно кто-то этот код будет смотреть и пытаться понять.

Выбирай названия переменных и функций подобающим образом, и комментарии будут не нужны.

Я конечно не великий профессионал, как некотрые, но считаю, что грамотно откоментированый код ничего не заменит. Особенно для новичков ето оптимальный вариант. С опытом програмирования логически правельная структура кода сама установитса. Тем более, что творческий елемент тоже присудствовать должен...