Сопоставление с образцом

[Geniepro]

Да кто спорит, что нельзя, конечно можно, но вот нужно ли всегда? Потому что в итоге может получиться не менее монструозная конструкция.

Из моих 12 лет в программировании 5 я писал, не заморачиваясь и не зная про "правильные циклы". (И про Оберон тоже).
for и break для поиска - да как делать нечего.

До сих пор использую for для поиска, но всё же стараюсь без break... Что-то типа:

Код: [Выделить]

bool found = false;
for (int i = 0; i < list->Count() && !found; i++)
{
    if (list->Items[i] == xxx)
    {
        elem  = list->Items[i];
        found = true;
    }
}

if (found)
{
    ......
}(В VCL есть список TList, который элементы списка хранит в массиве, там доступ к элементам массива по индексу быстрый...)

Быстро-быстро нагавнякал -- работает и ладно )))

[vlad]

Быстро-быстро нагавнякал -- работает и ладно )))

Не, это не труЪ цикл. Илья как раз упоминал это - убрать break мало, надо чтоб все было в условии цикла, без всяких костыльных переменных. Ну и последующая проверка по второму разу.

[Geniepro]

Вот так что ли:

Код: [Выделить]

for (int i = 0; (i < list->Count()) && (list->Items[i] != xxx); i++) {}
if (list->Items[i] == xxx)
{
    ......
} ?
Вроде компактнее выходит...
А если проверка тяжёлая? Как по вычислениям, так и по дополнительным действиям?

[Berserker]

Типичный while. А тяжёлая проверка уходит в подпрограмму.

Код: (C) [Выделить]

i = 0;

while ((i < list->Count()) && (list->Items[i] != xxx))
{
  i++;
}

if (i < list.Count())
{
  printf('yep');
}

[vlad]

Вроде компактнее выходит...
А если проверка тяжёлая? Как по вычислениям, так и по дополнительным действиям?

Она тяжелая для моих глазок Хотя в сгенерированном коде там тоже все грустно будет.

[ilovb]

2. Разработчик и постановщик задачи одно лицо. Когда тебе ставит задачу другой человек (обычно не знающий программирования), то сложность возрастает на порядки.
3. Практически отсутствует сопротивление среды (требования не меняются каждый день; нет нужды реагировать на вопли пользователей)

т.е. Оберон не считается, т.к. это тепличное растение.

Это не имеет отношения к Оберону, это особенности прикладной автоматизации... Хорошо известные.
Если автоматизатор - крупная компания, то она часто выделяет подразделение, которое занимается программированием "общего знаменателя" для своих проектов (библиотек, инструментов). И у этого подразделения будут тоже "тепличные условия".

А Оберон что вещь в себе? От кодеров для кодеров?
Хотя... наверно так и есть... (вот кстати почему она однопользовательская?)

