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

korian, надо же. Даже статья на Вики есть. Не знал.

100% тролль ...

именно...

Все верно, как и в предыдущем пояснении, но товариСЧ решил пЕсать для себя... Для себя можно как угодно )))



Ну только вот таких вот обобщений не надо   ... Смотря кто где и над какими задачами работает.


ну Ваши представления об возможностях оператора безусловного перехода несколько искажены. Дейкстра ругал goto за полную дезориентацию синхронизма выполняемых действий - затруднения в очевидности, наглядности работы системы. А совсем, как раз, не за усложнение и утяжеление чтения исходника в пределах одного блока кода - кстати оба Ваших варианта читаются довольно легко. Поколдовав с препроцессором можно добиться ясности и простоты для намного более запутанных случаев... Мало того ПП(или ООП  ) на asm будет тоже тяжелочитаемым. Кстати никто goto собственно и не запрещает, в планировщике задач Linux, что 2.4 что 2.6(более ранних - невидал) он на каждом шагу... И Торвальдс такую работу принимает.
slavaentp
прав в своих кратких тезисах. Все это (+ процедурное программирование) парадигмы - мировоззренческие точки отсчета. Но никто никого не заставляет   ... 


Не совсем верен сам подход... Можно писать ООП на asm. Но это, конечно, экстрим. Но уже для С так очень часто поступают - для тех же микроконтроллеров может не оказаться C++, например, а команда хочет ООП. Кстати, ранние версии GCC преобразовывали C++ в C. И книги встречались на английском как писать на C в стиле C++. Вот неплохой материал по-теме. Ну а все, что можно на C можно и на asm   . 


есть такой язык brainfack... там ничего этого нет. И он работает... Правда именно так как и называется...

Мое скромное имхо по теме...
1) ООП - не панацея от кривого кода. Кто не верит, могу прислать пару модулей, написанных моим коллегой на VB  
2) Модульность и полиморфизм/инкапсуляция/наследование - не одно и тоже. А от переписывания большого количества кода спасать должна правильная структура программы (и модульность - пророк её)...
3) ООП - это все-таки здорово, но только если без фанатизма...

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

Ко всему этому можно добавить, что в классах (и ООП в целом) нет ничего плохого... но только до тех пор, пока их не начинают пихать куда попало. У этой парадигмы есть определенная область применения, а попытки использовать ее в других задачах (к сожалению, чрезвычайно частые) обычно выглядят так, что вызывают желание полностью отказаться от ООП.   

Хорошо, спрошу так: где граница между теми программами, где не нужно применять ООП, и теми, где ООП лучше применить?

по любому прийдется учить ООП  

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

Особенно непонятно про читаемость. Для меня код, состоящий из функций и классов - абсолютно нечитаемый!!! Он же состоит сплошь из юзером определённых функций, названия которых ничего не говорят стороннему наблюдателю!

a = GetString();

b = LetUserInput(3);

InitiateConversation();

и т.д.

При этом - чтобы узнать, что каждая функция значит, нужно прыгать вверх, вниз(не знаешь же, где программист функции разместил, он как попало это часто делает), потом возвращаться к центру, следующая функция, опять вверх-вниз. Разве это удобно и читаемо?

---

В то же время - когда мы имеем дело с чистым листингом, то каждая строка - понятна, потому что она состоит из всем известных инструкций. 

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

---

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

