Я согласен. Не обязательно, что нам нужно больше goto, но иногда программисты идут на смехотворные меры, чтобы их избежать: например, создают причудливые конструкции вроде: do {... break; ...} в то время как (ложь); имитировать goto, делая вид, что не используете его.

Особенно, когда вас учат, что такое GOTO в течение всего семестра и как их использовать, тогда в следующем семестре приходит новый лектор, скандируя смерть инструкции GOTO в безумии необъяснимой и нелогичной ярости.

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

Я использовал GOTO в операторах switch, чтобы логика переходила повсюду, и у меня не было проблем с этим (не считая того факта, что я заставил FxCop жаловаться на сложность рассматриваемого метода).

Я видел только 1 пример хорошего использования за последние 5 лет, так что сделайте 99 999 процентов.

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

Нет-нет-нет-нет-нет. Так много производственного кода уже настолько запутано и неясно. Вы бы дали обезьянам больше инструментов.

Я не думаю, что смогу найти хотя бы одно хорошее применение GoTo в .NET-приложении ... вы можете привести пример его правильного использования?

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

Я слышал объяснение, что GOTO делают стек недетерминированным. Если вы попали в строку с GOTO, невозможно узнать, как вы туда попали. Значительно усложняет отладку.

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

Приятно видеть, что это действительно вызвало много споров!

Я считаю, что goto не очень читаемы. Я презираю их в SQL, так зачем мне их использовать где-нибудь еще?

@ Джереми, вы можете сделать goto в SQL? SQL - это декларативный язык. У какого поставщика базы данных есть SQL, который знает goto?

@tuinstoel, MSSQL поддерживает его как минимум с 6.5. Я часто использую его для начала, транзакции фиксации / отката в хранимых процедурах.

@ Джереми, разве вы не имеете в виду T-SQL вместо SQL?

Насколько мне известно на ассемблере / машинном языке, все ветвления являются формами goto. Во что скомпилирован ваш язык высокого уровня? Нет ничего плохого в случайном использовании ярлыков «низкоуровневого стиля», если все сделано правильно.

Continue = goto для циклов; Break = перейти к блокам; переключатель = goto безумие; Очевидно, что Goto не проблема, если использовать его с некоторой долей здравого смысла. Если вы используете объектно-ориентированный язык и используете Goto для ошибок и очистки, вы меня пугаете. RAII и его аналоги следует считать вашими друзьями.

+1 за споры :). О, я знаю, что такое GOTO, я начал с BASIC, как и многие из вас. Нам нужно больше GOTO, как нам нужны имена файлов DOS 8.3, простая кодировка ASCII, файловые системы FAT 16 и 5 1/4 дюймовые дискеты.

Только что нашел это: stackoverflow.com/questions/84556/…

Хороший пример goto: stackoverflow.com/questions/416464/…

Я довольно часто использовал goto в программировании на C - обычно как блок finally. У меня есть дескриптор файла, который мне нужно закрыть, память, которую мне нужно освободить, и т. д., Поэтому в момент, когда я вернусь раньше, я просто устанавливаю код возврата и перехожу к метке cleanup :.

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

Goto может быть в порядке. Мое практическое правило. Если хороший программист, который нечасто использует Goto, готов защищать его - тогда все в порядке. И, наверное, раз в год, если это так. Дмитрий, похоже, что FxCop прав, а вы ошибаетесь.

Эта ветка считается вредной. Эдсгер Дейкстра катается в могиле. :)

Согласовано. Я изо всех сил пытаюсь перевести числовой код из Фортрана в F#, потому что ему не хватает эффективной конструкции goto.

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

Люди, которые считают gotos злом, никогда не программировали на C, а если и программировали, то делали это плохо. Gotos - это способ Лучший для обработки ошибок на простом C, и повторение цитаты Дейкстраса догматически демонстрирует только незнание. Пожалуйста, прочтите это, прежде чем жаловаться на gotos: eli.thegreenplace.net/2009/04/27/…

Чтобы дополнить замечание catphive об использовании goto в C, вот обсуждение goto разработчиками ядра Linux, когда один человек перескакивает на goto и продолжает рекомендовать избегать его любой ценой: kerneltrap.org/node/553/2131

Собственно, обсуждение использования goto в Linux заставило меня передумать, действительно ли goto вреден для разработки. Я научился не просто доверять тому, чему ты учил :).

Мне были нужны gotos в C, потому что он не имеет эквивалента для Java "continue loopname;"

Однажды меня отправили домой из колледжа за то, что я сказал кому-то использовать GOTO: P

События - это современный оператор GOTO. Вы прибываете откуда угодно и когда угодно с дополнительным багажом данных, которого у GOTO никогда не было.

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

«У них есть цель, и они могут значительно упростить производственный код во многих местах. Тем не менее, они не нужны в 99% кода, который вы когда-либо напишете». +2 Если бы я мог, сэр, это лучше не было бы написано.

Извините, но я очень рад, что не видел инструкции GOTO после переноса программы QuickBasic на C#. Дайте мне перерыв в любое время.

Да! Его идеи о иерархических структурах данных изящны с академической точки зрения и совершенно бесполезны.

Что ж, мне нравится Celko, но я согласен с вами re: суррогатные первичные ключи!

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

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

Я могу согласиться с концепцией, что, если ваши ключи автонумерации не совпадают, исправить их невозможно. Но решение - не «естественные» ключи; решение - никогда не открывать ключи своим пользователям.

Я хотел бы вернуться на несколько лет назад к моему текущему проекту и сказать себе не использовать естественный ключ. Теперь мы застряли в этом и кидаемся вокруг него. +1

@ocdecio: Фабиан Паскаль дает (в главе 3 своей книги, как указано в пункте 3 на странице, на которую вы ссылаетесь) в качестве одного из критериев выбора ключа ключ стабильность (он всегда существует и не меняется). Если естественный ключ не обладает таким свойством, то необходимо использовать суррогатный ключ по очевидным причинам, на которые вы намекаете. Итак, вы на самом деле согласны с ним, но думаете иначе. Ничего противоречивым там: он говорил «не догматические, адаптировать общие принципы к обстоятельствам, и, прежде всего, считать, использовать свой мозг, а не догматический / поваренную книгу / слова-о-гуру подхода».

Одна из классических ошибок - предположить, что вы получите уникальные значения только потому, что естественный ключ кандидата, такой как SSN, по определению уникален. Люди могут лгать или совершать ошибки, и тогда у вас есть шанс столкнуться, когда появится «настоящий человек».

Согласитесь, но не очень спорно?

это спорно, потому что некрасиво беспорядок, что большинство людей называют MVC в основном «сделать все»

Действительно? На самом деле я думал, что MVC был противоположностью этого.

Этот ответ, кажется, вызывает споры о его противоречивости. ;П

Я согласен RE: MVC - действительно сложно ограничить раздувание методов на контроллерах

Re MVC: если проблема заключается в раздувании методов, тогда сделайте больше контроллеров, они не должны быть раздутыми методами, это не кажется правильным, если это произойдет, кажется, что контроллеры пытаются сделать больше, чем они должны.

Если вы не думаете, что это спорно, вы, вероятно, не знаете, как далеко вы можете пойти с этим. :-)

Да, видимо, это очень спорная точка зрения

BLASPHE --- !! Я имею в виду, да, я полностью согласен.

Похоже, что написание книги по C# еще не означает, что вы знаете все о VB;)

Я думаю, вы можете быть в курсе фактов о Джоне Ските. Помните: «Может ли Джон Скит задать вопрос, на который он не может ответить? Да. И он тоже может на него ответить». Он всемогущ!

Сначала я подумал, что вы сказали, что Джон Скит не импотент.

@Totophil: Интересный комментарий, если учесть: Джон Скит задал этот вопрос (и он опубликовал ответ ...)

Это хорошо. Точно так же небрежно оскорбляют людей во имя «правды». Этот конкретный вирус, кажется, имеет резервуар в аспирантуре, вроде той, которую я посещал.

Не могли бы вы выделить свое неоднозначное мнение ... это "viewstate плохо" или что-то еще?

Нет, это «ViewState включен по умолчанию, хотя я действительно не думаю, что это должно быть, но для его отключения по умолчанию требуются настраиваемые элементы управления»

Я ожидаю, что любой, кто работал над ASP.NET, согласился бы с этим. У нас есть страница для поиска сторонней системы, на которой есть БОЛЬШИЕ раскрывающиеся списки. ViewState удвоил размер страницы уже 200 КБ.

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

Да, время от времени мы сталкиваемся с удвоением размера страницы, а иногда даже больше. Страница отображается медленнее, используется большая пропускная способность, и отслеживать проблемы при просмотре исходного кода страницы - кошмар.

Интересно то, что в большинстве случаев ViewState вообще не нужен!

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

Вы пробовали программировать без ViewState? Я могу обещать вам, что 5 минут с JSP вернут вас запустить во ViewState. Серьезно, ViewState - это проблема НИКОГДА, проблема в том, что разработчик использует ViewState!

@ Пол, я безумно согласен! Не кидайте на страницу столько дерьма, если у вас проблемы с ViewState - вернитесь к дизайну!

Попробуйте ASP.NET MVC, с ним приятно программировать.

Вам не нужно отключать ViewState для каждого элемента управления. Вы можете сделать это в директиве @Page.

Я думаю, вы переоцениваете объем управления памятью, который имеет место в современном C++. C++ теперь повсюду использует идиому RAII. Утечки памяти больше не вызывают большого беспокойства или проблемы.

если вы не можете отследить утечки памяти, вам не стоит использовать мощные инструменты.

согласен с Дугом; с помощью некоторых простых практических правил утечки памяти в основном устраняются.

Не говоря уже о том, что не все программы работают исключительно в последней версии Windows.

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

И иногда вам нужно выбрать ярлык, несмотря ни на что. Мне нужна максимальная производительность в том, за что мне платят. Для большинства людей это не так.

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

Эй, как насчет того, чтобы не беспокоиться о производительности, пока она действительно не станет проблемой, а затем, когда это произойдет, профиль, Профиль ПРОФИЛЬ. Именно в этот момент можно принять решение, сокращать ли путь через минное поле. Это пустая трата денег и времени, чтобы решить, прежде чем это необходимо.

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

Привет. Меня зовут Ларри. Приятно познакомиться со всеми вами. :) Я думал, что я один в этом мире, потом я нахожу всех вас, которые думают так же, как я ... Как вы увидите в МОЕМ ответе на этот вопрос. Я ОГРОМНЫЙ поклонник C / C++ и считаю, что если вы не можете правильно использовать C / C++, то не делайте этого вообще. C# НЕ требуется.

Рассуждения несбыточной мечты. Земля зовет маркумку

Если бы у нас были действительно хорошо написанные фреймворки для запуска управляемого кода, то я бы сказал, что у вас есть хороший аргумент. К сожалению, с каждым выпуском .NET framework становится все более раздутым, и правда в том, что C++ остается для разработчика единственным способом писать на достаточно высоком уровне и быть уверенным в [способности достичь] хорошей производительности.

Утечки памяти невозможны в C++, если вы используете правильные методы: используйте указатели RAII / Smart вместо необработанных указателей / дескрипторов В худшем случае используйте Valgrind

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

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

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

На самом деле, я думаю, что в Ruby есть что-то, что привлекает вас обоих - это виртуальные атрибуты. Это позволяет вам проверять свои назначения и по-прежнему иметь доступ к данным, как если бы он был публичным участником.

Python также позволяет вам это делать.

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

Но сейчас 2009 год, и кто все еще использует IDE, которая не создает геттеры и сеттеры при нажатии клавиши ...?

Дело не только в том, что я должен писать код, но и в том, что геттеры и сеттеры запутывают сам код, в 95% случаев, когда мои приложения занимают место и просто уродливы.

Думаю, C# дает вам простой способ получить и то, и другое, это Java?

У меня было / есть такое мнение в некоторых случаях, но для меня ОЧЕНЬ важным фактом является то, что вы не можете «переопределить» общедоступную переменную. Если рассматриваемый класс окончательный, запечатанный, что угодно - круто ... И если вы в основном говорите, что расширители никогда не должны иметь возможность делать что-либо при установке / получении ... когда-либо ...

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

И как именно установить точку останова в публичном поле? Сеттеры великолепны именно по этой причине - вы можете легко увидеть, какой код влияет на значение.

Вы должен используете геттеры и сеттеры при кодировании интерфейса!

