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

Ассемблер не мертв

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

Также многие оптимизации кода возможны только с помощью программирования на ассемблере, посмотрите исходники любых видеокодеков, исходники написаны на ассемблере и оптимизированы для использования MMX / SSE / SSE2 кодирует что угодно, многие игровые движки используют процедуры, оптимизированные для ассемблера, даже ядро ​​Windows имеет процедуры, оптимизированные для SSE:

NTDLL.RtlMoveMemory

.text:7C902CD8                 push    ebp
.text:7C902CD9                 mov     ebp, esp
.text:7C902CDB                 push    esi
.text:7C902CDC                 push    edi
.text:7C902CDD                 push    ebx
.text:7C902CDE                 mov     esi, [ebp+0Ch]
.text:7C902CE1                 mov     edi, [ebp+8]
.text:7C902CE4                 mov     ecx, [ebp+10h]
.text:7C902CE7                 mov     eax, [esi]
.text:7C902CE9                 cld
.text:7C902CEA                 mov     edx, ecx
.text:7C902CEC                 and     ecx, 3Fh
.text:7C902CEF                 shr     edx, 6
.text:7C902CF2                 jz      loc_7C902EF2
.text:7C902CF8                 dec     edx
.text:7C902CF9                 jz      loc_7C902E77
.text:7C902CFF                 prefetchnta byte ptr [esi-80h]
.text:7C902D03                 dec     edx
.text:7C902D04                 jz      loc_7C902E03
.text:7C902D0A                 prefetchnta byte ptr [esi-40h]
.text:7C902D0E                 dec     edx
.text:7C902D0F                 jz      short loc_7C902D8F
.text:7C902D11
.text:7C902D11 loc_7C902D11:                           ; CODE XREF: .text:7C902D8Dj
.text:7C902D11                 prefetchnta byte ptr [esi+100h]
.text:7C902D18                 mov     eax, [esi]
.text:7C902D1A                 mov     ebx, [esi+4]
.text:7C902D1D                 movnti  [edi], eax
.text:7C902D20                 movnti  [edi+4], ebx
.text:7C902D24                 mov     eax, [esi+8]
.text:7C902D27                 mov     ebx, [esi+0Ch]
.text:7C902D2A                 movnti  [edi+8], eax
.text:7C902D2E                 movnti  [edi+0Ch], ebx
.text:7C902D32                 mov     eax, [esi+10h]
.text:7C902D35                 mov     ebx, [esi+14h]
.text:7C902D38                 movnti  [edi+10h], eax

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

Написав это самостоятельно, можно

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

Но зачем вам кодировать свою собственную версию?

• Не изобретайте велосипед. Но если вам нужен только кусок дерева, действительно ли вам нужно целое колесо телеги? Другими словами, вам действительно нужен openCV, чтобы перевернуть изображение по оси?
• Компромисс. Обычно вам приходится идти на компромиссы в отношении вашего дизайна, чтобы иметь возможность использовать определенную библиотеку. Стоит ли количество изменений, которые вы должны внести, получить функциональность, которую вы получите?
• Обучение. Вы должны научиться использовать эти новые фреймворки и модули. Сколько времени это займет у вас? Это того стоит? Будет ли учиться дольше, чем внедрять?
• Стоимость. Не все бесплатно. Хотя сюда входит и ваше время. Подумайте, сколько времени это программное обеспечение, которое вы собираетесь использовать, сэкономит вам, и стоит ли оно своей цены? (Также помните, что вам нужно потратить время, чтобы изучить это)
• Вы программист, а не ... человек, который просто складывает вещи вместе (извините, не мог придумать ничего остроумного).

Последний пункт спорен.

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

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

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

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

Последний пункт спорен.

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

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

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

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

Последний пункт спорен.

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

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

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

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

Последний пункт спорен.

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

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

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

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

Последний пункт спорен.

Сколько времени это займет у вас? Это того стоит? Будет ли учиться дольше, чем внедрять?

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

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

Последний пункт спорен.

Сколько времени это займет у вас? Это того стоит? Будет ли учиться дольше, чем внедрять?

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

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

Последний пункт спорен.

человек, который просто складывает вещи вместе (извините, ничего остроумного не придумал).

Последний пункт спорен.

человек, который просто складывает вещи вместе (извините, ничего остроумного не придумал).

Последний пункт спорен.

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

... когда мы (надеюсь) получим их, то есть. Базы данных SQL - отстой настолько, что это не смешно.

Что меня забавляет (если грустно), так это сертифицированные администраторы баз данных , которые считают систему баз данных SQL реляционной. Много говорит о качестве указанной сертификации.

