Общая практика кодирования - должен ли я использовать больше кода или больше переменных? (Flash AS3 или вообще)

Question

All

Я программист-самоучка, а не выпускник CS, поэтому существуют сотни лучших практик кодирования, которые я, вероятно, регулярно игнорирую.

Во всяком случае, вот общий вопрос ...

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

Это неопределенный вопрос, но вот конкретный "например ..."

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

(Подумайте о точках внизу ваших домашних экранов на вашем iPhone, которые позволяют переключать экраны, или навигацию по переключателю изображений на этой странице: http://www.apple.com/ipad/)

В любом случае, я реализовал этот «элемент управления точечной навигацией» как пользовательский подкласс Sprite. Когда пользователь щелкает точку, класс отправляет пользовательскому событию пользовательское событие, которое содержит значение индекса (uint), которое соответствует нажатой точке (например, «0» является первой точкой, «n-1» является n-й точкой ).

Теперь, в слушателе, мне нужно принять меры - переместить пользователя на соответствующую страницу. Итак, один очевидный вариант:

private function dotClicked(e:customDotEvent):void {
    // e.target.index contains the index of the dot clicked
    switch (e.target.index) {
        case 0:
            // navigate the user to the screen that corresponds to dot 0
            loadScreen("home");
            ....
            break;
        case 1:
            // navigate the user to the screen that corresponds to dot 1
            loadScreen("about");
            ....
            break;
        ....
        case n:
            // navigate the user to the screen that corresponds to dot n
            loadScreen("etc");
            ....
            break;
    }

В этом примере - у меня довольно подробная функция переключения, которая выполняет работу.

Менее многословный вариант:

private function dotClicked(e:customDotEvent):void {
    var screens:Array = ["home","about","blog",...,"etc"];
    // e.target.index contains the index of the dot clicked
    loadScreen(screens[e.target.index]);
}

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

(Очевидно, что, вероятно, есть и множество лучших альтернатив, но, надеюсь, это иллюстрирует мой вопрос ...).

Итак, что лучше для производительности, уменьшения общего объема памяти приложения и т. Д.?

В этом простом примере разница, вероятно, тривиальна. Но может ли это сложиться в большом приложении?

Лучше ли Flash (или другие платформы) обрабатывать больше кода или больше переменных?

Стоит ли беспокоиться об этом, или я должен просто беспокоиться о написании кода, который легче поддерживать и отлаживать?

Заранее большое спасибо!

Answer 1

Я думаю, вам следует в первую очередь беспокоиться о создании кода, который проще поддерживать и отлаживать. Если ваше приложение работает медленно, тогда сделайте оптимизацию. Моя стратегия состоит в том, чтобы оптимизировать только код, который будет много работать. Прослушиватель событий для кнопки может выполняться за 0,001 с или 0,01 с, это не имеет значения. Но если сложный код выполняется в каждом кадре, оптимизируйте его.
При использовании кода ActionScript скорость выполнения даже менее важна, поскольку рендеринг потребляет гораздо больше процессорных циклов, чем обычно алгоритмы (если вы не пишете какое-либо приложение, которое выполняет только огромные математические вычисления). Например:

for (var i:int=0;i<500;i++){
    Math.sin(Math.random());
}

менее ресурсоемкий, чем

graphics.lineTo(300,300);   

Так что, если вы хотите оптимизировать, начните с графики.

Answer 2

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

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

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

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

private function dotClicked(e:customDotEvent):void {
    // e.target.location contains the target location of the dot clicked, e.g. "home", "about", "etc"
    loadScreen(e.target.location);
}

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

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

Удачи.

Answer 3

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

Хотя это не всегда так, в большинстве случаев существует довольно хорошая корреляция между тем, сколькострок кода и сколько работы вы должны сделать, чтобы справиться с этим.Глупо быть настолько сжатым, что становится трудно читать код, но это становится действительно проблемой, когда вы доберетесь до уровня сокращения строки с 14 символов до 13.

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

Answer 4

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

Например, если у вас есть класс Locations, подобный этому:

public class Locations
{
    public static const HOME:int = 0;
    public static const ABOUT:int = 1;
    public static const ETC:int = 2;
    ...
}

так что теперь ваш switch становится:

switch (e.target.index) 
{
    case Locations.HOME:
        // navigate the user to the screen that corresponds to dot 0
        loadScreen("home");
        ....
        break;
    case Locations.ABOUT:
        // navigate the user to the screen that corresponds to dot 1
        loadScreen("about");
        ....
        break;
    ....
}

Намного легче читать, и если вы хотите изменить его, вы делаете все это в одной области (Locations.as), а не по всему коду

Answer 5

Для вашего примера, вы правы, что с несколькими экранами не будет никакой разницы в производительности.Если бы у вас было много-много возможных расположений экранов для сопоставления точек, имело бы смысл дать им постоянные целочисленные идентификаторы вместо строк, чтобы сэкономить память, и использовать ваш второй подход (массив или вектор).Я считаю, что компилятор AS3 превращает операторы switch в большую кучу условных выражений (if, else if cascade), так что это не идеально для производительности и не имеет большой экономии размера.

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