Общий вопрос про повторные определения

[am_devcorp]

Вот допустим, есть у нас код.

switch (dir) {
                case TOP:
                    var i:int = 0
                    for (var j:int = 0; j < pics[0].length; j++) {
                        что-то делаем с pics[i][j]
                    }
                    break;
 
                case RIGHT:
                    var j:int = pics[0].length - 1
                    for (var i:int = 0; i < pics.length; i++) {
                        что-то делаем с pics[i][j]
                    }
 
                    break;
                case BOT:
                    var i:int = pics.length - 1
                    for (var j:int = 0; j < pics[0].length; j++) {
                        что-то делаем с pics[i][j]
                    }
                    break;
                case LEFT:
                    var j:int = 0
                    for (var i:int = 0; i < pics.length; i++) {
                        что-то делаем с pics[i][j]
                    }
                    break;
                default:
            }

т.е. мы в зависимости от dir по разному проходим по матрице.
Вообще подробности не важны, может мы несколько раз по разному проходимся по матрице, не суть, главное, что подряд идут несколько похожих по смыслу циклов с i и опционально j. В таком случае компилятор сыпет в консоль ворнинги duplicate variable definition. Но щит, Шерлок, это я и сам вижу, но как лучше от них избавляться?

Вариант 1) Забить, но это несолидно, когда проект собирается не молча.
Вариант 2) В начале объявить эти злосчастные i и j и убрать объявления. Но может это мои тараканы мне это тоже не нравится, ибо это вроде как повторное использование переменной в другом месте, что не есть хорошо.

Есть ли какие-нибудь еще кроме (2) практики исправления таких ситуаций?

[Akopalipsis]

Только один вариант - обьявить i перед заходом в switch
Можно i=0 вообще убрать из цикла, но так будет не красиво.
Немного я упустил Ваш код)) ещё j добавить и делать в таком же духе.

Добавлено через 2 минуты

var i:int;
var j:int;
switch (dir) {
                case TOP:
                    for (i=0; i < pics[0].length; j++) {
                        что-то делаем с pics[i][j]
                    }
                    break;
 
                case RIGHT:
                    for (i=0; i < pics.length; i++) {
                        что-то делаем с pics[i][j]
                    }
 
                    break;
                case BOT:
                    for (i=0; i < pics[0].length; j++) {
                        что-то делаем с pics[i][j]
                    }
                    break;
                case LEFT:
                    for (i=0; i < pics.length; i++) {
                        что-то делаем с pics[i][j]
                    }
                    break;
                default:
            }

[Bletraut]

Объявить в самом начали, а потом уже присваивать им значения?

[Babylon]

правильнее всё таки писать var в цикле.

Добавлено через 33 секунды
Bletraut, да дурдом

[Akopalipsis]

Bletraut, да дурдом

А почему инициализация вне цикла - дурдом?

[Babylon]

Какой в ней смысл? переменная, что где-то перед циклом используется?

[КорДум]

Ну и, если на то пошло, обращение к геттеру length происходит каждый виток цикла, кэшируйте значение. Конструкция вида "i < pics[0].length" плоха еще тем, что нулевой элемент берется тоже каждую итерацию. Кэшировать нужно и это.

[Akopalipsis]

Какой в ней смысл? переменная, что где-то перед циклом используется?

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

var i:int;
for (i = 0; i < 10; i++) 
{
	trace(i);
}
for (i = 0; i < 10; i++) 
{
	trace(i);
}

[КорДум]

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

[expl]

Вариант 1) Забить, но это несолидно, когда проект собирается не молча.

Вынести объявления вверх как общие и смириться
Если смириться тяжело - в опциях mxmlc есть галочка - не выдавать ворнинги про дублирование переменных (проверять порядок объявления и область видимости, правда, компилятор не будет что так, что так - просто флудить не будет)
Насколько опасно отключать? Ну случалось, внутри блока объявлял переменную, думая что её нет снаружи и узнавал это из ворнинга.
С другой стороны отключать/не отключать - это мёртвому припарки. Когда у тебя половину переменных надо искать на полэкрана выше и не понятно где ты их собирался использовать, а где - нет, и когда компилятор даже не проверяет, объявлена ли переменная до её использования.

Сильный аргумент _не_ отключать: не пугать людей, которые так или иначе будут компилировать ваш код - по умолчанию то предупреждения включены

Вариант 2) В начале объявить эти злосчастные i и j и убрать объявления. Но может это мои тараканы мне это тоже не нравится, ибо это вроде как повторное использование переменной в другом месте, что не есть хорошо.

Вы правы, это отвратительно, и такое поведение в стандарт ECMA вписал какой-то негодяй
Но есть хорошая новость: во многих других языках область видимости переменных ограничена блоком, а не методом (Java, C#, haXe, F#, Ocaml, C++)