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

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

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

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

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

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

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

Данные - это система.

Процессы и программное обеспечение созданы для данных, а не наоборот.

Без данных процесс / программное обеспечение мало что значит. Данные по-прежнему имеют ценность без какого-либо процесса или программного обеспечения.

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

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

Исходные файлы SO 20-го века.

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

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

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

По сути, я хочу сказать, что в современных языках не имеет значения, в какие файлы вы помещаете свои классы или в каком порядке вы определяете членов класса, так почему же мы все еще вынуждены использовать эти архаичные практики? Помните, когда вышел Gmail и Google сказал: «Не сортируй»? Ну, а почему нельзя применить ту же философию к языкам программирования?

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

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

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

Хорошая идея - помнить об оптимизации при разработке кода.

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

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

Hugo

Избегайте отступов.

Используйте досрочный возврат, продолжение или перерыв.

вместо:

if (passed != NULL)
{
   for(x in list)
   {
      if (peter)
      {
          print "peter";
          more code.
          ..
          ..
      }
      else
      {
          print "no peter?!"
      }
   }
}

do:

if (pPassed==NULL)
    return false;

for(x in list)
{
   if (!peter)
   {
       print "no peter?!"
       continue;
   }

   print "peter";
   more code.
   ..
   ..
}

C ++ - хороший язык

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

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

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

В C ++ есть много функций, которые мне отчаянно не хватает при программировании на C # или других «современных» языках. В нем есть чему поучиться на C # и других современных языках.

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

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

Детерминированное уничтожение переменных позволяет RAII, чрезвычайно мощный маленький трюк, который делает блоки try / finally и блоки using в C # избыточными.

И хотя некоторые люди обвиняют его в том, что он «проектируется комитетом», я бы сказал, что да, это так, и в данном случае это на самом деле неплохо. Посмотрите на библиотеку классов Java. Сколько классов снова устарело? Сколько не следует использовать? Сколько дублируют функциональность друг друга? Сколько из них плохо спроектировано?

Стандартная библиотека C ++ намного меньше, но в целом она удивительно хорошо спроектирована, и, за исключением одной или двух незначительных бородавок (например, vector<bool>), ее дизайн все еще остается в силе. очень хорошо. Когда функция добавляется в C ++ или его стандартную библиотеку, она подвергается тщательному анализу. Разве Java не могла извлечь выгоду из того же самого? Также .NET, хотя он и моложе и был несколько лучше спроектирован с самого начала, по-прежнему накапливает большое количество классов, которые не синхронизированы с реальностью или плохо спроектированы с самого начала.

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

Там очень много плохого обучения там.

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

Картинка не стоит тысячи слов.

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

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

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

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

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

Вы должны остерегаться объектно-одержимых программистов.

например. если вы напишите класс, который моделирует встроенные типы, такие как int или float, вы можете быть одержимым объектами программистом.

Хорошо, если ты не знаешь. Но вы уволены, если не можете даже погуглить.

Интернет - это инструмент. Это не делает тебя глупее, если ты учишься у него.

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

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

Синглтоны не являются злом

В реальном мире есть место для синглетонов, и методы обхода их (то есть моностатный паттерн) - это просто замаскированные синглтоны. Например, Logger является идеальным кандидатом на синглтон. Кроме того, так же насос сообщений. Мое текущее приложение использует распределенные вычисления, и разные объекты должны иметь возможность отправлять соответствующие сообщения. Должен быть только один насос сообщений, и каждый должен иметь к нему доступ. Альтернатива - передавать объект в мой почтовый насос везде, где это может быть необходимо, и надеяться, что новый разработчик не создаст новый, не задумываясь и не удивляясь, почему его сообщения никуда не денутся. Уникальность синглтона является самой важной частью, а не его доступность. Синглтон имеет свое место в мире.

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

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