Смущает? Прочтите книги CJ Date.

edit

Почему он называется Relational и что означает это слово?

В наши дни программист (или сертифицированный администратор базы данных, ] ]) с сильным (черт возьми, any ) математическим фоном является скорее исключением, чем обычным случаем (я также являюсь примером общего случая). SQL с его таблицами , столбцами и строками , а также шутка под названием «Моделирование сущности / взаимоотношений» только добавляют оскорбления к травме. Неудивительно, что заблуждение о том, что системы реляционных баз данных называются так из-за некоторых отношений (внешних ключей?) Между сущностями (таблицами), настолько широко распространено.

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

[ http://en.wikipedia.org/wiki/Finitary_relation] [2] :

В математике (точнее, в теории множеств и логике) отношение - это свойство, которое присваивает значения истинности комбинациям ( k наборов) из k индивидуумов. Обычно свойство описывает возможное соединение между компонентами k -набора. Для заданного набора из k -элементов значение истинности присваивается каждому k -набору в зависимости от того, выполняется это свойство или нет.

Пример троичного набора. отношение (например, между тремя людьми): « X был введен в Y Z », где (X, Y, Z) - 3-кратный набор лиц; например, «Беатрис Вуд была представлена ​​Анри-Пьеру Роше Марселем Дюшаном» его второй элемент из s2 и так далее. (Эквивалентно r является подмножеством декартова произведения s1 x s2 x ... x sn .)

Установить si - это i -й домен для r ( i = 1, ..., n ). Примечание : Есть несколько важных логических различий между отношениями в математике и их аналогами в реляционных моделях. Вот некоторые из них:

• Математические отношения упорядочены по своим атрибутам слева направо.
• На самом деле математические отношения в любом случае имеют в лучшем случае лишь очень элементарную концепцию атрибутов. Конечно, их атрибуты не называются иначе, чем по порядковому номеру.
• Как следствие, математические отношения не имеют У t действительно есть либо заголовок, либо тип в смысле реляционной модели.
• Математические отношения обычно либо бинарные, либо, иногда, унарные. Напротив, отношения в реляционной модели имеют степень n , где n может быть любым неотрицательным целым числом.
• Операторы отношения, такие как JOIN, EXTEND и остальные, были сначала определены в частности, в контексте реляционной модели; математическая теория отношений включает в себя несколько таких операторов.

И так далее (приведенный выше список не является исчерпывающим).

...That the "clarification of ideas" should not be the sole responsibility of the developer...and yes xkcd made me use that specific phrase...

To often we are handed project's that are specified in psuedo-meta-sorta-kinda-specific "code" if you want to call it that. There are often product managers who draw up the initial requiements for a project and perform next to 0% of basic logic validation.

I'm not saying that the technical approach shouldn't be drawn up by the architect, or that the speicifc implemntation shouldn't be the responsibility of the developer, but rather that it should the requirement of the product manager to ensure that their requirements are logically feasible.

Personally I've been involved in too many "simple" projects that encounter a little scope creep here and there and then come across a "small" change or feature addition which contradicts previous requirements--whether implicitly or explicitly. In these cases it is all too easy for the person requesting the borderline-impossible change to become enraged that developers can't make their dream a reality.

switch-case не является объектно-ориентированным программированием

Я часто вижу много switch-case или ужасно больших конструкций if-else. Это просто знак того, что состояние не помещается туда, где оно принадлежит, и не используется реальная и эффективная конструкция switch-case, которая уже существует: поиск метода / vtable

Программисты не должны прикасаться к Word (или PowerPoint)

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

Сгенерированные файлы XML представляют собой двоичные капли

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

Когда возникает необходимость в создании документа для непрограммистов,

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

Хорошо, здесь собрана пара идей:

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

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

Анонимные функции - отстой.

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

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

Never change what is not broken.

Если вы когда-либо позволяли кому-либо с rentacoder.com прикоснуться к вашему проекту, и он, и ваш бизнес совершенно бесполезны.

У меня два:

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

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

Есть только один шаблон проектирования: инкапсуляция

Например:

• Заводской метод: вы инкапсулировали создание объекта
• Стратегия: вы инкапсулировали различные изменяемые алгоритмы
• Итератор : вы инкапсулировали способ последовательного доступа к элементам в коллекции.

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

Java - это COBOL нашего поколения.

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

Макросы , Инструкции препроцессора и Аннотации - зло.

Один синтаксис и язык для каждого файла, пожалуйста!

// не применяется к файлам Make или макросам редактора, которые вставляют реальный код.

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

Разработка - это 80% дизайна и 20% кодирования

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

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