1. Используйте редактор, который сокращает процесс 2. Использование сеттеров и геттеров намного безопаснее, чем прямой доступ к переменной: что, если вы напишете класс с переменной внутри: counter и включите его в код (возможно, в 100 классов) и теперь вдруг решите, что счетчик не может быть отрицательным? использование сеттера может помочь решить подобные проблемы ... 3. Иногда раскрытие переменных может быть опасным; например: предоставление TOS в классе стека

@Richard Berg В VB6 вы можете изменить публичное поле на свойство и наоборот, не требуя никаких изменений в коде, который его использует, даже не перекомпиляции. Это одна из немногих областей, где VB6 был IMHO лучше, чем .Net.

@ Thorbjørn - не обязательно. Тот факт, что разработчики C# / Java решили запретить использование полей в интерфейсах, не делает это изначально плохой идеей. Прямой доступ - это доминирующая идиома в таких разнообразных языках, как C и Ruby.

@Mark - установить точку останова по данным. Ваш CPU имеет аппаратные прерывания именно для этой цели. Заставить его работать на управляемом языке немного сложно, но не сложнее, чем проблемы, присущие отладке в программном режиме в целом.

@ Ричард Берг: Я вас не понимаю - прямой доступ является доминирующая идиома для C, но определенно не для Ruby - на самом деле, без рефлексии в Ruby нет способа сделать прямой доступ. Ruby дает вам чрезвычайно простой способ (attr_accessor :x) генерировать геттеры / сеттеры для атрибута, которые синтаксически прозрачны; то есть вы все равно будете использовать p.x и p.x = 3 вместо p.getX() и p.setX(3), но это все еще методы. «Прямая» переменная экземпляра будет @x, и вы не можете использовать с ней точечную нотацию (т. Е. p.@x не грамматичен).

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

Я считаю, что по умолчанию в C++ все методы делаются не виртуальными, поэтому C# вряд ли сделал шаг в правильном направлении. Я бы назвал это возвращением к их корням C++.

Однако C# на самом деле не укоренен в C++ - он довольно сильно укоренен в Java. ИМО, конечно :)

Это не спорно - это здравый смысл :)

Я понимаю, что связь между C# и Java определенно сильнее, чем у C++, но если бы мы рисовали диаграмму наследования, они оба заявили бы, что C++ является родителем (возможно, прародителем C++).

+1 от меня. Мне очень редко приходится удалять модификатор sealed (и я делаю все запечатанным по умолчанию, если сразу не ясно, что его нельзя запечатать).

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

«Я считаю, что по умолчанию в C++ все методы делаются не виртуальными, поэтому C# вряд ли сделал шаг в правильном направлении», как это логично? я скучаю по связи. делать методы невиртуальными по умолчанию в C++ - это хорошо (imho) +1

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

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

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

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

+1 от меня тоже. Речь идет о том, чтобы избегать неявных предположений, которые всегда возвращаются, чтобы вас укусить. Явное заявление всегда точнее.

@balabaster: Если вы сделаете это, а затем я захочу внести изменения, очень вероятно, что ваш код сломается. Как поставщик кода, я не хочу ставить клиентов в положение, когда у них хрупкий код. (Не то чтобы я на самом деле поставщик кода и т. д. Это теоретически.)

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

Даже в этом случае я должен понимать риски, связанные с получением незамерзшего класса. Любые изменения, которые вы вносите в незапечатанный класс, влекут за собой тот же штраф, поэтому все, что вы делаете, делая все запечатанным по умолчанию, затрудняет использование вашего кода по-своему.

В принципе согласен, хотя я ненавидел запечатанное по умолчанию поведение методов, когда я использовал ранний C# (на самом деле в Microsoft), потому что иногда мне хотелось перехватывать вызовы метода некоторого библиотечного класса, но я не мог просто создать подкласс, потому что они не делали методы виртуальными.

Если наследующий класс изменяет поведение метода, это неправильно. Период. Это не соответствует принципу заменяемости. Не нужно делать класс запечатанным, просто застрелите обидчика.

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

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

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

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

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

@Josh: Да, это определенно интересная идея. Есть несколько вариантов, в которых я не хочу быть явным - например, "нелетучие" было бы глупо. Как насчет «записи» как противоположности «только для чтения» для статических переменных и переменных экземпляра? Хм...

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

Самый веский аргумент в пользу того, что классы НЕ должны быть запечатаны по умолчанию, - это то, что это отрицательно скажется на экологии программных библиотек (коммерческих и внутренних). Слишком мало людей тратят время на то, чтобы подумать о том, как их классы могут быть унаследованы - это сложно сделать правильно. Большинство будет придерживаться языка по умолчанию. Программное обеспечение меняется относительно медленно (даже если у вас есть код), и изменение наследуемости будет происходить с задержкой. Наконец, действительно ли люди будут тратить больше времени на проектирование для наследования? Или просто слепо добавить «переопределяемый», когда найдут случай, когда они решат, что им это нужно?

@LBushkin: Тот факт, что люди не тратят времени на то, чтобы обдумать вещи должным образом (и что это трудно понять правильно), именно поэтому по умолчанию должна быть опция безопасный. Дайте людям дробовик выгружен и заставьте их зарядить его сами, если они захотят.

Что делать, если вы не знаете, когда условие ложно? А откуда появился Repeat? Хотя работает на английском языке «пока это условие выполняется, сделайте это»

Вы можете заменить все конструкции на goto.

Мне не только нравится WHILE, но я бы также позаимствовал Nemerle UNLESS и поместил его в C#.

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

Я не видел Repeat ... До тех пор, пока BBC BASIC! VB теперь имеет Do ... Loop, Repeat ... Пока и Пока ... Wend должны быть удалены. Меня это беспокоит, когда я вижу: Do While Not ... вместо Do While ...

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

Это нонсенс. Ни repeat, ни while не сломаются посередине, так что ваш аргумент абсурден. В основном разработчиков нужно проинструктировать об использовании break / exit / goto для раннего выхода из цикла. Что касается условий тестирования в начале / конце, оба имеют свое применение.

Также do {statement} while (! Условие) совпадает с do {statement} до (условие), поэтому я не знаю, в чем заключается жалоба.

На самом деле, я не уверен, то же самое или нет, но я никогда не использую блоки do ... while, поэтому я думаю, что, возможно, я согласен с вами. :)

«Один общий ... флаги ложные» - Насколько это распространено? На каком языке? Возможно, ответ для тех, кто имеет эту идею, когда она ложна, - «RTFM!». Это просто плохое решение для поиска проблемы, которую он не может найти.

A while с повторением - это if <not condition> then repeat until condition not a while + bool

Я заметил определенную обратную зависимость между навыками проектирования / кодирования и навыками использования отладчика (что не то же самое, что наличие навыков отладки).

Я продолжаю удаление копирования и вставки. Я часто вижу, как мои коллеги копируют и вставляют 20 строк кода и просто меняют значение.

На мой взгляд, копирование / вставка - это моментальный красный флаг. Если код дублируется, он должен: а) быть факторизован с использованием объектно-ориентированных методов; или б) управляемая моделью / генерируемая / определяемая dsl.

Я согласен, весь код, который вы видите в stackoverflow, не следует тестировать, потому что, если он протестирован, он копируется из IDE, и копирование из IDE должно быть невозможно :) Поэтому, пожалуйста, публикуйте только непроверенный код на SO!

@tuinstoel: Может быть, это должно быть «копировать, но не вставлять»? :)

возможно, он должен просто не разрешать копирование и вставку исходного кода в одном приложении, может быть интересно написать плагин eclipse, который предотвращает это :-)

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

Синглтоны выглядят очень умно, когда они привязаны к WPF (все это x: Static).

Итак, вы удалите все отладчики и все альтернативные системы для отладки. (если простой путь плох, то и трудный путь хуже, не так ли?) Затем при тестировании вы обнаруживаете ошибку. Что ты теперь делаешь? Отменить проект?

@charles, когда я обнаруживаю ошибку, я пытаюсь воспроизвести поведение в модульном тесте. Потом исправляю. Если вам нужен отладчик, это просто знак того, что вам нужны более качественные тесты или рефакторинг кода, который легче понять.

Иногда мне приходится поддерживать и расширять программы, которые широко используют арифметику сложных указателей. Вы можете вырвать мой отладчик из моих холодных мертвых рук. И если какой-либо разработчик упомянет слово «глобальный» в той же комнате, что и я, он может считать, что ему дали пощечину.

@Jon Skeet, если возможно только копирование, я не могу вставить из SO :)

Правильно ... Избавьтесь от отладчиков - чтобы вы не могли видеть результаты своего кода до конца, вместо того, чтобы шагать вперед, чтобы увидеть, где именно ГДЕ возникает проблема. Я возьму отладчики за десятки «временных, промежуточных операторов отображения» ЛЮБОЙ день.

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

Не имея возможности отладить это, как вы можете сказать, что нужно изменить, чтобы исправить это? ты дальновидный? Если да, то почему вы вообще поместили туда ошибку? «Отладка» и «Отладчики» по определению являются инструментами, которые мы используем, чтобы выяснить, что вызывает ошибку. Без них вы не сможете исправить ни одну ошибку.

За исключением, возможно, случайного подхода с дробовиком и БОЛЬШОЙ удачи (просто измените что-нибудь, проверьте еще раз и повторяйте, пока ошибка не исчезнет ...)

И вывод значений переменных или операторов «Я здесь» в текстовый файл ЯВЛЯЕТСЯ отладчиком!

«Отладчики должны быть запрещены». - и как вы находите ошибки, которые не ваши, но происходят из библиотеки / платформы?

Ух ты. Это все равно, что сказать: «Если молоток не справляется, этого не стоит делать». Серьезно, как бы вы отследили перезапись памяти, происходящую вне вашего объекта, с помощью модульных тестов?

Вероятно, термин «Отладчик» просто неправильный. Мне еще предстоит увидеть инструмент, который устраняет ошибки (устраняет ошибки) в моей программе.

@simon: rm или del удалит все ошибки. Конечно, удаляет и остальную часть программы, но такова цена за безглючную программу :)

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

Стив Макгуайр полностью использует главу 4 книги «Написание надежного кода», чтобы продвигать идею пошагового выполнения нового или измененного кода в отладчике. Хороший совет. Отладчик злоупотреблять - это отдельная история. Я тоже это видел, но не предлагаю отказаться от этого инструмента, потому что некоторые будут злоупотреблять им.

+1: определенно спорное мнение, основанное на комментариях к этому посту :)

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

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

Eek - без копирования и вставки? Что происходит, когда я решаю, что мне нужно переместить блок кода из одного класса в другой? Ты заставишь меня перепечатать все вручную? Нет отладчика ... да, я, наверное, мог бы обойти это, хотя было бы больно. Я, наверное, тоже смог бы жить без Синглтонов.

@balabaster, который вырезал и вставил, а не копировал и вставлял. Так что я бы позволил это ;-)

Я согласен с балабастром - нам нужно вырезать и вставить для рефакторинга или чего-то подобного.

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

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

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

Что касается синглтонов, это может быть неправильным для таких языков, как C# или Java, но с менее строгими языками ООП, такими как Javascript или Scala, использование синглтонов в порядке. В JS каждый объект - синглтон! (и классифицируется с использованием прототипов, по крайней мере, в JS 1.x) А в Scala есть одноэлементный тип, называемый object.

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

@martinus, может быть, это для вас, но я все время копирую и вставляю собственный код. У меня никогда не было проблем с тем, чтобы вернуться и что-то исправить. Я занимаюсь этим почти 30 лет. Я не вижу практических причин менять сейчас.

Я хочу проголосовать за ваш комментарий Singleton и проголосовать против вашего комментария Debugger ... Вам нужен отладчик, чтобы выяснить, почему этот дамп ядра существует в первую очередь (только тривиальный код можно проверить на 100%).

@martinus, дело не в том, что копипаст - это плохо, но в вашем примере программист должен использовать общую функцию, а не дублировать кусок кода. Таким образом, если в функции есть ошибка, вы исправите ее в одном месте. Но есть сценарии копирования и вставки, в которых вы бы не использовали общие строки функции one liners.

Как исправить драйвер без отладчика ... Напишите юнит-тест, воспроизводящий ... Подождите.

Фундаментализм - это не путь вперед!

Я согласен избавиться от копипаста, если вы все еще можете вырезать-вставить. Вырезание и вставка кода необходимы для рефакторинга и поддержания кода в чистом состоянии.

Ты свихнулся? <wink> Я проголосую за вас только потому, что я так категорически не согласен (и это вызывает споры - по крайней мере, для меня). Мне нужны эти инструменты. Это было бы похоже на наказание всех налогом на нездоровую пищу, потому что некоторые люди не могут себя контролировать.

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

Мне было бы интересно услышать здесь ваши рассуждения, а также о том, о каком методе CompareTo вы говорите.