Не будет там тепличных условий. Постановщик и разработчик один фиг будет о двух лицах практически в любой прикладной задаче. Чтобы закодить "общий знаменатель" нужен специалист по данной прикладной области, который и будет постановщиком задачи. (ну или нужно идти по пути alexus'a и вкуривать прикладуху самому..., а на это нужно дохера времени, коего в реальных задачах всегда мало)

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

А про циклы - какие там нах супер-формальные методы, коллега? Написать цикл аккуратно без выхода из середины - это супер-сложно? Легче наклепать и иметь 20% брака?

А чтобы написать цикл аккуратно нужно расписывать инварианты и доказывать правильность?
Вот info21 элементарные циклы пишет с доказательством, а я интуитивно в свое башке... И че? Результат то один. (хотя мне мои интуитивные больше нравятся  )
На сложном цикле с большим количеством переменных меня интуиция подведет, а info21 допустит ошибку на бумаге. И что дальше? Или скажете бумага ошибок не пропускает?!
На действительно сложных циклах и я бумагу мараю, но только потому, что оно в мою оперативу не помещается. 

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

[ilovb]

Вот пример из жизни (захардкодил в пятницу на месте у клиента)
5 минут на изучение формата. 15 минут на кодинг.

Загрузили уже кучу данных. Ошибок пока не обнаружено.

Код: [Выделить]

Процедура ЗагрузитьCSV_1(Путь)

ТекстовыйФайл = Новый ТекстовыйДокумент;
ТекстовыйФайл.Прочитать(Путь);

Текст = ТекстовыйФайл.ПолучитьТекст();

Буфер = "";

МассивСтрок = Новый Массив;
МассивПоказаний = Неопределено;

Для Индекс = 1 По СтрДлина(Текст) Цикл

ТекСимвол = Сред(Текст, Индекс, 1);

Если ТекСимвол = "," Тогда
МассивПоказаний = Неопределено;
МассивСтрок.Добавить(Буфер);
Буфер = "";
ИначеЕсли ТекСимвол = ";" Тогда
Если МассивПоказаний = Неопределено Тогда
МассивПоказаний = Новый Массив;
МассивСтрок.Добавить(МассивПоказаний);
КонецЕсли;
МассивПоказаний.Добавить(Буфер);
Буфер = "";
ИначеЕсли ТекСимвол <> Символы.ПС Тогда
Буфер = Буфер + ТекСимвол;
КонецЕсли;

КонецЦикла;

Состояние = "Ищем баркод";
ЛицевойСчет = Справочники.ЛицевыеСчета.ПустаяСсылка();
Сумма = 0;
НомерСтроки = 0;
Сумма1 = 0; // в баркоде неправильная сумма

Для Каждого Элемент Из МассивСтрок Цикл

Если Состояние = "Ищем баркод" Тогда
Если Найти(Элемент, "W") > 0 Тогда
НомерСтроки = НомерСтроки + 1;
// опред л/с
Если ПолучитьДанныеБарКода(СокрЛП(Элемент), ЛицевойСчет, Сумма1, НомерСтроки) Тогда
Состояние = "Ищем сумму";
Иначе
Состояние = "Ищем баркод"
КонецЕсли;
КонецЕсли;
ИначеЕсли Состояние = "Ищем сумму" Тогда
Попытка
Сумма = Число(?(Элемент = "", "0", Элемент));

// добавляем строку
НоваяСтрока = Состав.Добавить();
НоваяСтрока.ЛицевойСчет = ЛицевойСчет;
НоваяСтрока.Сумма = Сумма / 100;

Состояние = "Ищем показания"
Исключение
Сообщить("Не удалось определить сумму");
Состояние = "Ищем баркод"
КонецПопытки;
ИначеЕсли Состояние = "Ищем показания" Тогда
Если ТипЗнч(Элемент) = Тип("Массив") Тогда
// собираем показания
СтрокаСообщения = ЛицевойСчет.Код + " - "; 
Для Каждого Показание Из Элемент Цикл
СтрокаСообщения = СтрокаСообщения + Показание + "; ";
КонецЦикла;
Сообщить(СтрокаСообщения);
Состояние = "Ищем баркод"
КонецЕсли;
Иначе
ВызватьИсключение "Ошибка";
КонецЕсли;

КонецЦикла;


КонецПроцедуры
Формат тут не сложный, но дебильный (количество колонок плавает)
типа такого:

Код: [Выделить]

106798,5982144,3922588,034W0242071200352322108,36000,00188;00203;;;;
107139,5983300,153,3923490,034W0164061200940803042,50000,01085;01097;00070;00078;;;
106776,5987505,3926754,034W1199491000274242763,28000,00103;00117;00162;00181;;;
106783,5993445,3931435,034W0338781200376323156,40000,00150;00160;00083;00088;;;
107146,5995777,3933173,034W0129041200043922028,5000,00129;00132;;;;


[Geniepro]

Типичный while. А тяжёлая проверка уходит в подпрограмму.

Код: (C) [Выделить]

i = 0;

while ((i < list->Count()) && (list->Items[i] != xxx))
{
  i++;
}

if (i < list.Count())
{
  printf('yep');
}

Такой код мне вапще не нравится -- снаружи цикла появляется совершенно ненужная там переменная i, все эти инварианты цикла в данном случае меня совершенно не интересуют -- цикл простейший, условие завершения очевидное -- список либо кончится, и тогда искомый элемент не найден, или же элемент будет найден, и что там со списком меня не интересует уже.
Найден-не найден -- вот что важно. Если этот факт завуалировать через всякие дополнительные "if (i < list.Count())" -- это, имхо, затруднит понимание сути кода.

[Илья Ермаков]

Я повторюсь, это называется "культ карго":

А я не раз повторял, что у Петра культ конкретного формального метода, без желания обсуждать семантику.
Я, кстати, могу предложить ему пойти и попробовать где-нибудь на 1 курсе рядолежащего ВУЗа обучить делать циклы именно на том, безусловно, высоком матем. уровне, на котором он это сам делает. А лучше в школе. А не на 2-3 курсе мат. факультетов. У меня не получилось - а поскольку я стараюсь оставлять в арсенале только такие методы, которым я представляю, как быстро научить. Отсюда то, что Вы называете "культом карго". Это способ привить базовую дисциплину, само альтернативное понимание программы (не как последовательности инструкций). Шаг в нужную сторону. И, кстати, этого шага для многих случаев оказывается более, чем достаточно, чтобы иметь надёжный результат.

[Илья Ермаков]

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

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

[Geniepro]

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

А зачем это нужно -- отказываться от прогонки в уме?

[Peter Almazov]

1)... делать циклы именно на том, безусловно, высоком матем. уровне, на котором он это сам делает.
2)... У меня не получилось...