А вот аргумент сторонника goto убийственный(с форума http://www.sql.ru:

"3) Целевой машинный код в конечном счете будет содержать goto, какие-бы вы не использовали структурно-обьектно-функциональные компилляторы.".

Ещё раз, я не спорю, я хочу для себя понять.

Конечно же можно без классов. Но нельзя без ООП, а классы в этом сильно помогают.

Пример огромной программы без классов: linux. Но ООП там есть.

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

И опять же комментарии при объявлении функций еще не отменял.

Кстати мну тут друг недавно рассказывал - пытался одной знакомой по
программированию помочь, у нее простенькая прога максимум строк на 400 на с++ была написана
сплошным текстом (без функций/классов) и с использованием того же goto, причем было много коментов нормальных, так он часа 3
пытался разобраться в этом всем - не смог, и минут за 30 написал то же самое, но с разбивкой
на функции, и заняло это по объему кода намного меньше.

Точно тролль.

Такое ощущение, что здесь почти все кроме slavaentp - тролли.

ООП почти ничего к читаемости кода не добавляет. Объём становится больше - без вопросов. А вот читаемость могут повысить только комментарии, внятные имена переменных и документация.
Я сейчас участвую в проекте на ООП. Куча классов, куча проектов, куча всего. И ни хрена сходу непонятно. Мне дают задание, говорят что надо использовать такой-то класс или либу с набором классом. Я начинаю делать, а потом оказывается, что там не то, или недоделано или есть ограничения, которые обходить дороже, чем сделать заново. В результате куча времени - сами знаете куда. А все потому, что в этой куче кода - ни строчки комментариев, о документации я вообще молчу. 

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

Больше всего в ООП мне не нравятся всякие неявные действия - конструкторы и особливо десктрукторы. От того, что в программе выполняется функция, которой нет в тексте исполняемого модуля, по-моему ни фига не проще программировать. Уже не раз ловил глюк с неявным вызовом деструктора тогда когда это совсем не нужно. 

Мое собственное мнение - классы нужны когда проект большой, его результаты будут использовать много людей. И самое главное - каждый класс отдается другим людям когда он уже максимально отлажен. 
Проблема наверно ещё в том, что многие люди мечтают работать в больших проектах, в больших командах, а поэтому начинают изучать ООП и использовать его где ни попадя. Так появляются всякие мелкие программы , где под каждую функцию написан класс. 

ksili, при чем тут документация?
Разве не логичней, когда у тебя есть класс "строка", ты создаешь объект этого класса, а затем посылаешь сообщение "ToUpper" этому объекту, по твоему лучше когда вместо класса, объекта и сообщения у нас есть область памяти выделенная под строку, указатель на строку, куча переменных хранящих длину строки, кодировку символов и тд и функция, принимающая в качестве параметра указатель на область в памяти и кодировку символов?
Вообще, ###код можно писать как угодно, но код написанный в ООП стиле, если он написан правильно, намного проще использовать и сопровождать. Например мы пишем программу - редактор текста, и у нас есть класс CDocumentElement, от которого порожден класс CText, и от которого в свою очередь порожден CFormattedText, единственное отличие которого от простого текста - наличие форматирования. Теперь представим что нам потребовался класс CImage(наследник CDocumentElement) - встроенное в документ изображение, затем нам потребуется CAlignedImage итд. Это плохой дизайн, в этом случае получится очень сильно упростить программу, если ввести класс CFormat который был-бы декоратором для CDocumentElement и мог-бы изменять поведение вложенного в него объекта. 
Дело даже не в языке программирования, а в подходе, можно и на асме писать ОПП программы.
зы
кстати, хорошо спроектированная программа или библиотека не нуждается в большом количестве комментариев.

Добавлено через 1 минуту и 4 секунды

Такое ощущение, что здесь почти все кроме slavaentp - занимались сопровождением собственного кода  

Lazin, и как часто мы пишем текстовые редакторы, которые будем сопровождать полжизни? 
Я не говорил, что ООП вообще не нужно. Если проект большой - пожалуйста. Но большая часть программ - не такие крупные проекты как Word. 
И еще. Меня всегда поражал такой фанатизм в дроблении: сделаем Image, из него AlignedImage, из него ещё какой-нибудь имэйдж... Любит человек размножаться ничего не скажешь... Нельзя было сразу сделать объект со всеми нужными свойствами? AlignedImage же тоже можно сделать невыровненным.

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

у тебя опять же  будет, только кроме этого ещё куча воды.