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

почти в во всех случаях комментарии являются злыми: http://gooddeveloper.wordpress.com/

Процедурное программирование - это весело. ООП скучно.

Мое противоречивое мнение, вероятно, заключается в том, что Джон Кармак (ID Software, Quake и т. Д.) Не очень хороший программист.

Не поймите меня неправильно, по моему мнению, он умный программист, но после того, как я заметил строку «#define private public» в исходном коде Quake, я не мог не помочь думаю, что он парень, который выполняет свою работу, неважно, что, но, по моему определению, не хороший программист :) Это мнение вызвало у меня много горячих дискуссий;)

Ревностное соблюдение стандартов стоит на пути простоты.

MVC завышен для веб-сайтов. В основном это просто ВК, иногда М.

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

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

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

правдоподобным? Не для большинства. Правда? Совершенно верно.

Программисты гораздо более осуждающие, чем необходимо.

Свидетельствуйте все, что считается «злым» или «ужасным» на этих постах.

Программисты довольны структурой данных.

Засвидетельствуйте все обсуждения классов, наследования, private-vs-public, управления памятью и т. Д. Против того, как анализировать требования.

Программное обеспечение с открытым исходным кодом стоит дороже в долгосрочной перспективе

Для обычных компаний, занимающихся линейным бизнесом, Open Source выглядит бесплатно, но имеет скрытые затраты.

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

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

Использование Stored Proc прост в обслуживании и требует меньшего количества развертывания против Использование ORM - это ОО способ, поэтому это хорошо

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

Дефекты и запросы на улучшение одинаковы

Если вы не разрабатываете программное обеспечение по контракту с фиксированной ценой, не должно быть никакой разницы при расстановке приоритетов в вашем бэлоге между «ошибками» и «улучшениями» и «новой функцией» Запросы. OK - возможно, это не спорное, но я работал на предприятии ИТ-проектов, где эдикт был то, что «все открытые ошибки должны быть исправлены в следующей версии», даже если это не оставляло времени для разработчиков наиболее желательных новых функций. Таким образом, проблема, с которой сталкиваются 1% пользователей, 1% времени имеет преимущество перед новой функцией, может быть немедленно полезна для 90% пользователей. Мне нравится собирать весь свой портфель проектов, оценивать каждый элемент и отдавать его сообществу пользователей для определения приоритетов - с элементами, не классифицированными как «дефект», «улучшение» и т. Д.

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

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

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

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

Удалить копию & amp; Вставьте из ВСЕХ программных IDE . Копировать и вставленный код очень плох, эта опция должна быть полностью удалена. Тогда программист, надеюсь, будет слишком ленив, чтобы перепечатать весь код, поэтому он создает функцию и повторно использует код.

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

Если его не стоит тестировать, его не стоит строить

Блокнот - прекрасный текстовый редактор. (И иногда WordPad для разрывов строк, отличных от Windows)

• Редактирование файлов конфигурации
• Просмотр файлов журналов
• Разработка

Я знаю людей, которые действительно верят в это! Однако они будут использовать IDE для разработки, но продолжат использовать Блокнот для всего остального!

Тернарные операторы абсолютно отстой. Они являются воплощением ленивых задниц программирования.

user->isLoggedIn() ? user->update() : user->askLogin();

Это так легко облажаться. Небольшое изменение в редакции № 2:

user->isLoggedIn() && user->isNotNew(time()) ? user->update() : user->askLogin();

О да, просто еще одно «небольшое изменение».

user->isLoggedIn() && user->isNotNew(time()) ? user->update() 
    : user->noCredentials() ? user->askSignup
        : user->askLogin();

О, дерьмо, как насчет ДРУГОГО случая?

user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned() ? user->update() 
    : user->noCredentials() || !user->isBanned() ? user->askSignup()
        : user->askLogin();

НЕТ НЕТ НЕТ НЕТ. Просто сохраните нам изменение кода. Перестаньте быть ленивым:

if (user->isLoggedIn()) {
    user->update()
} else {
    user->askLogin();
}

Поскольку правильное выполнение в первый раз избавит нас от необходимости конвертировать ваши дерьмовые троицы снова и снова:

if (user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned()) {
    user->update()
} else {
    if (user->noCredentials() || !user->isBanned()) {
        user->askSignup();
    } else {
        user->askLogin();
    }
}

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

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

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

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

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

Никто не заботится о вашем коде

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

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

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

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

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

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

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

HTML 5 + JavaScript будет наиболее используемой платформой для пользовательского интерфейса в будущем. Flash, Silverlight, Java-апплеты и т. Д. И т. Д. Все умрут безмолвной смертью

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

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

Программы на 4GL в целом труднее писать, труднее читать и труднее оптимизировать, чем.

4GL следует избегать, насколько это возможно.

Программистам необходимо общаться с клиентами

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

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

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

Комментировать плохо

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

Все руководители проектов должны иметь задачи по кодированию

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

Delphi - это весело

Да, я знаю, что он устарел, но Delphi был и остается очень интересным инструментом для разработки.

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

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

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

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

«Программисты должны заниматься программированием на стороне, или они никогда не так хороши, как те, кто это делает».

Как сказал kpollock, представьте, что вы говорите это врачам или солдатам. ..

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

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

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

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

Linq2Sql не так уж и плох

Я сталкивался с большим количеством сообщений, разбивающих Linq2Sql. Я знаю, что он не идеален, но что это?

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

Variable_Names_With_Bloody_Underscores

или даже хуже

CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES

должны быть полностью опровергнуты! CamelCapsAreJustFine. (Глобальные константы не выдерживают)

Операторы GOTO предназначены для использования разработчиками в возрасте до 11 лет

Любой язык, не поддерживающий указатели, не достоин названия

. Net = .Bloat Лучший пример усилий Microsoft по разработке веб-сайтов (Expressionless Web 2) - это лучший пример медленного раздутого cr @ pw @ re когда-либо написанного. (вместо этого попробуйте Web Studio)

Ответ: Хорошо, позвольте мне немного затронуть проблему Underscore. Из ссылки C вы указали:

-Глобальные константы должны быть заглавными буквами с разделителями '_'. Я на самом деле согласен с этим, потому что это BLOODY_OBVIOUS

- возьмем, например, NetworkABCKey. Обратите внимание, как перепутаны C из ABC и K из ключа. Некоторые люди не возражают против этого, а другие просто ненавидят это, поэтому вы найдете разные политики в другом коде, чтобы вы никогда не знали, как что-то вызвать.

Я подпадаю под первую категорию. Я выбираю имена ОЧЕНЬ тщательно, и если вы не можете сразу понять, что K принадлежит Key, то, вероятно, английский не ваш родной язык.

• Имена функций C

  • В проекте C ++ должно быть очень мало функций C.
  • Для функций C используйте соглашение GNU для всех строчных букв с «_» в качестве разделителя слов.

Обоснование

* It makes C functions very different from any C++ related names. 

Пример

int some_bloody_function () {}

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

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

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

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