Каким стандартом наилучшей практики / кодирования в отношении этой области является AS3?

Question

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

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

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;
}

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

var foo:String= "bar";

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

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

Answer 4

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

Было бы больше смысла, если бы ваш пример был:

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

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