Кроме того, когда я вызываю метод, у меня нет возможности узнать, может ли этот метод вернуть нулевые ссылки, если я на самом деле не копаюсь в реализации. Я хотел бы, чтобы больше языков следовало модели F # для обработки нулей: F # не позволяет программистам возвращать нулевые ссылки (по крайней мере, для классов, скомпилированных в F #), вместо этого требуется, чтобы программисты представляли пустые объекты, используя типы option. Хорошая вещь в этом дизайне заключается в том, как полезная информация, например, может ли функция возвращать нулевые ссылки, распространяется через систему типов: функции, которые возвращают тип 'a, имеют тип возвращаемого значения, отличный от функций, которые возвращают 'a option.

Возможно, меня за это поджарят, но:

Создание невидимых символов, синтаксически значимых в python, было плохой идеей

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

Не пишите код, удаляйте код!

Как умный учитель однажды сказал мне: «Не пишите код, Написание кода - это плохо, Удаление кода - это хорошо. И если вам нужно писать код» - напиши маленький код ... "

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

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

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

Не используйте наследование, если не можете объяснить, зачем оно вам нужно.

Если вы разработчик, вы должны быть в состоянии написать код

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

Учитывая, что Pi можно оценить, используя функцию 4 * (1 - 1/3 + 1/5 - 1/7 + ...) с больше терминов, дающих большую точность, напишите функцию, которая вычисляет число Пи с точностью до 5 десятичных знаков.

Это проблема, которая должна заставить вас задуматься, но не должна быть недоступна опытному разработчику (на нее можно ответить примерно в 10 строках C #). Однако многие из наших (предположительно предварительно отобранных агентством) кандидатов даже не смогли начать отвечать на них или даже объяснить, как они могли бы ответить на него. Поэтому через некоторое время я начал задавать более простые вопросы, например:

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

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

Редактировать:

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

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

Читаемость является наиболее важным аспектом вашего кода.

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

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

Хорошо написанный код на языках с динамической типизацией следует соглашениям статической типизации

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

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

• Ошибка типа в статически типизированном языке все еще является ошибкой типа в динамически типизированном языке.

• Функции, как правило, предназначены для одновременной работы с одним типом данных, так что функция, которая принимает параметр типа T, может использоваться только с объектами типа T или подклассами T. ].

• Функции, предназначенные для работы со многими различными типами данных, написаны таким образом, что параметры ограничиваются четко определенным интерфейсом. В общих чертах, если два объекта типов A и B выполняют сходную функцию, но не являются подклассами друг друга, то они почти наверняка реализуют один и тот же интерфейс.

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

Динамическая типизация не уменьшает количество кода, которое нужно писать программистам

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

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

Существование семейства языков ML демонстрирует, что мы можем пользоваться преимуществами статической типизации со всей краткостью написания на динамически типизированном языке. Я на самом деле использую REPL OCaml для специальных, одноразовых сценариев точно так же, как все остальные используют Perl или Python в качестве языка сценариев.

Мнение: SQL - это код. Относитесь к нему как к такому

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

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

UML-диаграммы сильно переоценены

Конечно, есть полезные диаграммы, например. Диаграмма классов для Composite Pattern , но многие диаграммы UML не имеют абсолютно никакого значения.

Геттеры и сеттеры сильно злоупотребляют

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

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

ОБНОВЛЕНИЕ:

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

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

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

Многие думают:

private fields + public accessors == encapsulation

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

Наконец, позвольте мне процитировать дядю Боба в этой теме (взято из главы 6 «Чистого кода»):

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

Использование венгерской нотации должно быть наказано смертью.

Это должно быть достаточно спорным;)

Ваша задача - избавиться от работы.

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

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

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

Операторы печати - это правильный способ отладки кода.

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

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

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

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

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

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

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

С другой стороны, я считаю, что люди, которые не имеют У меня был опыт отладки утечек памяти в C / C ++, и я не могу полностью оценить, что Java приносит в таблицу.

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