Я говорю о методе C# IComparable.CompareTo. Не ожидайте, что два реализующих объекта IComparable равны, если метод CompareTo возвращает ноль. У них просто такой же порядок.

Тогда ваша реализация IComparable не работает. В документации указано, что возвращаемое значение нуля означает «Этот экземпляр равен obj». Я не говорю, что там нет сломанных реализаций, но ваш коллега может разумно указать на документы ...

Я бы сказал, что если у вещей нет естественного отношения равенства / порядка, лучше иметь отдельную реализацию IComparer, которая может выразить это явно. Конечно, есть непростые крайние случаи - например, 1.000 м равно 1.0 м?

это хороший случай ограниченного взгляда. проверьте множество предикатов 'compare' в схеме

Джон, не могли бы вы быть так любезны и указать мне строки в документации, где говорится: «a.CompareTo (b) == 0 подразумевает a.Equals (b) == true»?

Конечно. Документы к ICompable.Compare означают, что «a.CompareTo (b) == 0» подразумевает, что «a равно b». Документы для object.Equals означают, что "a.Equals (b)" должно возвращать истину, если a равно b. Можно утверждать, что документация слишком узкая или неполная (документация Java более осторожна в этом отношении)

но документация действительно кажется явно ограничивающей. Он действительно говорит, что значение «равно» зависит от реализации, но по крайней мере сбивает с толку, что «равно» означает что-то другое внутри того же типа между двумя методами.

Вот почему я думаю, что проще реализовать неестественный порядок (т.е. когда равенство в порядке не означает равенство между объектами) через IComparer вместо IComparable.

JavaDocs, где это красиво и понятно (по сравнению с MSDN для IComparable): java.sun.com/javase/6/docs/api/java/lang/Comparable.html Он даже говорит, как документировать время, когда вы нарушаете согласованность с равными.

Конечно, учитывая количество комментариев, обсуждающих эту строку, я думаю, что мы вправе считать ее хотя бы немного неясной.

Зато 7 комментариев до этого были моими :)

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

ладно с этим, так что вы повторяете ... исправляете дизайн теперь, когда вы обнаружили что-то новое и продолжаете работу. Ваш код снова является выражением вашего дизайна. Разработчики думают, что дизайн следует коду, который мне подсказывают.

Я бы хотел, чтобы мне разрешили проектировать, прежде чем я буду писать код. В этой работе это «У меня есть идея» от somoene, за которой следует указание получить что-то в демоверсии как можно скорее.

Большая часть моего дизайна отмечена в файлах заголовков и / или в нескольких диаграммах на белой доске. Я ничего не говорю о том, насколько формальным должен быть ваш дизайн или как это делать, но, ради Бога, разберитесь с мыслями перед написанием кода!

Меня раздражало обратное, слишком большое значение придается дизайну. Мантра «повторно используйте дизайн, а не код» забывает время, потраченное на реализацию, тестирование, отладку и в целом укрепление кодовой базы. Вы не можете просто выбросить такое количество тренировок.

@ Даниэль: Думаю, я согласен с тобой. В то же время важно быть готовым и иметь возможность часто и поздно пересматривать дизайн и код. Для этого нужны навыки, которым, я боюсь, не учат.

@Mike - Я не говорю, что мы все вернемся к модели водопада. Напротив, как разработчику вы должны ожидать, что что-то изменится, поэтому проектируйте свою систему с учетом изменений (например, минимизируйте взаимосвязь) и ожидайте неожиданных итераций, которые повлияют на ваш дизайн. Вы правы - этому не учат.

Так что, если вам все равно нужно выполнить итерацию, выбор сначала разработать или сначала написать код, по сути, одно и то же.

@Kendall: ты шутишь, да? Возможно, вы думаете о доказательстве индукции для своего утверждения, но я надеюсь, что количество итераций для написания фрагмента кода, закрытого от изменений, невелико. В этом случае я считаю, что сначала дизайн намного эффективнее.

Я верю в итеративный дизайн. Если вы заранее потратите слишком много времени на дизайн, у вас не будет времени на необходимое переписывание (что всегда происходит).

+1 вроде. Я использую свой планшет, когда мне нравится ручка и бумага, потому что иногда писать проще, чем использовать программное обеспечение.

Вы имеете в виду «все», а не «ничего»?

Ну, он сказал: «Вам не нужно программировать», и я полностью согласен - меня никто не заставлял программировать, просто мне это нравится. Извините, но здесь нет разногласий.

Нет-нет, мне нужно много чего программировать.

Вам не нужно все программировать

+1 для низкотехнологичных. Иногда электронная таблица Excel отлично справляется с задачей вместо кодирования дорогостоящего CRUD.

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

Да, юнит-тесты заранее не имеют смысла. Если я это записал, я подумал о возможности. Если бы я подумал о возможности, если я не полный идиот, это, по крайней мере, сработает с первого раза, где будет применяться тест. Тестирование должно уловить то, о чем я НЕ думал!

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

Я работал в компании, которой требовалось 95% тестового покрытия, даже для классов, содержащих поля для назначения и никакой бизнес-логики. Код, созданный в этой компании, был ужасен. Моя нынешняя компания не пишет никаких модульных тестов, вместо этого полагаясь на интенсивный контроль качества, а код первоклассный.

Я пишу модульные тесты, когда считаю, что они мне нужны, но, что более важно, я пишу случайные тестовые драйверы, потому что мой код может работать нормально в 100% предсказуемых случаях. Меня беспокоят непредсказуемые случаи.

В моем текущем проекте я ввел предварительные модульные тесты, и качество кода резко улучшилось. Людей сначала нужно было убедить, но вскоре положительный эффект заметили и сами. Так что мой опыт говорит, что вы ошибаетесь. И PhoenixRedeemer, ты полный идиот ... как и все остальные.

@Brazzy: Почему ваши разработчики не писали код лучше? Заметьте, мое мнение говорит, что вам «не нужно» писать тесты заранее. Я не говорю, что вам не следует этого делать, просто вам следует подумать, почему вы так пишете.

@brazzy: Эй, полное правило дебилов! :) Я видел код, который улучшают модульные тесты, потому что они ему нужны. Я видел код, для которого не требовалось много модульных тестов, потому что у него было мало недопустимых состояний. Мой код имеет тенденцию нуждаться в случайно сгенерированных тестах из-за проблемного пространства.

Модульные тесты также предназначены для управления изменениями. Тесты нужны не для кода, который вы пишете прямо сейчас, а для кода после следующей итерации изменений, которая потребуется. Как можно перефакторить код, если у вас нет возможности доказать, что то, что он делал до изменения, остается тем, что он делал после?

@Greg: Конечно, можно сказать, как можно провести рефакторинг, если вы не можете доказать, что не сломали что-то, но потом я пишу тесты, предназначенные для отображения изменений после рефакторинга. Мое мнение о тестах в основном ограничивается их предварительным использованием. Тесты очень полезны при рефакторинге.

Все пишут модульный тест, который проверяет, что open () терпит неудачу, если файл не выходит. Никто не пишет модульный тест того, что происходит, если имя пользователя состоит из 100 символов на планшетном ПК с правым-левым языком и турецкой клавиатурой.

Я думаю, что здесь упускается из виду принцип разработки, основанной на тестировании, что вредит аргументу. Речь идет не о тестировании крайних случаев, а о разработке дизайна.

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

Хотя я согласен с тем, что «модульные тесты выявляют только те проблемы, о которых я думал», часто бывает, что я положительный - код, который я только что написал, удовлетворяет определенному условию, но тест обнаруживает то, что я полностью упустил. Более того, процесс написания тестов в первую очередь заставляет вас подумать обо всех крайних случаях таким образом, что вам, возможно, не потребуется в такой степени.

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

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

Да, это метод выборки. Разница в том, что вы торгуете точностью отсчета времени ради точности понимания. Опасения по поводу замедления работы приложения путают средства с целями. Вы пытаетесь найти циклы, потраченные по небрежным причинам. Это не требует быстрого бега.

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

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

«Лучший» способ анализа требований зависит как от того, кто их дает, так и от того, кто их получает. Поэтому обсуждение «наилучшего» способа сделать это не очень поддается количественной оценке.

@Kendall: Я никогда не видел "какой-либо" работы по анализу требований, предложению и оценке альтернативных решений, не говоря уже о "лучших". Если бы мы были врачами, мы бы знали все о лечении, но диагноз был бы «очевиден».

Ой, это самая смешная вещь, которую я видел на SO за долгое время.

Я понимаю, как системы * nix записывают время, и как представлены истина и ложь. Но может ли кто-нибудь объяснить мне эту шутку, я не понимаю? Спасибо.

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

Есть два типа оптимизации: по архитектуре и по коду. Перед написанием кода явно необходима архитектурная оптимизация. Однако термин «преждевременная оптимизация» действительно применяется к усилиям по написанию кода оптимальным, а не простым способом. Это зло.

Меня часто вызывают, чтобы исправить большие беспорядки, которые были спроектированы якобы с целью «производительности».

@Mike: Прежде чем приложение будет разработано, необходимо некоторое понимание объемов и требований к ответам. Такие вещи нужно учитывать в изначальной архитектуре. Конечно, конкретный выбор производительности должен быть обоснован.

@Mike, как я уже сказал, все дело в контексте. Я работаю в геопространственной области, где сложность многих задач по умолчанию составляет O (n ^ 3). В этой области оптимизация является обязательной, и это должно происходить во время разработки. Анализ неэффективного кода с помощью профилировщика редко бывает полезным.

Спорные, и одновременно аксиома. Хороший.

«никогда не тестировался» Вы проводите предварительное тестирование с включенными утверждениями и принимаете сработавшее утверждение как прохождение теста? Странная идея. Если вы это сделаете, то я согласен с вами, но я не понимаю, почему вы это делаете.

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

Если во время тестирования ваши утверждения ни разу не дали сбоев, а во время производственного кода оно действительно завершилось ошибкой, значит, с тестированием возникла проблема, но, тем не менее, ошибка должна быть записана в журнал, и приложения должны завершиться. Утверждения или код, который гарантирует то же самое, должны быть в производстве. Я согласен.

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

++ Я пошел по этому пути в духе «надежда на лучшее - план на худшее». Мы тестируем изо всех сил, но никогда не предполагаем, что нашли возможную проблему каждый. Утверждение (или создание исключения) - это способ защиты от дальнейшего ущерба в случае возникновения проблемы (не дай бог).

По-разному. Нельзя так писать программы, управляющие кардиостимуляторами или атомными электростанциями.

Я не согласен, сколько классов StringUtils у вас есть в вашем проекте? Однажды я нашел проект, в котором их было 5. Большую часть этого материала можно заменить библиотекой третьей части.

Рамки, да. Бесполезные накладные расходы, много раз. Сторонних компонентов, нет! Части задачи уже выполнены, протестированы и отлажены тысячами других людей!

@skiphoppy - ничего не могу поделать. Я действительно парень в душе твой собственный тип. Я полностью признаю, что могу быть измучен тем, что места, где я работал в прошлом, пытались купить самые дешевые вещи из возможных. В конце концов, это нас укусило.

Джоэл в защиту не изобретенного здесь синдрома: joelonsoftware.com/articles/fog0000000007.html

Я выпустил кое-что позапрошлой неделей, что тестировал только в режиме отладки. К сожалению, хотя при отладке он работал нормально, без жалоб, он не прошел в режиме выпуска.

Единственное, чем я отличаюсь между сборками Debug / Release, - это уровень ведения журнала по умолчанию. Все остальное всегда возвращается, чтобы укусить вас.

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

Опять же, я не использую их. Если вы что-то утверждаете при отладке, не должно ли это случиться и в выпуске? Используйте исключение, если оно критично, или не используйте assert (или не волнуйтесь, если assert не успевает выпустить).

@Cameron MacFarland - хорошее замечание; код с утверждениями в режиме отладки либо не обрабатывает условие сбоя в режиме выпуска, либо имеет второй путь обработки сбоя, который работает только в режиме выпуска.

Хотелось бы писать в разные приложения. ваша отладочная версия будет хорошо отлажена, а ваша версия выпуска - нет. Трагично!

@ Дэниел Пол, если есть что-то подозрительное, часто лучше остановить обработку, чем иметь поврежденные данные.

Согласовано: Исключения> Утверждения.

Согласитесь: там есть несколько очень неприятных ошибок, которые могут нанести серьезный ущерб вашей репутации!

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

@MarkJ: Это то, что я говорю, вы должны тестировать код, который выходит за дверь, и не иметь разницы между «Release», который не тестируется, и «Debug», который тестируется, но никогда не выпускается.

