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

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

Некоторые из плохих частей:

• eval
  медленнее, сложнее для чтения, опасно insecure

• ==
  запутанный и неоднозначный с операндами разного типа

• с
  непредсказуемыми результатами

Да.

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

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

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

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

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

Больше всего больно было то, что отражение нельзя было использовать!

вы, безусловно, делаете это, когда кодируете код c / c ++ для работы как в Linux, так и в Windows - поэтому вы ограничиваетесь ANSI c / c ++, поэтому я полагаю, что мультиплатформенная поддержка является одной из причин.

другие причины - если вам нужна максимальная совместимость с широко распространенным программным обеспечением / ОС (например, winXP, IE 6.0) - тогда вы нацеливаете свое программное обеспечение на эти приложения / ОС (например, dot net framework 2.0, а не 3.5 и Ie 6, а не ie.8) - для лучшей совместимости со старыми применениями.

То же самое касается совместимости со старым оборудованием / совместимости со старыми графическими устройствами и т. д.

Я избегаю GOTO , который в некоторых кругах считается вредным.

Имеет смысл не использовать функции, которые не понятны вашим соавторам. В C ++ это относится к большей части языка :), но в C # также есть интересные конструкции. Старые языки, такие как Delphi, могут по-прежнему содержать goto. Я стараюсь избегать всех шаблонов и XML, так как считаю их невозможными СУХОЙ

Один из случаев - когда вы пишете компилятор нового языка как такового. Вы можете:

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

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

На самом деле, это просто вопрос дисциплины. Создавая шаблоны HTML / PHP, я ограничиваюсь простейшим возможным подмножеством: условиями и циклами и никакой бизнес-логикой. Нет экземпляра объекта. Нет определений функций. Более сложная логика разделена на другие файлы.

Да, все время.

Потому что я использую Perl, и большинство людей согласны с тем, что многие из наших языковых функций лучше не использовать, если вам это действительно не нужно, и вы знаете, что делаете . Например, символьные ссылки поддерживаются, но вы не должны их использовать. goto существует, но вы не должны его использовать. Вы можете повторно использовать метки переменных в качестве разных типов, например $ var , @var , % var , но вам тоже не следует этого делать. Вы не можете использовать strict , чтобы необъявленные переменные автоматически становились записями таблицы символов, но вы действительно не должны этого делать.

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

Я люблю говорить TMTOWTDI, BMOTWAW; Есть несколько способов сделать это, но большинство из них неверны.

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

В .NET у нас есть приложение, которое ДОЛЖНО работать в Windows 98, поэтому мы ограничены рамками 2.0, так как более новые версии не работают на этой ОС .. Это просто печально. Невозможно использовать LINQ, методы расширений и прочее.

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

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

Lotus IBM представила метод getAllEntriesByKey класса NotesView в LotusScript R5, я начал использовать его по незнанию всего пару лет назад, теперь это основная часть моего программирования в качестве альтернативы getAllDocumentsByKey.

В getAllDocumentsByKey нет ничего плохого, и я использую его постоянно, но если в просмотре, на который вы смотрите, есть сотни или даже тысячи записей (документы для разработчиков Notes), то сканирование возвращаемой вами коллекции может быть очень медленным. Если, однако, значение документа - это запись в столбце представления, то сканирование viewEntryCollection, которое вы получаете от getAllEntriuesByKey, происходит намного быстрее, не делает старый код неправильным или даже непригодным для использования, вам просто нужно знать, когда использовать каждый из них.

На прошлой неделе я перекодировал процесс, который должен был проходить через коллекцию, которая, как оказалось, могла содержать от 0 до 22 000 записей, для 200 записей потребовалось 60 секунд для запуска. Новый код завершился за 2 секунды (я добавил временный код времени) и, что более важно, столько же времени потребовалось для 500 документов, это большая победа за десять минут работы, включая модульное тестирование. Этот метод был доступен разработчикам много лет назад, когда они писали подпункт, но они либо не знали об этом, либо, что более вероятно, не были уверены / не понимали последствий для производительности.

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

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

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

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

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

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

Много раз. Основная причина для меня - кроссплатформенность. Примеры:

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

2) использование исключений / rtti для c ++ - a нет-нет, если вы ориентируетесь на встроенную платформу, а также на настольную платформу (отказ от ответственности - не делал ничего из этого годами, так что, возможно, сейчас это более приемлемо, хотя я в этом сомневаюсь)

3) Удаленное взаимодействие .NET, если вы пишем приложение для рабочего стола .NET и WinCE - сейчас большая головная боль: - (

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

Последний раз, когда я помню, как сознательно писал на языке подмножества, был еще в 80-х, когда большинство моих целевых платформ поддерживали FORTRAN 77, но один не работал должным образом, поэтому мне пришлось писать на гибриде FORTRAN 77 / FORTRAN IV. Это было больно - в последние годы дела пошли намного лучше, в основном благодаря движению FOSS.

I plan to be in the upcoming weeks as I port Lua over to the DLR.

В Verilog и VHDL (языках программирования, используемых для разработки микросхем) мы всегда должны использовать подмножества, которые можно «синтезировать» при разработке микросхемы. Весь язык может использоваться для стендов тестирования (модульных тестов).

Мы активно используем XSLT для многих наших компонентов. Большинство компонентов старые) использует старые парсеры, которые не поддерживают XSLT 2.0, поэтому мы все еще используем функции XSLT 1.0, хотя XSLT 2.0 предоставляет много хороших функций.

Хотя это и не строго «языковая функция», одна конструкция, которую я избегаю в C #, - это lock (this)

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