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

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

Мнение: Не должно быть никаких предупреждений компилятора, только ошибки . Или, сформулированный по-другому Вы всегда должны компилировать свой код с -Werror .

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

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

Глобалы и / или синглтоны не являются злыми по своей природе.

Я пришел из системного администратора, оболочки, Perl (и моего «реального» программирования), фона типа PHP; В прошлом году меня бросили на концерт Java.

Синглтоны - это зло. Глобалы настолько злы, что их даже не пускают. Тем не менее, в Java есть такие вещи, как AOP, и теперь различные фреймворки «Dependency Injection» (мы использовали Google Guice). АОП меньше так, но DI вещи наверняка дадут вам что? Глобал. Ух, спасибо.

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

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

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

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

Я действительно не думаю, что это должно быть спорным, но это так. Люди видят пример из другого места в коде, из Интернета или из какой-то старой книги «Научите себя продвинутому SQLJava # BeansServer за 3,14159 минут» за 1999 год, и они думают, что что-то знают, и копируют это в свой код. Они не идут по примеру, чтобы выяснить, что делает каждая строка. Они не думают о дизайне своей программы и не могут найти более организованный или более естественный способ сделать то же самое. Они не предпринимают никаких попыток поддерживать свои навыки в актуальном состоянии, чтобы понять, что они используют идеи и методы, которые устарели в последний год предыдущего тысячелетия. Похоже, у них нет опыта, чтобы понять, что то, что они копируют, годами создавало особую ужасную нагрузку на программистов, и что их можно избежать, если немного подумать.

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

Я родом из мира Perl, где один из лозунгов: «Есть больше, чем один способ сделать это». (TMTOWTDI) Люди, которые бегло взглянули на Perl, списали его как «только для записи» или «нечитаемый», в основном потому, что смотрели на дерьмовый код, написанный людьми с менталитетом, который я описал выше. Эти люди не задумывались над дизайном, ремонтопригодностью, организацией, уменьшением дублирования в коде, связыванием, связностью, инкапсуляцией и т. Д. Они пишут дерьмо. У этих людей есть программирование на всех языках, и они легко изучают языки с множеством способов сделать что-то, что дает им много веревки и оружия, чтобы стрелять и вешаться. Одновременно.

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

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

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

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

VB отстой
Хотя это не очень противоречиво в целом, когда вы работаете в доме VB, это

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

Если вы хотите проверить правильность кода, я предпочитаю следующие методы, а не модульное тестирование:

1. Проверка типов
2. Утверждения
3. Тривиально проверяемый код

Для всего остального есть модульные тесты.

Современный C ++ - прекрасный язык .

Там я это сказал. Многие люди действительно ненавидят C ++, но, честно говоря, я считаю современный C ++ с программированием в стиле STL / Boost очень выразительным, элегантным и невероятно продуктивным в большинстве случаев.

Я думаю, что большинство людей, которые ненавидят C ++, основывают это на плохом опыте с ОО. C ++ не очень хорошо работает с OO, потому что полиморфизм часто зависит от объектов, выделенных в куче, а C ++ не имеет автоматической сборки мусора.

Но C ++ действительно великолепен, когда дело доходит до универсальных библиотек и методов функционального программирования, которые позволяют создавать невероятно большие, легко обслуживаемые системы. Многие люди говорят, что C ++ пытается сделать все, но в итоге ничего не делает. Я бы, вероятно, согласился с тем, что он не поддерживает OO так же хорошо, как другие языки, но делает общее программирование и функциональное программирование лучше , чем любой другой основной язык на основе Си. (C ++ 0x еще больше подчеркнет эту истину.)

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

Плюс RAII. Шутки в сторону. Я действительно скучаю по деструкторам, когда я программирую на других языках Си. (И нет, сборка мусора не делает деструкторы бесполезными.)

«Комментарии - это ложь»

Комментарии не выполняются и легко игнорируются. Намерение лучше выразить с помощью ясного, переработанного кода, проиллюстрированного модульными тестами. (Конечно, модульные тесты написаны TDD ...)

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

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

Спорный а? Я считаю, что потоки C ++ используют < < и >> Я ненавижу это. Они операторы сдвига. Перегрузить их таким способом - плохая практика. Это заставляет меня хотеть убить любого, кто придумал это и подумал, что это хорошая идея. GRRR.

Исключения следует использовать только в действительно исключительных случаях

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

Вот пример:

У нас есть фильтры, которые перехватывают веб-запросы. Фильтр вызывает средство проверки, и задание проверяет, имеет ли запрос определенные входные параметры, и проверяет параметры. Вы устанавливаете поля для проверки, и абстрактный класс проверяет, чтобы параметры не были пустыми, а затем вызывает метод screen (), реализованный вашим конкретным классом, для более расширенной проверки:

public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{           
            // 
            if (!checkFieldExistence(req)){
                    return false;
            }
            return screen(req,resp,filterConfig);
    }

That checkFieldExistance ( req) метод никогда не возвращает false. Он возвращает true, если ни одно из полей отсутствует, и выдает исключение, если поле отсутствует.

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

Кроме того, я знаю, что сигнатура checkFieldExistance (req) действительно вызывает исключение, просто почти все наши методы это делают - так что мне не пришло в голову, что метод может выдать исключение вместо возврата false. Только пока я не начал копаться в коде, я заметил это.

Самый простой подход - лучший подход.

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

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

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

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

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

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

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

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

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

Подобная глупость в IMO возникает, когда вас спрашивают о высокодоступных основах, например: «Ой, подождите, позвольте мне посмотреть, можете ли вы использовать псевдокод этого insert_name_here -алгоритма на листе бумаги (так! )». Мне действительно нужно помнить это при подаче заявления на работу по программированию высокого уровня? Должен ли я эффективно решать проблемы или головоломки?

JavaScript - это «грязный» язык, но, боже, помоги мне, мне это нравится.

Мое противоречивое мнение: OO Программирование значительно переоценено [и рассматривается как серебряная пуля], когда оно действительно просто еще один инструмент в наборе инструментов, не более того!

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

Если вы программист, то вы, скорее всего, ужасны в веб-дизайне / разработке

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

Конечно, XHTML и CSS просты в освоении. Тем не менее, вы не просто изучаете язык! Вы учитесь правильно его использовать, и очень немногие дизайнеры и разработчики могут сделать это, не говоря уже о программистах. Мне понадобились целые годы, чтобы стать способным дизайнером и еще дольше стать хорошим разработчиком. Я мог писать в HTML с 10 лет, но это не значит, что я был хорош. Теперь я опытный дизайнер в таких программах, как Photoshop и Illustrator, я прекрасно умею писать хороший веб-сайт в Блокноте и могу писать базовые сценарии на нескольких языках. Не только это, но я хорошо разбираюсь в методах поисковой оптимизации и могу легко сказать вам, где большинство людей идут не так (подсказка: получите хороший контент!).

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

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

Если вы новичок в веб-дизайне / разработке, не беспокойтесь об этом месте (здесь полно программистов, а не веб-разработчиков). Посетите хорошее сообщество веб-дизайнеров / разработчиков, например SitePoint .

Два мозга думают лучше, чем один

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

Разделение интересов является злом:)

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

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

Рад обсудить это дальше.

Массивы должны по умолчанию основываться на 1, а не на 0. Это не обязательно относится к языкам реализации системы, но такие языки, как Java, поглотили больше странных Си, чем они должны были иметь. «Элемент 1» должен быть первым, а не вторым, чтобы избежать путаницы.

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

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

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

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

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

Слишком много программистов пишут слишком много кода.

Отладчики - это костыль.

Это настолько противоречиво, что даже я не верю в это так, как раньше.

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

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

Прежде чем нажать «Опубликовать свой ответ», я быстро проверил в Google эту точную фразу, оказалось, что я не единственный, кто придерживался этого мнения или использовал эту фразу. Я поднял долгое обсуждение этого самого вопроса на форуме по программному обеспечению Fog Creek, на котором в качестве заметных сторонников упоминались разные светила, в том числе Линус Торвальдс

Наследование является злом и должно быть осуждается.

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

Примитивные типы данных преждевременной оптимизации.

Есть языки, которые обходятся только одним типом данных, скаляр, и они прекрасно справляются. Другим языкам не так повезло. Разработчики просто добавляют «int» и «double», потому что они должны что-то писать.

Важно не то, насколько велики типы данных, а то, для чего они используются. Если у вас есть переменная дня месяца, то не имеет большого значения, подписан он или нет, или тип char, short, int, long, long long, float, double или long double. Неважно, что это день месяца, а не месяц, или день недели, или что-то еще. См. Колонку Джоэла о том, как сделать неправильные вещи неправильными; Венгерская нотация в первоначальном предложении была хорошей идеей. На практике это в основном бесполезно, потому что говорит не то, что нужно.

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

Тогда внезапно военнопленный! Кто-то придумал этот термин, и все вскочили на подножку AJAX. Внезапно люди стали экспертами в AJAX, как будто «экспертов» по ​​динамической загрузке данных раньше не было. Я думаю, что это один из самых значительных факторов, который ведет к жестокому разрушению Интернета. Это и «Web 2.0».

1. Вы не должны всегда следовать веб-стандартам.

2. Вам не нужно комментировать свой код.

Пока это понятно незнакомцу.

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

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

Мнение: Управляемый данными дизайн ставит телегу впереди лошади. Это должно быть немедленно устранено из нашего мышления.

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

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

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

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

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

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