Задача по программированию №1

Сообщение от TanaTiX Задача №1 этап №1 Создать приложение размером 600х400 с синим фоном. Загрузить картинку http://www.adobe.com/flashplat... _20x20.jpg Поместить в координаты (10; 10) Рядом написать текст "Hellow, FLASH". Слово FLASH выделить желтым, остальной текст - белым.

кривотота =)

Вложения

дф.zip (9.0 Кб, 71 просмотров)

2

наконец сделал

Вложения

www.rar (17.1 Кб, 15 просмотров)

1

RaiderSk8, как и у jtgvlas в ранних версиях нет резины. И по умолчанию отображается не 1й пункт из списка.
Смотреть на исходники буду на той неделе.

0

RaiderSk8, ау =)

0

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

0

Вот классический пример описания резины. Правда еще на ас2, но не думаю, что портирование вызовет трудности.

ЗЫ. я уже начала писать сочинение на тему ошибок, но ввиду личной занятости, болезни и ЗНАЧИТЕЛЬНОГО объема... Впрочем RaiderSk8 все равно немного задерживается.

0

TanaTiX, RaiderSk8, резина то вроди есть =)

Сообщение от TanaTiX я уже начала

опечатка =D

TanaTiX, жду с нетерпением. и вторую задачу тоже =)

0

Сообщение от jtgvlas опечатка =D

jtgvlas, да.

0

Сообщение от jtgvlas резина то вроди есть

Какая же это резина?

ЗЫ. Что-то и отредактировать не получается как хочется, и сообщения объединить...

Миниатюры

 

0

TanaTiX, аа, у меня просто при тестировании норм было

0

Странно если явно stage.align не задать то при тестировании это свойство стоит одно, а уже в готовой swf другое.

Вложения

www.rar (16.8 Кб, 14 просмотров)

0

RaiderSk8, мб это

0

не stage.align = "LT" по левой и верхней стороне

1

RaiderSk8, а у меня "left" =D

0

jtgvlas, значит у тебя криво

0

Во-первых немного напомню что к чему:
ActionScript является ООП-языком, поэтому при описании допущенных ошибок буду исходить из этого.
Теперь непосредственно по ошибкам. Ошибки сваливаю в общий котел, т.к. зачастую они повторяются, но первые 22 относятся к jtgvlas, думаю RaiderSk8 разберет какие из них относятся и к нему тоже.
RaiderSk8,
jtgvlas
1) Нет смысла использовать старые технологии, если в этом нет явной острой необходимости и/или использование новой технологии не скажется на "популярности" продукта. Это я об ас2. Уже давно подавляющее большинство пользователей способны просматривать флеш-приложение с использованием ФП9 и выше.
2) Используйте точку с запятой. И это не просто стиль программирования, что, конечно же, тоже важно. На моей памяти отсутствие этого символа ломало работу программы - по-видимому компилятор/программа воспринимала участки кода, не разделенные ; как единое целое. В действительности даже не могу точно сказать с чем связана была проблема, но решением было только проставить ;
3) Избыточное использование функционала классов. Т.е. там где достаточно спрайта вы используете мувик. Зачем для рытья земли под картошку пригонять экскаватор? Есть такое понятие - бритва Оккама суть которого в том, что использовать ресурсы нужно рационально с минимально достаточной функциональностью (в применении к программированию), пусть даже речь идет о стандартных классах.
4) Замыкания. На сколько мне известно, в свое время наличие замыканий в других ЯП (языках прогарммирования) преподносилось как фича. Но практика показывает (уже применительно к флеш), что каждый вызов такого метода засоряет память (была где-то тема с обсуждением на флешере с разбором на уровне
байт-кода). Кроме того ухудшается читаемость кода.
5) Пространство имен. Используйте четкое указание для объектов для кого он должен быть видим, для кого нет. По умолчанию если нет указания, то все становится internal. Не буду растекаться по древу - это противоречит принципу инкапсуляции.
6) Используйте константы. Конструкция вида "event.keyCode==192" не должна существовать. Сколько времени было потрачено на определение того, что там именно 192? Если вы покажете свой код кому-то еще, сколько на это потратит времени он? Есть класс Keyboard, содержащий в себе помимо ряда настроек константы для клавиш. К сожалению константа со значением 192 там присутствует только для Air-приложений.
Кроме того если какое-то статичное значение (возможно используемое несколько раз - тогда тем более) вынести в константу, то это гораздо удобней в понимании написанного. Да, вы создадите еще одну переменную, потратите на это процессорное время. Но удобство в дальнейшем может оказаться гораздо более важным. В общем использование констант - хорошая практика по сравнению с "забить 5 значений как есть, потом при необходимости поправлю все 100500 - их не так много".
7) Учите английский, давайте внятные названия переменным, классам, методам. Сам не отличаюсь его хорошим знанием (инглиш), поэтому частенько заглядываю в словари/google translate за переводом.
8) Форматирование кода. Когда в коде несколько условий, переменных и пр. конструкций написаны без пробелов - это очень плохо для восприятия. Adobe выпустили рекомендации по оформлению кода (ссылку не могу найти). Конечно там есть вещи, к которым стоит отнестись критично, но на 99% этот труд заслуживает внимания. Это, кстати, относится и к ;.
9) Чем больше (по количеству кода) и "менее структурирован" метод, тем хуже он в понимании.
10) Импортирование не используемых классов. На работе приложения это никак не скажется, н больше памяти. Есть более чем достойная альтернатива.
12) Мягкие ссылки - это не только рекомендация Adobe по оформлению кода, но и дополнительная страховка при контроле за объектами. Исключениями должны быть ситуации когда нужна жесткая ссылка на объекты при создании слушателей, а не наоборот.
13) Отсутствует типизация у некоторых объектов. Это минус к отладке, к читаемости кода. Это источник, и доволно-таки весомый, потенциальных багов.
14) Если метод что-либо возвращает, это должно быть указано явно.
15) Все нестандартные значения необходимо заносить в константы. При изменении ТЗ не придется лазить по всему классу (проекту?) в поиск всех тех мест, где используется данное значение. А если таких мест много, а значения изначально повторялись для разных параметров - это сразу минус несколько часов.
16) Мне сложно представить такое приложение с необходимостью обновления и рассчетов в каждом кадре на протяжении всей жизни приложения. Если произошло подписывание на ENTER_FRAME, то должно быть и отписывание.
17) Если необходимо получить объект по индексу из массива/вектора более чем 1 раз за время работы метода, то есть смысл выносить такие объекты в приватные переменные, тем самым экономя процессорное время на получение доступа к такому объекту. Это же касается и получения длины массива/вектора.
18) Часто используемые значения есть смысл вынессти в изначально заготовленные переменные/константы, чтобы не производить каждый раз их вычисление.
19) В конечном проекте трэйсы допустимы в крайнем случае. На любом этапе проекта не доопустимы трэйсы вида trace(stage.stageWidth). Они не информативны и засоряют другую служебную информацию. В идеале всю значимую служебную информацию лучше выносить в специальный логгер, чтобы не быть зависимым от версии ФП (дебаг/релиз) и от места запуска приложения (web/standalone)
20) Различные части приложения целесообразно разделять на компоненты/модули: это повысит вероятность повторного использования кода, поспособствует уменьшению времени на разработку. Копипаст применим только к целым классам/модулям, а не отдельным разрозненным кускам кода.
21) По возможности необходимо отделять логику от представления. Если есть возможность что-то нарисовать, то лучше это нарисовать, т.к. при изменении дизайна проще перерисовать руками, чем программно подбирать нужные значения (этто не умаляет того факта, что умение реализовать все программно повышает (до определенного момента) профессиональный уровень разработчика)
22) Класс ImageLoader - это нечто страшное. jtgvlas, выкинь его и никогда не используй.
23) try-catch - не самый лучший варинат при попытке обработать исключение, да еще и там, где его быть не должно по определению.
24) графику лучше разделять по слоям, чтоб при клике по одному объекту не выделялось все содержимое единственного слоя, мешая отладке.
25) Массив содержит в себе не типизированные данные. Если нет возможности использовать вектор, есть смысл использовать приведение типов при работе с массивом для четкого понимания природы программируемого объекта.
26) Классы должны быть настраиваемые из вне. К примеру класс скроллбара имеет ряд значений, которые от проекта к проекту могут меняться. Необходим инттерфейс для возможности изменения этих свойств на лету. Копирование однотипных классов (потенциально класс соответствует) ради изменения пары-тройки свойств - плохая практика.
27) Не вижу смысла импортировать полностью весь пакет ради использования пары классов. На работе приложения это никак не скажется, и есть разные мнения на этот счет.

