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

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

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

Но на практике никто не программирует на чисто функциональных языках. (Ребята из Haskell будут подпрыгивать, когда увидят это, но серьезно, Haskell используется крайне редко).

Анализируемым язык программирования делает инфраструктура, предназначенная для поддержки анализа. ASIS Ады, приведенный выше, является отличным примером. Не смущайте тот факт, что ASIS был написан для Ada или написан на Ada; важно то, что кто-то серьезный хотел проанализировать Ada и вложил усилия в создание механизма анализа Ada.

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

В результате получился движок, который я считаю идеальным для анализа, рефакторинга, реинжиниринга и т.д.: наш DMS Software Engineering Toolkit. .

Он имеет общий синтаксический анализ, построение дерева, красивую печать, манипуляции с деревом, переписывание источника в источник, оценку грамматики атрибутов, управление и анализ потока данных. Он имеет качественный интерфейс для ряда широко используемых диалектов C и C ++, для Java, C #, COBOL и PHP, и даже для Verilog и VHDL (многие другие языки тоже, но не совсем того уровня).

Чтобы дать вам некоторое представление о его полезности, он использовался для преобразования кода JOVIAL для бомбардировщика B-2 в C ... без того, чтобы мы никогда не видели исходный код. См. http://www.semdesigns.com/Products/Services/NorthropGrummanB2.html

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

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

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

Существует парадигма разделения языка «код - это данные». Например. каждая строка кода - это просто данные в терминах этого языка. Это делает рефакторинг таким же основным действием, как и простые операции с данными. И название этого языка - Лисп. ;)

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

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

Для рефакторинга: самоподобие

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

• Извлеките фрагмент C ++ в новую процедуру, используя ссылочные параметры, чтобы предоставить ей доступ для изменения переменных.
• Методы Python, Javascript и Lua - это просто функции с параметром self. *
• В любом количестве языков функция, которая создает / заполняет структуру, может быть (более или менее тривиально) преобразована в конструктор.

Контрпримеры ...

• Ruby (модули, классы), методы лямбда-блока и необработанные блоки: различия в семантике, мягко говоря, сбивают с толку. (это все, что я могу сказать наверняка.)

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

* Python почти похож на это. (Я забыл, в чем проблема. Возможно, что-то с этим связано, если метод был определен в классе или привит во время выполнения.)

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

x++ = x++ + ++x;

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

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