Утверждения и исключения имеют разные цели. Исключение составляют ошибки пользователя - вещи, которых «не должно происходить». Утверждения предназначены для предварительных условий - вещей, которые «НЕ МОГУТ произойти». Утверждения приводят к аварийной остановке приложения со словами: «У вас большая проблема - исправьте ее сейчас !!!»

@James: Исключения также приводят к сбою приложения. Также что происходит, когда пользователь видит ошибку утверждения? Они должны это исправить?

Вся разработка и тестирование должны выполняться в сборке выпуска, но должна существовать сборка отладки для помощи в отладке. (Привет #ifdef!)

Вам просто нужно переключиться. Наш QA использует отладочные сборки во время разработки, но переходит на выпуск ближе к концу. Существуют определенные уровни проверки работоспособности, которые вы хотели бы выполнять в максимально возможной степени перед отправкой, но не можете позволить себе доставку по причинам производительности.

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

@Cameron MacFarland: Статья вовсе не об этом. Он утверждает, что нет никакого различия между «ООП» и другими видами программирования, кроме риторического.

Почему нет ссылки на ADT, из которого, как я полагаю, возникло ООП?

@Apocalisp: Вы правы, я только просмотрел статью. Теперь, когда я прочитал это как следует, он сравнил различение стилей кода с различением расы, используя аргумент капиталистических либертарианцев, которые верят в то, что ведет к рабству и убийству бедных людей.

См я сказал вам, что это было спорным. Достаточно, чтобы в одном предложении нарисовать ad hominem с non-sequitur и соломенного человечка. Я впечатлен.

@Cameron, на самом деле именно либералы убивают бедных людей, говоря им, что им не нужно нести ответственность за свою жизнь, им просто нужно делать то, что им говорят «высшие» либералы. Либерализм - это эмоциональное и интеллектуальное эго.

@Apocalisp: Вы легко впечатляете. «Действительные концепции достигаются путем индукции» полностью игнорирует кантовскую идею априорной концепции, которую можно было бы рассматривать как ООП и смурфов. Ограничение понятий фактами реальности само по себе является соломенным аргументом.

«Это бесполезное различие, точно так же, как« раса »- бесполезное различие». - А по национальности, вероисповеданию, полу, роду занятий. Все это бесполезные различия, если следовать логике статьи Айн Рэнд.

@Cameron: Вы попали в точку. Я сознательно и полностью бросаю вызов Канту, потому что его идеи бессмысленны. Думать - значит думать о чем-то.

«Java объектно-дезориентирована» - я

Хороший ответ ... «Нет такого понятия, как ООП» ... И это легко доказать. Достаточно взглянуть на сборку, сгенерированную любым компилятором C++. Я не вижу там ООП ... :)

Должен быть объектно-ориентированный язык. Действия - это не объекты. Меня злит, когда я пишу пустоту для изменения объекта. ARRRGH ............................

@epatel: возможно, потому, что идея о том, что ООП возникла из ADT, неверна. См. Разделы «ООП против ADT» (cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf) и «Повторное рассмотрение абстракции данных» (cs.utexas.edu/~wcook/Drafts/2009/essay.pdf) Уильяма Р. Кука.

Как вы относитесь к тому, должно ли значение тип переменной быть явным или нет? (Думая о "var" в C#.)

Хороший. Если вам нужно работать с устаревшим кодом Fortran, вы не поверите, что эта проблема вызывает головную боль.

Я действительно хотел написать то же самое мнение. ИМХО, это главный недостаток как Python, так и Ruby, без всяких на то причин. По крайней мере, Perl предлагает use strict.

Явное объявление - это хорошо, чтобы избежать опечаток. Присвоение типов переменным часто является преждевременной оптимизацией.

Ага. ОДИН поиск ошибок, когда l (между k и m) становится 1 (между 0 и 2), впустую тратит время жизни на объявление переменных.

Все остальное - ненастоящий язык. Теперь это спорно.

Я помню, как изучал Visual Basic 6 в старшей школе. Если OPTION EXPLICIT не будет первой строкой в ​​каждом исходном файле, мы потерпим неудачу.

Твоя биография устрашающая - все вымыто в 20! Вот моя собственная стяжка против MVC. stackoverflow.com/questions/371898/…

Я всегда копировал код локально. Затем я бы сделал слияние с Windiff и emacs-macro, а затем заблокировал бы его только на время, достаточное для того, чтобы зафиксировать изменения. Я ненавидел, когда люди блокировали файл, а потом уезжали в отпуск.

Раньше я думал, что без файловых блокировок в SCM невозможно работать в команде. Но, поработав с Subversion в четырех компаниях (и самостоятельно развернув его в двух из них, я обнаружил, что слияние (автоматическое, если возможно, ручное, если нет), намного лучше в 99% случаев.

Не спорно. Никто не использовал SourceSafe по собственному желанию.

@MusiGenesis: Да, это так. Они существуют.

Моя компания все еще использует SourceSafe. Основные причины: а) общая инерция и б) разработчики боятся работать без эксклюзивных блокировок.

Лично я считаю, что умение объединять файлы кода должно быть навыком, необходимым всем программистам, как и всем программистам, которые должны знать, как компилировать свой код. Это часть того, что мы делаем как побочный продукт использования системы контроля версий.

@MusiGenesis: Я руководил отходом от SourceSafe в двух разных компаниях за последние 5 лет, и в обоих случаях причиной использования SourceSafe было незнание альтернатив.

SourceSafe даже не работает ни на чем на основе IIS7. Так что скоро это станет в значительной степени излишним.

Просто чтобы быть педантичным ... в то время как эксклюзивные блокировки были по умолчанию до недавнего времени, SourceSafe фактически поддерживает режим редактирования-слияния-фиксации с 1998 года.

@Ed - SourceSafe может работать с IIS7, если у вас установлен WebDAV. Плагин WebDAV не поставлялся с Vista, но доступен как бесплатный плагин, а также поставляется с Win2008. Тем не менее, я, как и все остальные, надеюсь, что он наконец выйдет из строя. На рынке есть гораздо лучшие инструменты (бесплатные и другие).

@ Ричард: Да, но никто из тех, кто использует Source Unsafe, не использует его в режиме слияния, потому что боится и т. д.

МКС детка! Наконец-то просто убиваю это сейчас.

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

@MusiGenesis мы делаем на моем рабочем месте, но мне это не особенно нравится. Мне гораздо больше нравится SVN.

Ваше последнее чувство +1. Остальное, ИМХО, неверно, потому что отсчитываемые от нуля индексы очень полезны, потому что make заставляет индексы контейнера размера N быть набором целых чисел в полуоткрытом интервале [0, N [. Это имеет приятные математические / алгоритмические / практические последствия.

Лично я не видел такой пользы от полуоткрытых интервалов, как вы. Если бы вы могли оставить указатель в комментарии, мне было бы интересно.

+1, потому что: а) я не согласен с абзацем 1, поэтому я думаю, он отвечает на вопрос, и, 2) мне нравятся другие абзацы :)

Должны ли индексы массива начинаться с 0 или 1? Мой компромисс 0,5 был отклонен, как мне показалось, без должного рассмотрения. - Стэн Келли-Бутл

Ага, +1 за последнее предложение.

+1 за изучение математики, -1 за то, что Lisp - лучший (чтобы сделать хороший язык нужно больше, чем круглые скобки)

в массивах smalltalk начинаются с 1

Это просто условность, и это не имеет значения.

Не могу согласиться и с массивами на основе 1. Сделал бы добавление / удаление элементов намного более сложным (потому что вам пришлось бы перебазировать ваши индексы во время операции). Я бы предпочел, чтобы -1 был последним элементом в массиве :)

В чем разница между массивами на основе 0 и 1 для добавления / удаления? Обозначение Python, использующее отрицательные числа для измерения с конца, довольно изящно.

Большинство функциональных языков похожи на это; например, F# явно требует, чтобы вы объявили что-либо как «изменяемое», если вы хотите иметь возможность это изменить.

В этом смысле функциональные языки просто превосходят. Из нефункциональных языков Nemerle, кажется, единственный, предлагающий эту функцию.

Мне нравится бит в SICP, в котором авторы отвергают «циклические конструкции, такие как do, repeat, until, for и while» как языковой дефект.

Не согласен, но заставил задуматься. Интересно.

Мне лично это нравится. «Все неизменяемо» значительно упрощает написание многопоточного кода: блокировки больше не нужны, так как вам никогда не придется беспокоиться о том, что другой поток изменит ваш объект у вас под ногами, поэтому целый класс ошибок, связанных с условиями гонки и взаимоблокировкой, перестает быть существовать.

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

@AnthonyWJones: какие затраты у неизменяемого по умолчанию?

Это заставляет меня задаться вопросом, на что был бы похож мой код и как мне нужно было бы изменить свое понимание парадигм программирования. Могу ли я иметь дело с неизменяемыми переменными? Я не могу понять, насколько сильно это отразится на C#, но я не могу представить себе что-нибудь хорошее из этого.

Что мне не нравится в неизменяемости, так это объем необходимого копирования.

Я подумал, что это было слишком много, когда я прочитал об этом в «Эффективная Java: пользу неизменности». Тогда при применении это имеет смысл. Приложения НАМНОГО проще создавать и поддерживать, используя неизменяемость. Единственное, что требуется, это шаблон макроса для «кодирования» методов копирования, как указывал TraumaPony.

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

@TraumaPony: Хорошая особенность неизменяемости заключается в том, что (почти?) Во всех случаях копирование может быть заменено простым псевдонимом. Однако этот делает требует некоторых изменений в структурах данных.

Другой случай, который не может быть неизменным: любые итерационные вычисления или вычисления в цикле. В более общем смысле, данные, над которыми вы работаете. Насколько хорошо будет продаваться Microsoft Immutable Word?

@Princess: неизменяемый по умолчанию имеет стоимость понимания. Гораздо сложнее думать (а не рассуждать, думать о) неизменяемых по умолчанию объектах / переменных / что-то-есть-у вас.

Я согласен с тем, что переменные должны быть доступны только для чтения. Это позволяет компилятору оптимизировать и позволяет разработчику знать, что значение никогда не изменится после определенного момента.

@Loren: о вашем «другом случае»: чем он отличается от специального аккумулятора? На самом деле это просто так, и это хорошо поддерживается многими фреймворками, такими как LINQ. Обратите внимание, что при любом взаимодействии с пользователем неизменяемость редко выигрывает, поэтому использование Immutable Word, вероятно, не лучшая идея.

@Jeff: Я думаю, что это по меньшей мере спорно. Программирование в целом требует понимания, как и любой стиль программирования. Но я сомневаюсь, что неизменяемость по умолчанию влечет за собой дополнительные затраты на понимание любой, тем более что это намного ближе к математическому использованию переменных в уравнениях.

@Loren Pectel, я думаю, что базы данных тоже должны быть неизменными.

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

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

Я хочу неизменное яблоко. Когда я откусываю яблоко, я беру ваше яблоко с оторванным кусочком и могу отдать свое яблоко следующему человеку, который захочет целое яблоко. Все так просто!

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

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

Было бы немного сложно анимировать что-либо, если бы переменные, описывающие объект для анимации, были неизменными.

@ Камил: нет, совсем нет. Фактически, объекты Point в .NET находятся неизменяемы и прекрасно анимируются. Вам просто нужно создать новый объект для каждой позиции анимации - что звуки неэффективно, но на самом деле не обязательно.

Интересно, что в Java даже переменные цикла могут быть final: for (final item: list) {...} Мне потребовалось время, чтобы это обнаружить.

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

Определить долго. Я видел оператор переключения на 13000 строк (правда, это был C++, но все же ...)