1). НЕТ ТАМ МАТЕМАТИКИ.
См. http://oberspace.dyndns.org/index.php/topic,331.msg8778.html#msg8778

2). Не получилось потому, что надо сначала обучить себя

[DIzer]

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

А зачем это нужно -- отказываться от прогонки в уме?

Согласен на  все 100!

[valexey_u]

Это способ привить базовую дисциплину, само альтернативное понимание программы (не как последовательности инструкций). Шаг в нужную сторону.

Сори что вмешиваюсь, просто примечание:
По моему скромному опыту обучения кого-либо программированию могу сказать, что сложнее всего прививается именно понимание программы как последовательности действий. По умолчанию народ воспринимает текст программы целиком и сразу (свободно читает его как сверху-вниз, так и снизу вверх). Отсюда возникают проблемы с понимаением "почему оно выдает не то что ожидалось". Пока в отладчике (да-да, в пошаговом отладчике) не покажешь как РЕАЛЬНО оно работает (по шагам с тыканием пальцем в то как изменяются переменные и так далее), народ не воспринимает. Если этого не сделать, то народ через какое-то время научается просто имитировать понимание и отвечать так, как ты ожидаешь услышать ответ.

Не факт что это у всех так, но у многих мозг (особенно после школьной математики) закручен не имеперативно а сурово декларативно-функционально.

[Илья Ермаков]

2). Не получилось потому, что надо сначала обучить себя

Пётр, покажите методику. Пойдите и попробуйте. На студентах СПО после 9 класса.
Я не делаю разницу между собой и студентами, в том смысле, что обычно не задействую в повседневном арсенале программирования те методы, которым невозможно обучить в течение полутора лет. Info21 с "паттернами" столкнулся с тем же самым. Мы можем сколько угодно читать Дейкстру и Гриса, но в первую очередь для того, чтобы спроецировать их в такие методы, которые можно объяснить доходчиво и доступно для использования всеми, желательно в первые полгода (потому что лично у меня во вторые полгода начинается ООП и элементы архитектуры).
Вы правы, если судить с позиции отдельно взятого интеллектуала. У нас срабатывают другие факторы, при которых просто нет иного пути, чем то, что Вы называете "культ карго". Врубитесь в ситуацию, в конце концов.