Что вы наиболее противоречивое мнение программирования?

Исключения считаются вредными.

(Безымянный) кортежи - это зло

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

• Если вы используете их для возврата нескольких значений из метода, используйте вместо этого параметры Out (для этого требуется, чтобы ваш язык поддерживал передачу по ссылке)

• Если это часть стратегии обфускации кода, продолжайте использовать их!

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

Что (по крайней мере, во время первоначального проектирования) каждая таблица базы данных (ну, почти каждая) должна быть четко определена, чтобы содержать какую-то явно понятную бизнес-сущность или абстракцию домена системного уровня, и что независимо от того, используете ли вы ее как первичный ключ и как внешние ключи в других зависимых таблицах, некоторые столбцы (атрибуты) или подмножества атрибутов таблицы должны быть четко определены, чтобы представлять уникальный ключ для этой таблицы (сущность / абстракция). Это единственный способ гарантировать, что общая структура таблицы представляет логически непротиворечивое представление всей структуры данных системы, без наложения или неправильного понимания сглаживания. Я твердо верю в использование бессмысленных суррогатных ключей для Pks и Fks и функциональности объединения (для производительности, простоты использования и других причин), но я считаю, что тенденция в этом направлении слишком сильно отодвинула сообщество баз данных от первоначальные принципы Кобба, и мы потеряли большую часть преимуществ (согласованности базы данных), которые обеспечивали естественные ключи.

Так почему бы не использовать оба?

Лучшие практики не являются.

80% ошибок вносятся на этапе проектирования.
Остальные 80% вводятся на этапе кодирования.

(Это мнение было вдохновлено чтением ответа Димы Маленко. «Разработка на 80% связана с дизайном и 20% - с кодированием», да. «Это даст код с почти нулевыми ошибками», нет.)

Один класс на файл

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

Если вы не читали справочную страницу, вы не настоящий программист.

Никогда не принимайте решение по какой-либо проблеме, прежде чем тщательно рассмотреть эту проблему. Ни один стандарт программирования НИКОГДА не оправдывает плохое решение проблемы. Если стандарт требует написания класса, но после тщательного обдумывания вы считаете, что статический метод более уместен, всегда используйте статический метод. Ваше собственное усмотрение всегда лучше, чем даже самые лучшие идеи того, кто написал стандарт. Стандарты хороши, если вы работаете в команде, но правила должны быть нарушены (со вкусом, конечно).

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

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

Разработка на .NET - это не программирование. Это просто склеивание чужого кода.

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

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

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

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

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

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

Можно использовать короткие имена переменных

Но не для индексов во вложенных циклах.

Повторное использование программного обеспечения является наиболее важным способом оптимизации разработки программного обеспечения

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

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

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

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

Шаблоны проектирования плохие.

На самом деле, шаблоны проектирования не .

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

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

Чтобы быть действительно спорным:

Вы ничего не знаете!

или другими словами:

Я знаю, что ничего не знаю .

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

При запуске с компьютеров / разработки, ИМХО, есть три этапа, через которые должен пройти каждый:

новичок: ничего не знает (это факт)

Промежуточный: думает, что он знает что-то / очень (/ все) (это тщеславие)

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

Я думаю, как программист, вы должны знать, как учиться - или лучше: учиться учиться (потому что помните: вы ничего не знаете!;)).

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

Удалить классы. Количество классов (методов классов) в .NET Framework неявно обрабатывает исключения. Трудно работать с тупым человеком.

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

• [Генераторы документации] ( http: //en.wikipedia.or / wiki / Comparison_of_documentation_generators): ... вид, в котором создатель изобрел несколько специально созданных специально для документирования -sourcecode roll-your-own синтаксис (включая, но не ограничиваясь этим, JavaDoc) совершенно излишен и является пустой тратой времени, потому что:

  • 1) Они недоиспользуются людьми, которые должны их использовать самый; и
  • 2) Все эти мини-языки документации все они могут быть легко заменены на YAML

Жесткое кодирование - это хорошо!

Действительно, во многих случаях это более эффективно и намного проще в обслуживании!

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

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

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

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

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

Примеры домашних животных: Java следует использовать только тогда, когда спецификация очень хорошо продумана (из-за множества взаимозависимостей, означающих рефакторинг ада) и при работе с конкретными концепциями. Perl должен использоваться только для обработки текста. C следует использовать только тогда, когда скорость превыше всего, включая гибкость и безопасность Пары ключ-значение должны использоваться для одномерных данных, CSV для двумерных данных, XML для иерархических данных и DB для чего-либо более сложного.

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

Что Закон Деметры , рассматриваемый в контексте агрегации и композиции, является анти-паттерном.

«остальное» вредно.

Есть только 2 типа людей, которые используют C (/ C ++): те, кто не знает другого языка, и те, кто слишком ленив, чтобы выучить новый.

Существует разница между программистом и разработчиком. Пример: программист пишет логику разбиения на страницы, разработчик интегрирует разбиение на страницы на странице.

Люди жалуются на удаление слова «goto» из языка. Мне кажется, что любой вид условного перехода сильно переоценен и что «если», тогда как «switch» и цикл общего назначения для «for» сильно переоценены и должны использоваться с особой осторожностью.

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

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

Очевидно, что это не практично для многих проектов и алгоритмов (таких как циклы потока управления), но это то, что мне нравится продвигать.

-Rick

Вот мое:

«Вам не нужен (текстовый) синтаксис для выражения объектов и их поведения».

Я присоединяюсь к идеям Джонатана Эдвардса и его проекта Subtext - http://alarmingdevelopment.org/

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

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

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