Что ж, (в C#), если оператор switch сгенерирован (в отличие от ручного редактирования), я не вижу ничего плохого в операторе переключения строк 13K, если честно. В любом случае он превратится в хеш-таблицу.

Конечно, если в нем 13 КБ строк, потому что в каждом предложении case много кода, это совершенно другое. Тогда его следует отремонтировать.

Вообще-то, да. Было ли это так или если, и замена всех if на switch была бы слишком многословной даже для python?

Я хочу, чтобы компилятор сгенерировал для меня хороший ассемблерный код, а switch - это то, как я говорю ему, что мне нужна таблица переходов. Тем не менее, легко думать, что вы делаете что-то из соображений «производительности», хотя на самом деле вы никогда не заметите разницы.

@Mike: если у вас есть оператор switch с тысячами случаев, вы будут заметите разницу в производительности между таблицей переходов и серией операторов if-else.

Как у вас могут быть тысячи случаев? Не представляю, есть ли у вас пример?

@tuinstoel: Это несложно представить, если вы попробуете. До появления единиц с плавающей запятой было обычной практикой хранить тригонометрические функции в таблицах поиска. Я думаю, что сохранение результатов сложных математических функций в готовых таблицах поиска по-прежнему имеет смысл.

Отличный ответ. Полностью согласен.

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

Регистратор, безусловно, не идеальный кандидат для синглтона. Вы можете захотеть иметь два регистратора. Я уже был в такой ситуации раньше. Это может быть хорошим кандидатом на роль Глобальный, но определенно не для принудительного использования «только в одном экземпляре». Очень немногие вещи требуют этого ограничения.

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

Я очень рекомендую вам прочитать misko.hevery.com/2008/08/25/root-cause-of-singletons.

Я хотел бы добавить, что в C++ шаблон singleton чрезвычайно важен из-за фиаско статической инициализации.

Ведение журнала - единственное распространенное использование шаблона singleton, все остальные использования в основном плохие.

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

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

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

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

+1 Если бы я выступал перед собранием первокурсников CS, мой первый совет был бы: «Знай, данные_Структуры», Аминь, брат.

Брукс в «Мифическом человеко-месяце» заметил, что он был бы сбит с толку, если бы вы спрятали свои таблицы и показали ему свои блок-схемы, но если бы вы показали ему свои таблицы, ему не нужно было бы видеть ваши блок-схемы. Это должно дать вам представление о том, сколько лет этой идее.

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

Совершенно верно. Способности очень мало связаны с опытом, который часто просто закрепляет вредные привычки.

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

@ Джульетта, полная чушь. Когда я был разработчиком начального уровня, я занимался обслуживанием и исправлением ошибок и непосредственно понял, почему согласованность и разделение проблем так важны в программном обеспечении. Сохранение кода с «проблемами» - это лучший способ улучшить ваш собственный дизайн.

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

Я рад, что вы это квалифицировали. Слава богу, что Python 2.6 добавил именованные кортежи.

Эй, это круто. Я не знал, что существует такая вещь, как именованный кортеж. Я думаю, что для tuple-perfect-storm вам следует разработать библиотеку GUI на python, которая ожидает 2-кортежи в порядке x, y и y, x в разных местах. :-)

в bash есть перерыв; и продолжить n; вместо. imho единственная причина использовать goto - это когда у вас их нет (или нет пометки break / continue)

В сборке все реализовано как goto (jump / branch). В большинстве языков есть if и некоторая форма цикла, но многим не хватает try / catch или break / continue, все из которых могут быть реализованы с помощью goto. По общему признанию, его можно использовать очень плохо, поэтому будьте осторожны :)

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

@ Джошуа, ты имеешь в виду интерпретируемые языки? Такой язык, как Basic, когда-то был интерпретируемым языком, и у него определенно был оператор goto. Сколько тебе лет?

@ Джошуа, я бы сказал, что это было проще. Я написал простой интерпретируемый язык (под «простым» я имею в виду «вообще ничего не делал»: D), в котором был goto. Но никаких условий.

и есть операторы cmp (операторы if) в сборке - иначе вы никогда не узнаете, когда использовать jmp

Тогда вы, очевидно, никогда не использовали DataSet: P

Я не согласен. IMO DataSet является излишним для подавляющего большинства операций. И прежде чем его спросят, да, я использовал его.

По тем же соображениям LINQ to SQL, Entity Framework, NHibernate и т. д. Также являются излишними для «подавляющего большинства» операций. Кстати, вы имели в виду «подавляющее большинство» всех операций или «подавляющее большинство» мест, где я бы использовал DDD?

Я согласен: вы не можете создавать версии хранимых процедур, а наличие 200+ хранимых процедур в большом проекте становится кошмаром для обслуживания. Встроенный SQL подходит для небольших проектов, но я бы предпочел использовать ORM для написания запросов за меня.

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

Я согласен с управлением версиями хранимых процедур. Если вы пишете SP, вам нужно взять на себя ответственность за их версию в системе управления версиями.

Нет в базе данных ваш? Говорит администратор базы данных 1970-х годов

Мы можем версия SP. В процессе сборки они перемещаются из системы управления версиями в базу данных.

В DB2 / 400 хранимые процедуры - это интерфейс к машинному коду в системе ... Другими словами, их трудно перенести на вызывающую систему.

100% верно. Если бы только разработчики Python наконец признали это и соответствующим образом изменили свой в остальном исключительный язык. Спасибо, что разместили это.

Но уже существует один статически типизированный Python-подобный язык. Это называется C# ;-)

C# похож на Python? Может ты имел ввиду Бу;)

Если кто-то говорит, что динамическая типизация более лаконична, просто укажите на Haskell =). Я согласен со всем, кроме вашего третьего пункта. Динамический код часто принимает параметры, которые могут быть одного из двух типов. Например, функции Prototype принимают либо HTMLElements, либо строки, которые вы можете использовать $ () для поиска, чтобы получить HTMLElements. Хорошая система статической типизации позволит вам это сделать =).

№2 верен только в том случае, если вы следуете №1, что, на мой взгляд, не нужно. Если понятно, что делает код, значит, он правильный. У меня есть код, который я часто использую, который считывает данные из файла с разделителями табуляцией и анализирует их в массив с плавающей запятой. Зачем мне нужны разные переменные для каждого шага процесса? Данные (так называется переменная) по-прежнему являются данными каждого шага.

Обычно, когда все выровнено по столбцам, это создает бремя обслуживания для разработчика. То есть выравнивание типа данных и идентификатора в объявлении метода ... Line1 (int id,) line 2 (char id,) ... убедитесь, что тип данных, имя переменной и даже запятые все в столбце являются MESS

обычно требуется всего пара дополнительных нажатий клавиш, если это так. Я не вдавался в подробности, но обычно я разбиваю его только на два столбца для целей выравнивания (обычно тип - id). У меня есть другие правила, чтобы облегчить бремя, когда дело касается скобок. Самое большое препятствие, которое у меня есть [продолжение ...]

[... продолжение] борется с редакторами автоформатирования. На самом деле, если отключить легко, я обычно сдаюсь в таких обстоятельствах и «плыву по течению». Но я все же предпочитаю особенно многословные языки, такие как C++.

Интересно. Хотелось бы увидеть несколько примеров. У вас есть блог?

Ну, у меня есть: levelofindirection.com (да, он пересылает в блог - каламбур предназначен было), а также organic-programming.blogspot.com. Однако вы заметите, что ни один из них не обновлялся довольно долгое время - в значительной степени из-за vconqr.com ;-) [продолжение ...]

[... продолжение] - и я не говорю о макете. Я снова буду считать, что меня подтолкнули!

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

@Kendall: Звучит неплохо. Однако это сложно, потому что вы должны иметь возможность указать точное форматирование каждого возможного бита кода, включая код, который недопустим на языке!

Это довольно стандартное мнение. Или, по крайней мере, так должно быть. Если это спорно, то есть проблема.

Я видел утечку 50 МБ, потому что какой-то программист библиотеки подключил событие и не позаботился о его отключении.

8 ГБ ОЗУ - ничто по сравнению с повторяющейся утечкой на сервере при высокой нагрузке.

Я думаю, это относится к идиоме RIIA. В таком случае я должен придерживаться предложения. RIIA - это решение для всех ресурсов, GC - частичное решение только для ресурсов памяти.

+1 к этому. До GC программисты позаботились об утечках перед развертыванием. В наши дни приложения развертываются, а затем, когда 100 пользователей используют приложение, мы обнаруживаем, что у нас закончились соединения с базой данных.

Любой, кто ожидает, что сборка мусора будет обрабатывать все управление ресурсами, отчаянно неправильно понял сборку мусора. GC предназначен только для управления объем памяти

Я бы поставил +1, если бы вы сказали: «Сборщик мусора, потому что он доступен не для всех ресурсов; только память. Таким образом, вы можете пропускать соединения с БД». GC решил 100 проблем и представил 20 новых, так что это все еще преимущество.

Какие «100 вопросов»? Решил только один - управление памятью, и ИМХО даже то слабо.

+1 за мерзость. Все, что труднее читать, чем писать, должно быть неправильным.

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

HTML-макет намного проще, чем сборка виджетов на C++

Я думаю, у вас есть некоторые неправильные представления о DI. Вам следует посмотреть выступления Миско Хевери «Чистый кодекс».

Я согласен насчет глобалов. Проблема не в самой концепции глобального, а в том, какие вещи сделать глобальными. При правильном использовании глобальные переменные очень эффективны.

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

Мы все время используем глобалы в java, каждый раз, когда мы используем окончательную общедоступную статику вместо константы (C, C++, C#). Я думаю, что если он должен быть глобальным, то он должен быть статическим. Я могу (в основном) согласиться с этим.

Мне это нравится! Теперь я хочу, чтобы все объекты IDisposable во фреймворке делали это.

Кстати, MemoryStream одноразовый, но утечка безопасна. Подумай об этом.

Джошуа: Тот факт, что MemoryStream является одноразовым, является деталью реализации, и, как мы все знаем, не рекомендуется полагаться на детали реализации, если они вам не нужны. Его можно очень легко изменить, чтобы в будущем он использовал указатель неуправляемой памяти для буфера. Подумай об этом. знак равно

Я бы предпочел, чтобы все типы, реализующие IDisposable, были принудительно выделены стеком или какой-либо подобной концепцией.

Я нашел это: Single Entry Single Exit !!

Я предполагаю, что другими словами это «функция должна иметь только одно выражение возврата» - никогда не соглашался с этим.

Более того, исключение - это просто еще одна точка выхода. Когда функции короткие и безопасные (-> наконец, RAII), нет необходимости следовать SESE.

Согласовано. Я съеживаюсь от более чем 100 методов loc, которые я видел, которые несут возвращаемое значение от первой строки до самого низа, просто чтобы придерживаться SESE. Когда вы найдете ответ, есть что сказать для выхода.

Полностью согласен с этим, я собирался добавить его в этот пост, вы меня опередили;)

Подождите, люди на самом деле это делают? Почему вы не можете просто искать "возврат"?

SESE - это закон в неуправляемом коде, но в управляемом коде это не так, какой-то пост где-то здесь в SO объясняет это лучше

Я бы хотел увидеть этот пост, но, по общему признанию, мое мнение исходит из домена строго управляемого кода.

Это может быть полезно, если ваш отладчик имеет не более двух точек останова. Очень часто встречается во встроенных аппаратных средах.

Думаю, SESE - отличный пример решения в поисках проблемы

SESE восходит к 1960-м годам и занимается структурным программированием. тогда это имело большой смысл. одиночный вход сегодня в значительной степени гарантирован, цепляние за одиночный выход просто выдает низкий iq.

Это имеет смысл только в том случае, если это SESRP: Single Entry, Single Return Point. Это было важно для таких языков, как BASIC, где можно было НАХОДИТЬСЯ здесь, там и где угодно. Лучшей практикой было всегда возвращаться туда, откуда вы пришли, используя GOSUB вместо GOTO. С современными языками программирования это не такая уж большая проблема ... похоже, что разумное «возвращение туда, откуда вы пришли» превратилось в ужасный «выход только из одной точки метода».

Я запускал PMD в проекте и пришел сюда, чтобы опубликовать это после того, как появился раздражающий набор точек нарушения «OnlyOneReturn».

Интересная ссылка для подтверждения вашей точки зрения: sadekdrobi.com/2008/12/22/…

Неманья: Замечательная находка, жаль, что я не могу проголосовать за комментарии :)

Я бы предпочел иметь «ссылочные типы, не допускающие значения NULL» (с проверкой компилятора), чем полностью удалить NULL.

Я должен согласиться с Джоном; «null» часто является допустимым состоянием и указывает на что-то совершенно отличное от нуля или пустого. Устранение этого было бы ошибкой, ИМО; но для тех случаев, когда это не подходит, было бы неплохо использовать тип объекта, не допускающий значения NULL.

Исправление: ссылка, не допускающая значения NULL.

Я не согласен, но затем я использую Objective-C, где nil - довольно удобная концепция.

Это похоже на запрет нуля для предотвращения ошибок деления на ноль. Нулевые значения случаются в реальных ситуациях, и их запрет вынудит всех использовать свои собственные специальные реализации.

Мне очень нравится подход Scala к этому: здесь нет нуля, и если вам нужен тот же эффект, вы должны заключить его в объект Option [T] (Some [T] или None), который заставит вас заметить и проверить его. Больше никаких случайных нулей.

Я не обязательно согласен с тем, что их следует удалить, но я думаю, что шаблон Null Object должен быть предпочтительнее проверки на null каждые четыре строки в вашем коде.

