Удобочитаемость APL

Во-первых, добро пожаловать в удивительный мир APL.

Написание удобочитаемого и поддерживаемого кода APL мало чем отличается от написания удобочитаемого и поддерживаемого кода на любом языке. Любая хорошая книга по написанию чистого кода применима к APL так же, как и к любому другому языку, а может быть, даже в большей степени. Я рекомендую Чистый код Роберта С. Мартина.

Обратите внимание на рекомендации этой книги, что весь код в функции должен быть на одном уровне абстракции. Это относится к APL в 100 раз больше. Например, если у вас есть функция с именем DoThisBigTask, в ней должно быть очень мало примитивных символов APL и уж точно не должно быть длинных сложных однострочников. Это должна быть просто серия вызовов других функций более низкого уровня. Если все эти высокоуровневые функции правильно названы и четко определены, общий дрейф должен быть легко определен тем, кто даже не знаком с APL. Функции самого низкого уровня будут ничем иным, как примитивами и будут непостижимы для не-APLer. В зависимости от того, как они написаны, они могут даже поначалу казаться непонятными опытному специалисту по APL. Однако эти низкоуровневые функции должны быть короткими, не иметь побочных эффектов и могут быть легко переписаны, а не изменены, если поддерживающий программист не может понять исходную технику кодирования.

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

Поскольку вы просили книги и другие ссылки, я могу предложить:

• APL2 in Depth Нормана Д. Томсона и Рэймонда П. Поливки. Я много лет работал с Рэем Поливкой, и он был одним из лучших преподавателей APL, которых я когда-либо знал.
• Классический А. П. Л.: Интерактивный подход Леонарда Гилмана и Аллена Дж. Роуза хорош для базового языка, но он довольно устарел и не содержит многого, что действительно важно для удобства чтения.
• Краткий обзор APL 2, написанный Джеймсом А. Брауном и Сандрой Пакин, в некотором смысле является обновленной версией Гилмана и Роуза. Он охватывает вложенные операции и другие обновления APL, но не особо направлен на удобочитаемость. Тем не менее, если вы будете следовать приведенным здесь примерам, вы будете писать читаемый код.
• APL is Easy от STSC и Jerry R. Turner — это вступление, посвященное линейке APL*Plus. Опять же, не так много конкретно о читабельности, но модели, как правило, представляют собой хорошо спроектированный читаемый код.
• Освоение Dyalog APL: Полное введение в Dyalog APL от Бернара Леграна весьма полезно, если вы работаете только с Dyalog APL, но не так хорошо, если вы работаете с одной из других версий, таких как APL*Plus. (от APL2000)

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

Некоторые советы:

• Написание однострочников — это способ проверить свое мастерство в языке, но это очень плохая практика для производственного кода.
• Прокомментируйте, чтобы сделать алгоритм и особенно используемую структуру данных понятными. Как и в любом коде, комментарии должны добавлять что-то, что не может быть легко прочитано из самого кода, или привлекать внимание к сложному или непонятному коду.
• Если возможно, избегайте неясного кода, чтобы не было необходимости его объяснять. Обычно это возможно.
• Сделайте так, чтобы каждая функция выполняла одну и только одну работу с понятным интерфейсом. По большей части избегайте глобальных переменных и документируйте все, что необходимо.
• Задокументируйте интерфейс, цель и эффект любой функции вверху. Сделайте утилиты черными ящиками без побочных эффектов, если это возможно. Если побочные эффекты важны, задокументируйте их как часть интерфейса. Разработайте стандартную структуру комментариев заголовка.
• Динамический код, создаваемый «на лету», может сделать решение более гибким, но зачастую его намного сложнее отлаживать в случае возникновения проблем. Сделайте такой код пуленепробиваемым, насколько это возможно, и встройте дополнительное ведение журнала, чтобы помочь, когда в любом случае возникнут проблемы.

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

(Я буду использовать здесь «А» вместо комментария, «'» вместо знака символа.)

Ну, я разрабатывал APL в течение года, я использовал только Aplusdev.org.

Вам даже не нужно больше. Хитрость заключается в том, чтобы попытаться мыслить в стиле ООП. У вас должны быть - если я хорошо помню - структурированные поля, используемые как данные класса, такие как {'attribute1 'attribute2, {value,value2}}, чтобы вы могли легко выбрать их, например obj.attribute1 в С++. (здесь атрибут Pick объекта, используйте только в функциях класса:))

Кроме того, используйте функции пространства имен:

namespace_classname.method(this, arg1)
namespace_classname._private_method(this, arg1, arg2)

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

И прежде всего: подумайте о Matlab и Mathematica без циклов for! :) Очень помогает.

Мои предложения для надежного, поддерживаемого кода:

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

• блоки try-catch, есть встроенная обработка исключений, которую можно использовать здесь,

  try_begin();
  Пробный код, возможно, в дополнительных скобках, чтобы не забыть try_end() в конце.

  try_end();
  catch(sth, function_here);

  можно красиво реализовать. (Вы увидите, ловить ошибки очень важно)

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

  function(point2i, ch): {
  typecheck({{'int, [1 2]}, 'char}); Сделайте несколько утверждений в typecheck...
  // ваша функция находится здесь
  }

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

• всегда сообщайте о возврате с пометкой "возврат"!

• Модульные тесты, основанные на try-catch, тестируют каждую написанную вами функцию.

• Я также использовал много 'apply' и 'map' из mathematica, реализуя свою собственную версию, здесь они очень-очень эффективны.

• Я написал Matlab, думая, что здесь вы можете иметь список структурированных полей (=данные класса) в переменной. Вы напишете их много, если захотите оставить вещи без циклов (а вы хотите, поверьте мне). Для этого вам нужно иметь стандартное соглашение об именах, скажем, во множественном числе:

  namespace_class.method(объекты, arg1, arg2)

В заключение: также я написал inputBox и messageBox наподобие тех, что написаны на Javascript или VisualBasic, они очень упростят объединение простых инструментов или проверку состояний. Единственная загвоздка messageBox в том, что он не может приостановить поток функций, поэтому вам нужно

 AA documentation of f1
 f1():
 {
     A  do sth

     msgbox.call("Hi there",{'Ok, {'f2}}); 
 }
 f2():
 {
     A  continue doing stuff
 }

Вы можете написать автодокументы в bash с комбинацией gawk/sed, чтобы поместить их на веб-страницу. Также создание кода в формате HTML помогает при печати. ;)

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