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

Ответ 1

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

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

• Eval
  медленнее, труднее читать, опасно небезопасно

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

То, что больно больше всего, не могло быть отражением.

Ответ 12

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

Ответ 13

Да.

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

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

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

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

Ответ 14

Я планирую быть в ближайшие недели, когда я переношу Lua в DLR.

Ответ 15

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

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

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

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

Ответ 16

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

Ответ 17

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

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

Ответ 18

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

Ответ 19

В то время как не строго "языковая функция" - одна конструкция, которую я избегаю в С#, это lock(this)

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