Принцесса, если вам нравится ссылка Неманья, вы можете отредактировать свой ответ и включить его

Согласитесь с Джоном. Должна быть возможность заставить язык предписывать, что данной переменной никогда не может быть присвоено значение null.

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

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

Эй, тот, кто понимает истинное предназначение хранимых процедур!

Хм. Выньте данные из системы и что у вас есть? Система, которая ничего не вычисляет. Поместите неверные данные в вашу систему и что произойдет? Крушение. Аналогия: запеките свои кирпичи (создайте надежные типы данных) и смешайте свой цемент (обеспечьте соблюдение ограничений), затем спроектируйте / создайте свою систему с идеальными блоками.

Если ваш язык заявлен как объектно-ориентированный, но имеет встроенные типы, которые синтаксически и семантически отличаются от объектов, и вы думаете, что это нормально, вы можете быть программистом на Java или C++.

@ Барри! А как насчет нас, программистов на Objective-C! Это может быть и мы!

C++ - это мультипарадигма, и поэтому он может решить использовать любые типы, которые захочет: P

Ориентация на объект - это средство достижения цели, а не цель сама по себе.

IMHO Регионы хороши для одного ... визуализации гниения кода.

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

Больше всего в VS мне не хватает регионов (я использую Eclipse). поэтому вместо использования регионов мы создаем Method, у которого есть вызовы методов, у которых есть вызовы методов ............. только для того, чтобы мы могли читать проклятые вещи. Регионы ХОРОШИЕ! +1

Причина, по которой OODB не стала популярной для веб-приложений, заключается в том, что веб-приложения являются единственной областью, в которой масштабируемость и скорость имеют наибольшее значение, а OODB не работает при высокой нагрузке. Вот почему MySQL взлетел вместо чего-то более надежного, как Postgres, из-за чистой скорости чтения и масштабируемости.

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

Только глубокое незнание может помешать кому-либо реализовать такие вещи даже в SQL, который является плохо разработанным языком и не соответствует реляционной модели данных.

Не могу с этим больше согласиться! Это показывает, насколько серьезно относится к моде наша отрасль. Когда я изучил, из-за чего была возня с AJAX, я обнаружил, что занимаюсь этим уже 2 года. Но для того, чтобы все произошло, требуется модное словечко в маркетинговом стиле.

Взгляд на историю AJAX: theregister.co.uk/2008/11/27/microsoft_ignored_ajax

Я помню, когда это называлось DHTML: P

напоминает мне одного моего старого менеджера, который отвлекся от работы. Он провел месяцы, абстрагируя приложение, чтобы сделать его «идеальным», но в конце концов ничего не сделал.

Я умею печатать (был армейским телетайпом), но настаиваю на том, что это не имеет никакого значения.

Неманья -> "никакой разницы" ?! Я только что получил 70 слов в минуту на онлайн-тесте. Я мог видеть, как кто-то может соскрести со скоростью 20-30 слов в минуту, но если они используют два пальца, подключая их со скоростью 5 слов в минуту (да, я работал с такими людьми), это их сдерживает.

Никакой разницы. Я даже не знаю, какой у меня текущий уровень wpm, потому что полностью потерял к нему интерес. Конечно, когда вы пишете документацию или отправляете электронные письма, полезно печатать быстро, но для кодирования? Неа. Обдумывание требует времени, набор текста не важен.

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

@ Неманья Трифунович - я слышу, что вы говорите, но, с уважением, я думаю, что вы совершенно неправы. Умение печатать имеет огромное значение.

@keysersoze: Я никогда не работал над проектами, когда скорость набора имела значение. Даже когда я пишу код с нуля и не борюсь с какими-то сумасшедшими фреймворками, хороший редактор делает навыки набора текста почти бесполезными. В vim я обычно просто набираю пару букв, прежде чем нажимать Ctrl + P.

@duncan: Никаких обид, но ты чертовски неправ - без разницы :)

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

Я умею печатать. После двадцати лет набора текста мой указательный и средний пальцы знают, где находятся все клавиши, поэтому мне не нужно так часто смотреть на клавиатуру. Но давно у меня был этот аргумент в другом контексте: мой коллега утверждал, что случай с верблюдами [продолжение ...]

[... продолжение] лучше, чем подчеркивание, потому что его легче набирать. Мой аргумент заключается в том, что вы не должны писать код со скоростью набора текста.

Я не против иногда смотреть на клавиатуру, чтобы не напрягать глаза. Вы ДОЛЖНЫ время от времени менять свой фокус. Если вы хороший машинист, скорее всего, у вас есть очки или контактные линзы.

Хотя я не могу коснуться текста и подтвердить это, я подозреваю, что это помогает. Я встречал много ситуаций, когда мне мешала медленная скорость набора текста. К сожалению, обучение невероятно скучно. Да, я знаю, что есть множество забавных игр, которые могут вам помочь, но мне все равно это скучно. Хотя все еще пытаюсь ...

+1. Я неоднократно видел, как люди совершают кучу ошибок, потому что они смотрят на клавиатуру, а не на код на экране. Чаще всего встречаются проблемы с синтаксисом и форматированием кода, но также и настоящие ошибки, которые не обнаруживаются компилятором.

Вы, должно быть, используете какой-то смехотворно многословный язык вроде Java. При программировании узким местом является мышление, а не набор текста.

Я согласен здесь. Хотя думать важно, главное - смотреть на экран.

Я согласен с тем, что мысль является ограничивающим фактором программирования, но кто программирует так часто, что разрабатывает программное обеспечение по мере его ввода? Пока я кодирую / печатаю, я в значительной степени уже разработал программное обеспечение ... в результате мое мышление легко совпадает с моей скоростью набора 80wpm +.

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

Странно то, что охотники и пекеры находятся буквально на волосок от полноценного набора текста десятью пальцами. После многих лет использования клавиатуры вы точно знаете, где находятся клавиши - вы просто не знаете, где находятся ваши руки, не глядя. И это лишь небольшая часть техники. Кстати: использование контурной клавиатуры Kinesis очень помогает. И используя английскую клавиатуру вместо локализованной.

@hstoerr: Когда я впервые пошел на курсы набора текста в шестом классе, я обманул и посмотрел на свои пальцы. Я был самым быстрым в классе, звездным учеником. Только я толком не умел печатать. К счастью, в седьмом классе я снова начал печатать, и на этот раз все сделал правильно. Это единственное полезное, чему я научился в средней школе. (Ну, это и «Всегда носите свои книги в рюкзаке, чтобы они не вылетели из ваших рук и не рассыпались по коридору».)

Я смотрю на это так: если вы не умеете печатать, какой у вас действительно есть опыт программирования? Так что да, я думаю, что хороший программист - это тот, кто умеет печатать.

Я не согласен. Я никогда не брал уроки набора текста, но, проведя большую часть своей жизни за компьютером, я помнил, где находятся все клавиши, чтобы я мог быстро печатать, не глядя на клавиатуру. Может быть, мои руки не находятся в оптимальном положении, как вы узнали бы на уроке набора текста, или я не использую клавиатуру DVORAK, но я печатаю нормально. И я точно не хочу печатать быстрее, чем могу думать.

Обычно я печатаю 4 пальцами или около того, и я проверил свою скорость набора - 90 слов в минуту.

С каких это пор wpm имеет значение при программировании? Программирование требует мысли, а не просто бездумного набора текста.

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

-1 за полную ошибку: вам вообще не нужно печатать, чтобы быть программистом. Затем +2 к тому, что это на самом деле означает: вы должны знать, как печатать, чтобы стать программистом хорошо. Когда я беру интервью у людей, я сразу сдаю, если они не умеют печатать прикосновением.

Программирование имеет много общего с уборкой в ​​комнате. Применяются те же принципы организации.

Может быть ... вместо того, чтобы обращаться со своими счетами как с клочками бумаги, вы распределяете их по папкам и инкапсулируете в картотечный шкаф или коробку. Если вы найдете способ провести модульное тестирование прачечной, дайте мне знать!

Как правило, иметь план перед созданием веб-сайта / настольного приложения / дома / атомной подводной лодки - всегда хорошая идея! Составление карт с помощью набросков на блокноте, каркаса, видео, рабочего процесса, интеллект-карты и т. д. И обучающие пользователи ... Я вижу, что этого не хватает даже самым блестящим программистам. Принятие пользователями в конечном итоге определяет успех ваших приложений. Если они этого не понимают, независимо от того, что оно делает или насколько хорошо сделано, ваше приложение выйдет из строя.

Отличный момент. Я заново усваиваю этот момент каждый раз, когда пытаюсь научить своих родителей (которым чуть за 70), как использовать что-то на компьютере или в своих мобильных телефонах.

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

Я не согласен, но только в том смысле, что большинство решений по дизайну интерфейса, по-видимому, принимает руководство.

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

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

Это одна из моих любимых книг. Должен быть обязательным к прочтению - особенно для программистов, которые думают, что они веб-дизайнеры ...

Это все равно, что сказать: «Если вы знаете что-нибудь о том, как устроен автомобиль, вам не должно быть позволено проектировать интерьер». Вокруг дизайна пользовательского интерфейса существует целая дисциплина, и если вы делаете что-то только на основе своей ментальной модели какого-то воображаемого пожилого пользователя, то вы делаете это неправильно. Никто не может объяснить ментальную модель каждого. Применение обширных исследований, передовых практик, статистического анализа и пользовательского тестирования - вот способы получить желаемый результат. Программисты тоже могут изучить эту дисциплину.

@Ben: нет, вы не можете объяснить ментальную модель "всяких", но совершенно точно, что ментальная модель разработчиков полностью отличается от всех остальных. Вот почему профессионал в области интерактивного дизайна изобретет человека, который лучше всего представляет типичного пользователя. Если в системе есть пользователи очень разных персон (например, в дополнение к Дорис мы можем изобрести Джеффа, администратора ИТ), тогда хороший дизайн взаимодействия будет использовать Джеффа в качестве целевой аудитории для задач, в которых он, вероятно, будет участвовать.

Дизайн взаимодействия пользователей - вот что принесло MySpace репутацию вызывающих рвоту страниц.

Я работал над проектом, который считаю исключением из этого правила, но это означало постоянно бороться со всеми причинами, по которым я в основном с вами согласен. В 99% случаев это не лучшее решение.

SQL - это просто еще один язык? Трудно рассуждать с таким мышлением.

SPROC исключают атаки SQL-инъекций. В MSSQL они предварительно скомпилированы (а значит, быстрее). @ Кристофер, не могли бы вы дать мне адреса созданных вами веб-сайтов? Я хочу немного заработать: P.

Проверял исключения. Непроверенные исключения - это фантастика, они отлично справляются со стабилизацией вашего приложения.

Я не знаю, как спорно это мнение. То, что вы описываете, похоже, является хорошо известным шаблоном «Решение шипа» c2.com/xp/SpikeSolution.html, и это хороший шаблон.

Я думаю, вы пытаетесь сказать, что Swing - отстой (как в пользовательском интерфейсе JAVA). Бэкенды Java совсем не отстой ... если только это не спорный момент;)

Необязательно быть приверженцем Java, чтобы оценить такое приложение, как JEdit. У Java есть серьезные недостатки, как и у любого другого языка. Таковые из Java легче распознать.

Я фанат C#, но восхищаюсь тем, что некоторые приложения Java выполнены очень хорошо.

Я думаю, вы пытаетесь сказать, что барьер для программирования на Java настолько низок, что есть много отстойных Java-программистов, пишущих полную чушь.

Я согласен с тем, что большинство настольных приложений Java, которые я видел, отстой. Но я бы не сказал того же о серверных приложениях.

Вы собираетесь винить язык программирования в «ужасных пользовательских интерфейсах»? Конечно, это вина дизайнера пользовательского интерфейса. И хотя я уверен, что у Java есть доля плохо написанного программного обеспечения, которое работает медленно и потребляет слишком много памяти, совсем нетрудно писать программы Java, которые работают эффективно и используют память только по мере необходимости. Работая над веб-сканером на основе Java, способным сканировать сотни миллионов URI, я могу это подтвердить.

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

Java - отстой. Познакомьтесь с .NET, Visual Studio, и вы больше никогда не захотите писать код для Java.

Или вы можете сделать всю свою программу одной (действительно длинной) строкой кода. Это всегда весело.

БАКА !! даже в функциональном языке, таком как haskell, в функции может быть несколько строк!

Если комбинировать правило, согласно которому класс должен умещаться на экране, и каждый метод имеет только одну строку, класс может содержать только приблизительно 7 строк кода.

