2009-03-06 5 views
1

Каков стандарт лучшей практики/кодирования в отношении «этой» области AS3? Есть ли это? Я чувствую, что это действительно помогает при стандартизации и моей читабельности, но иногда это кажется «слишком много».Какова наилучшая практика/стандарт кодирования в отношении «этой» области AS3?

Например, это использование «это» в следующем действительно необходимо (я знаю, что он работает без «этого») ?:

private var _item:Object; 

private var selectedItem:Object; 

public function set item(value:Object):void 
{ 
    this._item = value; 

    if (this._item["label"] == "doodad") 
     this.selectedItem = value; 
} 

public function set item(value:Object):void 
{ 
    return this._item; 
} 

ответ

3

«это» не требуется, если вы не хотите препятствовать именованию конфликтов между локальными облачными переменными (параметры метода для примера) и переменными экземпляра.

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

+0

Да, я очень решил не использовать «это», потому что он только ПОНИМАЕТ разработчикам повторно использовать имена переменных по областям, что само по себе является плохой практикой. –

1

Это, конечно, не нужно, но я согласен, что это может помочь с удобочитаемостью. Поскольку я больше работаю на более динамичных языках (например, Perl и Python), такие соглашения могут быть жизненно важными для быстрого определения того, где находятся переменные и функции. Если это соглашение работает для вас, я не думаю, что это плохо, само по себе.

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

Например: один человек, которого я работал с автором всех заданий, как это:

var foo:String= "bar"; 

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

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

1

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

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

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

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

+0

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

0

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

бы больше смысла, если ваш пример был (вероятно, худший повод, чтобы сделать это!):

public function set item(_item:Object):void 
{ 
    this._item = _item; 

    if (this._item["label"] == "doodad") 
     this.selectedItem = this._item; 
} 
+0

Я использую Flex Builder 3 в основном и просто использую CTRL + SPACE для автозаполнения. Не уверен, как это работает с плагином Eclipse. –

+0

Да, нашел это на днях! – Iain

Смежные вопросы