Мое личное субъективное мнение по этому поводу: импортировать нужно только используемые классы, это может помочь в ориентированию по классу (хотя и притянуто за ушии); импортирование целиком считаю оправданным в случае импорта (и использования) пакета целиком, содержащего кастомные однотипные классы (к примеру, изображения, зашитые в swc)
28) Нет обработки ошибок.


Общее резюме.
Вот прошло достаточно много времени? Сколько времени понадобится для того, чтоб незначительно изменить работу приложения? К примеру поменять левую и правую части местами, изменить цвет заливки и оформление айтемов для загружаемых картинок. Думаю, что при более тщательной организации структуры приложения это бы могло занять в несколько раз меньше времени, чем сейчас. Даже если на этапе разработки на это бы пришлось бы потратить чуть больше времени. Это все равно ускоряет скорость модифицирования проекта. Универсальные классы можно повторно сипользовать в других проектах.
Самое главное. Вот изменил я в проектах только путь к xml, прописав свой (кстати автоматически сгенерировал) и скопилил из-под Flash CS5.5 (оба проекта создавались в IDE), загрузил проекты на 1й попавшийся халявный хостинг и запустил - не работает ни один. Глянуть можно тут (да не сочтут за рекламу) У RaiderSk8 вообще синий экран и никаких телодвижений, а у jtgvlas какое-то мельтешение и последующая некорректная работа.

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


PS. Хочу извиниться за столь долгое отсутствие - навалились дела, совсем не было возможности уделить времени разбору. К тому же времени для этого, учитывая количество ошибок (может даже и пропустил что-то) потребовалось не мало. Зато у участников сейчас будет возможность посмотреть на свои работы со стороны. Спасибо за участие.

3

TanaTiX, ого! спасиба =)

Сообщение от TanaTiX Сколько времени понадобится для того, чтоб..

я провозился час, и забил..

Сообщение от TanaTiX Зато у участников сейчас будет возможность посмотреть на свои работы со стороны.

"я не мог это написать!", "я отказываюсь признавать это своей работой", мысли что то в этом духе =(


TanaTiX, на самом деле большое спасибо

1