Меня забавляет, что в настоящее время это ответ с самым низким рейтингом; Я думаю, что мне удалось на «спорной» части.

Это действительно спорный, так что я до.

Я полностью согласен, когда люди увидят свет? Я использую Perl, поэтому я не знаю, как написать функцию с более чем одной строкой кода, а также что это за «рефакторинг», о котором вы говорите? : -O

Вы должны быть функциональным программистом ... но одна строка на функцию все еще немного экстремальна;)

Извините, это чушь. -1 от меня

Это не спорное - это бессмысленная.

Это зависит от вашего определения «линии». Для некоторых методов даже одной строки слишком много.

Ни один метод, который я когда-либо писал (насколько я помню), имеет всего одну строчку кода =)

int ScrewYou () {printf ("Это шары ... \ n"); }

Обычно, когда я пишу фиктивный метод ПУСТОТА, просто из-за соглашений о форматировании он занимает как минимум две строки. Непустые функции обычно занимают три строки. Конечно, как сказал Кив, вы можете иметь 10 000 символов в одной строке, поэтому «строки» могут быть не лучшим показателем для подсчета размера программы.

Это спорный, потому что я не думаю, что вы можете использовать этот тип заявления на всех языках.

@atconway: C++ не работает, потому что вы не можете сделать ничего полезного в одном операторе. Perl терпит неудачу, потому что сбивает с толку даже одну строчку. (Для всех: за этим стоит здравомыслие, но я хотел шокировать.)

Тогда у вас должен быть действительно большой экран. Вы также думаете, что у этого класса может быть не более 3 или 4 методов, потому что они не умещаются более четко на 41 строке, которые умещаются на моем экране. Голосование вверх, потому что это действительно спорный.

Рене: Спасибо, что не согласились со мной, не отклонив мой ответ сразу. Я чувствую непредвзятость.

Я тоже должен не согласиться. Я пишу много классов Python, и не многие из них умещаются на моем экране. Конечно, я не считаю экран своего нетбука, потому что это было бы несправедливо по отношению ко мне. = P

Размер экрана сильно различается в зависимости от остроты зрения. Я держу свои экраны с разрешением 1680 × 1250 и использую Consolas 8pt. То, что я вижу на одном экране, скорее всего, на много больше, чем у парня, работающего с разрешением 640 × 480 и использующим Courier New 10pt.

Сделайте так: «Емкость экрана сильно различается в зависимости от остроты зрения и настроек дисплея». :-) Еще не хватило кофе. :-)

@Mike: это правда, емкость экрана варьируется. Чтобы следовать моим рекомендациям, вы должны решить, на какой экран вы хотите поместиться. В команде вы должны принять это решение вместе. Тем не менее, принцип верен: я хочу иметь возможность смотреть на весь класс и понимать его целиком, без прокрутки.

Это может быть довольно сложно реализовать на некоторых языках, которые являются более подробными (требуют дополнительной сантехники), но я восхищаюсь общим мнением.

@ Роб: спасибо, и ты прав. В некоторых языках вы можете извлечь класс и получить некоторую компактность, надеюсь, в пользу вашего кода. В других случаях (C++ я смотрю на вас!) Даже простые классы должны работать очень усердно.

Есть ли у вас какие-то другие правила? Список классов в API должен умещаться на одном экране? Что есть в классе, что вам все равно нужно видеть, конечно, название говорит вам все о том, на что он способен! Зачем смотреть методы по списку.

Некоторые другие правила, которые могут подойти: «Методы должны иметь один оператор» и «блоки должны иметь только один оператор», и «варианты переключения должны быть тривиальными» и «каждый тип« перечисления »должен упоминаться в условном выражении только один раз». :-)

Ой. Может быть достаточно сложно разместить метод на экране, не говоря уже о целом классе (мой основной язык - Java BTW)

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

@SnOrfus: Готов поспорить, что в этих больших классах есть кусочки автономных, универсальных, многоразовых функциональных возможностей, которые сделают COMPLETE SENSE новым классом. Вы не будете сбиты с толку при просмотре ссылки на один, потому что имя и его функциональность будут очевидны.

Я думаю, это приманка. Подразумевается, что класс должен иметь ограничение на количество атрибутов, которые он может иметь, потому что их объявление поглощает пространство для тел методов. Это звучит как языковой тролль, поскольку любой язык, на котором класс не помещается на одном экране, непригоден для использования. Попробуйте закодировать что-нибудь сложное, например, контактные данные человека, которые включают международный адрес, включая номера телефонов, электронную почту, факс и т. д.

Вы говорите о классах в C++, где тело функции объявлено вне класса? тогда, может быть, ты прав ...

@Amarghosh Нет, я не об этом. В C++ это невозможно сделать, потому что язык слишком сложный и громоздкий. Кроме того, я бы хотел, чтобы вы писали на английском.

Нет, если вы программируете для мобильного телефона.

Конечно, я сам много раз забывал набирать «себя», но что бы вы сделали вместо этого? Вы не можете просто подразумевать себя во всех объявлениях методов из-за методов классов и статических методов.

Я часто ошибочно набираю его как slef и получаю ошибки, потому что self не объявлен.

Я думаю, что def в class должен подразумевать self, а другие типы методов могут использовать другое / дополнительное ключевое слово, например defstatic / static def.

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

Пожалуйста, прочтите и пересмотрите свое мнение: effbot.org/pyfaq/… и artima.com/weblogs/viewpost.jsp?thread=214325 - два хороших места для начала.

@Daz: ссылки, которые вы дали, говорят либо о теле функции (но я говорю об объявлении аргументов), либо о семантике функций 1-го класса (что полностью ортогонально синтаксису).

Это делает программы довольно медленными. Сравните python с C или C++, и вы увидите огромную разницу в производительности при работе с целыми числами. Это позволит избежать переполнения за счет постоянной полной проверки. Это во многих случаях является источником преждевременной пессимизации.

По крайней мере, в Common Lisp вы можете указать типы данных позже, как только вы добьетесь правильной работы программы. Вот как CMU Common Lisp однажды победил компилятор Fortran в состязании по вычислению чисел.

В основном это Алан Перлис: «Функции задерживают привязку: структуры данных вызывают привязку. Мораль: структурируйте данные на поздних этапах процесса программирования».

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

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

Не забывайте, что то, что считается «правильным» с точки зрения стандартов разработки, было всего лишь чьим-то временным здравым смыслом, которое случайно подхватило множество людей. Это не заповедь «свыше» - здравый смысл может измениться, но он всегда полезен. Хорошая работа.

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

Мой общий совет - следовать соглашению и не попадаться в ловушку, пытаясь заставить их указывать конкретные условия ошибки. На каждом уровне вы должны предпринять шаги, чтобы значение нормализовалось. (Что обычно не сложно / необходимо, если вы следуете соглашению)

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

Если платформа GC не подходит для вашей конкретной ситуации, будьте благоразумны и не используйте ее. Это так просто.

Какие? Для создания динамического веб-сайта, генерируемого на стороне сервера, вам понадобятся все три (если вы не используете другую систему). Для PHP у вас есть шаблоны, мощность сервера и т. д. Для HTML у вас есть основа фактического сайта. JS: динамически загружаемый контент, специальные функции (подсветка синтаксиса).

+1. Это вопрос собственности, мы склонны больше заботиться о вещах, которыми мы владеем, чем о вещах, которыми мы не владеем. Хотите доказательств? Взгляните на автомобили вашей компании.

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

Я думаю, что тестирование и развитие - это разные навыки, их должны делать те, кто хорошо в них разбирается. Изолировать тестировщиков от разработчиков и затруднить исправление ошибок тестировщиками: нет оправдания.

Мне кажется, это плохие разработчики. Я бы подал это под не все ленивые разработчики хорошие разработчики.

+1 за противоречие: я собираюсь тестировать только те вещи, которые, как я думаю, проверять, и если я разработаю конкретный метод ... Я уже подумал обо всем, что может пойти не так (с моей точки зрения). Хороший тестировщик увидит другую точку зрения -> понравится вашим пользователям.

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

C НЕ подходит для всего! это не инструмент для веб-разработки! есть хотя бы что!

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

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

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

Это 3 мнения в одном ответе, и все они дураки

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

В C++ очень сложно создавать пригодные для использования классы, но как только вы их создадите, жизнь станет очень легкой. Намного проще, чем использовать простой C. Я делаю следующее: я реализую функциональность на C, а затем оборачиваю ее с помощью классов C++.

На мой взгляд, многие опасения по поводу C++ проистекают из того факта, что C++ обычно преподают неправильно. Обычно нужно отучиться от C, прежде чем он сможет хорошо разбираться в C++. Изучение C++ после C никогда не казалось мне хорошей идеей.

И я думаю, что C++ превосходит C во всех отношениях, за исключением того, что, к сожалению, он был разработан так, чтобы быть «обратно» совместимым с C.

Я думаю, что C++ - хороший пример «разработки комитетом», выполненного ВЕРНО. Это беспорядок во многих отношениях, и для многих целей это паршивые языки. Но если вы потрудитесь по-настоящему выучить его, в нем спрятан удивительно выразительный и элегантный язык. Просто обидно, что мало кто это обнаруживает.

У меня есть еще одна проблема: «Вы можете обучать C++ двумя способами» - это неправильно. Очевидно, вы когда-либо использовали C++ только двумя способами, не раскрывая его истинный потенциал. Это также объясняет ваш опыт работы с микроконтроллерами: C на нет быстрее, чем (хорошо написанный) C++.

+1: Из всех языков, с которыми я когда-либо играл, С ++ - единственный, от которого меня тошнит каждый раз, когда я к нему обращаюсь. У меня уже много лет есть книга по C++, время от времени я беру ее и говорю себе: «На самом деле не может быть так уж плохо» и читаю до тех пор, пока мои глаза не кровоточат, я добрался до страницы 47.

Существует третий подход к изучению C++: его использует ускоренный C++. Он строится с самого начала (переменные, функции), но с использованием реальных элементов C++ (STL). Я рекомендую его всем, кто хочет еще раз взглянуть на C++.

@dribeas: Я ценю рекомендацию, похоже, хорошая книга. Я сомневаюсь, что когда-нибудь смогу «оценить» то, что может предложить C++, но если я когда-нибудь оправлюсь от своего предыдущего опыта, я приму вас по вашей рекомендации.

Хорошо, если код C++ был в десять раз медленнее, чем код C, какие компиляторы Микки Мауса вы использовали? Или какие идиотские соглашения о коде вы должны были использовать? Например, вас просили сделать спецификации исключений (почти всегда плохая идея)?

Просто выбросьте это там, но в тестовой игре Programming Language есть довольно много примеров того, как C++ работает быстрее C.

«Когда вы переходите на C++, вы получаете огромные накладные расходы, накладываемые компилятором на управление языковыми функциями, которые вы не можете использовать. Во встроенных приложениях вы мало что выиграете, добавляя классы и тому подобное, IMO. Вам нужен жесткий, чистый код . " - кто сказал, что вы имеют используете классы, rtti и еще много чего?

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

и я согласен, что это почти хороший первый язык. ИМХО неразумно сначала этому учить. и хорошо, что он совместим с С. нуфф сказал :)

Я согласен с тем, что здесь куча проблем. но хуже всего? Вы когда-нибудь видели интеркал? BFUNGE? язык ассемблера?

Что касается вашего анекдота о том, что C++ на порядок медленнее, имейте в виду, что компиляторы C++ 80-х - это не то же самое, что компиляторы C++ сегодня.

Я согласен, что это худший язык на свете. За исключением всех остальных.

Я не согласен, что это худший язык; Я согласен, что это плохой язык; Я также согласен с тем, что это плохой родной язык. C++ мощен и имеет множество очень полезных функций. Иногда это делает C++ хорошим выбором. В C++ также есть много скрытого зла (много неопределенного поведения, которое выглядит прекрасно ...), что делает его плохим языком и, безусловно, плохим первым языком.

@ david-basarab - компиляторы C++ теперь намного лучше! Я использую C++ не только для MIDI, но и для алгоритмов аудио DSP - использование шаблонов C++ делает его очень мощным для создания настраиваемых параметров времени компиляции, таких как размер и макет буфера, что позволяет выполнять автоматическую оптимизацию SSE / altivec. Преимущество C++ в настоящее время заключается не в языке, который в наши дни всегда является загадкой для шаблонов, а в том, что доступные компиляторы лучше оптимизируют функции реального времени, чем Haskell, Ada, Scheme и Scala.

-1. C++ по-прежнему остается самым мощным и широко доступным языком с множеством парадигм. Это наиболее адаптируемый из всех, поэтому он может решать множество различных проблем, что в некоторых приложениях полезно очень. Возможно, это не лучший вариант для каждой конкретной вещи, но в целом это редко бывает действительно плохим выбором.

C++ подобен демократии: "Многие формы правления были испытаны и будут испытаны в этом мире греха и горя. Никто не притворяется, что демократия совершенна или всесторонне развита. Действительно, было сказано, что демократия - наихудшая форма. правительства, за исключением всех тех других форм, которые время от времени применялись ". -Сэр Уинстон Черчилль

C++ огромен и пользуется огромной популярностью. Как и все языки, у него есть приложения, для которых он хорошо подходит, и приложения, для которых он не подходит.

+1 За второй язык. Сначала я выучил Java, а год спустя - немного C. Я рад, что изучил материал C низкого уровня, потому что он делает меня лучшим программистом высокого уровня, но я также рад, что мне не пришлось начинать с C.

А как насчет Objective-C? И я полностью согласен с вами, Хантродс.

Мне это нравится, но это спорно?

Тех, кто не умеет, учите. Согласно этой логике, люди, которые не умеют программировать, учат нас программированию. Я сам испытал это, когда профессора, которых я имел, признались, что не могут выполнять задачи и упражнения, которые они назначают. Совет: посещайте занятия с преподавателями, нанятыми университетом, а не с профессорами, имеющими постоянную (или постоянную) должность.

Это напоминает мне цитату (хотя я не могу вспомнить, кто ее сказал): «Измерение программы строками кода похоже на измерение плоскости по весу».

@ Cristián: Это сказал Билл Гейтс.

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

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

+1: Все должны сначала изучить C, потому что программирование не для всех и не для тех, кто не понимает C.

Взломайте их с помощью сырого машинного кода. Страдать!!! Курс ассемблера был самым интересным (во время занятий) в университете.

Мифология. До знакомства с C я изучил сборку 2/3 CPU и ознакомился с другими. Некоторые процессоры приятно программировать из-за их ортогональных наборов инструкций, другие - неприятно, но менее идиосинкразично, чем C.C не подходит для предполагаемого использования, то есть портативной сборки.

.. и я нахожу жалкой элитарность, которую проявляют слишком многие программисты.

В моем университете программирование преподавалось почти исключительно на Java. Я почувствовал себя одновременно возбужденным и обманутым, когда наконец добрался до изучения C и C++.

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

@Matt: ты не должен соглашаться;)

Я много преподавал вводный CS. То, что я обнаружил, было наиболее полезным - это сначала несколько недель на симуляторе десятичной машины, чтобы настроить базовую мысленную структуру адресов, памяти, инструкций и пошагового выполнения. Потом мы сделали Basic (извините), затем Pascal. Мне нравится C (и C++), но учить этому новичков - ад, потому что есть слишком много тонких способов запутать студентов, например, разница между указателями и ссылками на массивы и вложенными типами. Сказать «тонуть или плавать» неприемлемо - они платят за обучение.

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

И становится все проще и легче, не так ли?

«вы наконец понимаете, что все языки программирования одинаковы» - вы часто слышите это от людей, которые программировали только на C#, C++, разновидностях VB, Java и, возможно, Python. Затем вы наконец изучаете Haskell, Ocaml, Erlang, Prolog и Lisp и чувствуете себя идиотом из-за того, что так много пропустили.

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

@cookre: попробуйте использовать алгоритмы, разработанные для выражения на императивном языке программирования (PL) с чисто ленивым функциональным PL, таким как Haskell, или в логике (ограничений) PL, такой как Prolog (и производные), или в PL, разработанном для отказоустойчивости и массивный параллелизм, такой как Erlang, и вы обнаружите, что различия в семантике - это все, что действительно имеет значение.

Я с гордостью могу сказать, что прочитал все имеющиеся у меня книги по программированию. Даже чудовищный Python Programming и Programming Perl.

У меня есть степень бакалавра. на английском. Скорее всего, я для этого лучше программист. Это то, что ты имеешь в виду?

Вы переоцениваете ценность образования. Я работаю программистом на полную ставку уже 15 лет, и я самоучка. Когда я встречаю разработчиков, только что окончивших школу, я иногда задаюсь вопросом, не было ли все обучение пустой тратой времени. Они почти ничего не знают о «реальном мире», редко могут работать самостоятельно, а их навыки в лучшем случае средние.

@ Седьмой элемент: я бы ожидал, что кто-то, только что окончивший школу, без опыта работы, будет иметь средние навыки. Сравнивать недавнего выпускника с человеком с 15-летним опытом работы - это сравнивать яблоки с апельсинами. Я проработал программистом 8 лет, прежде чем вернуться в школу, чтобы получить степень. Думаю, я довольно хорошо понимаю ценность своего образования мне. Вы получаете то, что вкладываете в это.

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

Вы когда-нибудь слышали о модульных тестах? Используя модульные тесты, вам не нужно «проверять все пути» после каждого изменения, которое вы внесли в код. (Во всяком случае, я думаю, что невозможно проверить все пути, кроме крошечного небольшого приложения)

Похоже, вы видите, что процесс используется для компенсации плохих программистов, а не для повышения квалификации великих разработчиков. Вот почему в Agile Manifest сказано: «Люди и взаимодействие важнее процессов и инструментов». Вместо того, чтобы добавлять процесс для плохих программистов, добавляйте его, когда количество программистов вырастет.

@jay не совсем так. Я думаю, что этот процесс даже у лучших разработчиков вызывает снижение качества кода. Я бы сравнил это со встречей со знаменитым художником, а затем с рассказом ему правил, которых он должен придерживаться, чтобы сделать хорошую картину. Для вас это может иметь смысл, но это смешно.

Я подозреваю, что у великих художников есть свои собственные процессы.

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

Я не мог с тобой больше согласиться! Споры, которые я вел с другими программистами по поводу их строгого соблюдения процессов, могут составить книгу размером с «Войну и мир». Однако это включает как «хорошие», так и плохие процессы.

Я видел обратный эффект. Я работал в компании, которая использовала методологию Agile, и качество кода было кошмарно плохим, не говоря уже о ужасном. Сейчас я работаю в компании с очень жестким процессом, множеством бюрократических проволочек, связанных с недокументированными изменениями, и получающийся код на высшем уровне.

Один размер не подходит для всех. Небольшой проект, небольшая команда в одном месте, опытные разработчики, эксперт в предметной области на месте, программное обеспечение не является абсолютно важным? (какое-то программное обеспечение, если у вас есть ошибка, кто-то может умереть.) Тогда да, просто одичал. Если нет, вам нужно больше процесса.

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

Замените язык разметки на YAML ... вы, должно быть, сошли с ума. Голосование за хорошую полемику.

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

Мое неоднозначное мнение по этому поводу: любой, кто описывает технологию как «зло», является злом. Узоры не убивают людей, люди убивают людей.

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

«Языки ООП со статической типизацией не могут избежать наследования» - OCaml - это язык ООП со статической типизацией, но он также поддерживает структурную типизацию ((en.wikipedia.org/wiki/Structural_type_system), что более или менее является «утиной типизацией для статических языков». роль наследования.

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

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

на самом деле не «спорный» - это установившаяся практика везде я работал

Первый не вызывает споров, по крайней мере, в области CS.

Я не согласен. Я знаю многих людей, изучающих информатику, которые думают, что они получают степень в области программирования. Каждый раз, когда я слышу нытье о том, почему программы CS не учат всех Java, я с болью вздыхаю.

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

Я могу согласиться с первым пунктом, но говорю, что знание только Java может сделать программиста ..... это преступление, караемое смертью !!!

Можете ли вы переместить свой второй ответ в другой пост, чтобы его можно было оценить отдельно?

@ Грег: Готово. Спасибо за предложение.

Я согласен с «не следует», но не с «не должен». Где еще в академических кругах вы должны научиться программировать? В программном обеспечении нет аналога инженерным дисциплинам (механика, электрика, гражданское строительство и т. д.).

@MusiGenesis: В моем местном общественном колледже есть степень «младшего специалиста по прикладным наукам» по направлению «Компьютерное программирование». (Washtenaw Community College) Вот куда я пошел бы, чтобы стать программистом. Важно не путать информатику с программистом. Они НЕТ одно и то же

@MusiGenesis: На самом деле я только что получил степень в области инженерии (программное обеспечение). Я, конечно, не компьютерный ученый, и я не хочу им быть.

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

Я не согласен с тем, что CS не учит вас быть программистом. Он ДЕЛАЕТ и ДОЛЖЕН делать это - кстати, обучая нескольким языкам, а не только одному - но это еще не ВСЕ, что он должен делать. Степени CS также должны научить вас как можно большему количеству различных областей CS, например, базовое программирование, функциональные языки, базы данных, криптография, AI, языковая инженерия (например, компиляторы / синтаксический анализ), архитектура и математические области, такие как компьютерная графика и различные алгоритмы. .

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

Я не согласен. Степень CS учит вас, как часто решать проблемы с использованием C / C++ (низкоуровневые языки), она учит вас дизайну алгоритмов, теории, лежащей в основе ОС, общим алгоритмам, используемым повсюду - все это применимо, если вы хотите кодировать. Другими словами, вы получаете основы - основу, которую вы можете построить, изучая больше языков. Знание Java не делает вас программистом, на самом деле, это самая нелепая вещь, которую я слышал некоторое время.

Моя компания разрабатывает программное обеспечение для автострахования, и мы полагаемся на несколько внешних веб-сервисов для проверки номеров VIN и проведения проверок OFAC на людях. Мы также делаем некоторые из наших API-интерфейсов доступными через веб-службы сторонним поставщикам. Как бы вы посоветовали написать наше программное обеспечение без веб-сервисов?

@Juliet: что в "Web-сервисах НИКОГДА нельзя использовать в системе где пишутся и клиент, и сервер", вы не понимаете? Понятно, что в вашей ситуации вы не контролируете обе части системы, поэтому ваш риторический вопрос неуместен.

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

Идиома «Истинно XYZ» обычно является случаем ошибки «Не истинный шотландец». Что касается остального, вы читали xahlee.org/Periodic_dosage_dir/t2/oop.html? Кроме того, это очень похоже на сообщение perlmonks, вы писали об этом раньше?

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

Я ни разу не слышал, чтобы кто-нибудь говорил о словосочетании «действительно объектно-ориентированный» за последние 10 лет, которые я занимаюсь программированием. Никогда. Ни разу. Вы на самом деле цитируете какого-нибудь неприятного менеджера?

Любой, кто начал с java или C++, а затем попробовал lua, или javascript, или какой-либо другой язык, в котором нет какой-либо произвольной функции java. Любой, кто укоренился в мире Java и считает, что одиночные игры - ужасная идея. Любой, кто читал книгу GoF и думал, что это будущее

Почти, ИМХО. Я думаю, что ООП - идеальный способ справиться с некоторыми аспектами программирования, но это не то, чем оно задумывалось: это не замена каждой методологии и / или фрагменту кода, с которым вы когда-либо сталкивались; Он не застрахован от того, чтобы зайти слишком далеко; Это не ваш хозяин; Незаменимый.

Вы имеете опыт работы с VB6 и никогда не принимали ООП?

Неправильно. В ООП нет ничего плохого, это просто стратегия. Проблема в том, что я должен был «принять» это, или единственная альтернатива - я немного отсталый новичок. Это еще не конец, это не религия, и мне не нужно быть распятым, чтобы исключить меня из пула программистов, чтобы все «правильные» программисты могли жить без греха. Я опубликовал свой ответ на этот вопрос, потому что это самое противоречивое мнение, которое у меня есть. Это был вопрос.

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

Я ненавижу, когда новички читают мне лекции о величии ООП, когда я программирую на ООП-языках с середины 80-х. Они полностью слепы к недостаткам ООП, они не знают, что «ООП» - это плохо определенная концепция, и, что хуже всего, они игнорируют целый мир вариантов w.r.t. парадигмы программирования.

+1 Хотел бы я проголосовать больше. Это поле изобилует подножками, гуру, «правильным мышлением», а иногда и хорошими идеями, воплощенными в религии. Для инженера-механика / электрика (вроде меня) это так странно. Я полагаю, что если что-то правда, то этому есть научная причина. Я также считаю, что изобретательность - это хорошо. Очень мало этого в этой области.

Есть ли оправдание вашей позиции?

Итак, вы не видите значения в использовании стиля (camelCase vs CamelCase vs ALL_CAPS), чтобы указать, относится ли ссылка к классу, переменной, константе или чему-то еще? Я не могу согласиться. Похоже, вы могли не знать об идее соглашений об именах. например возможность.com/Cpp/CppCodingStandard.html#names