Здравствуйте, AlexGin, Вы писали:
mgu>>Control-чпок в модных IDE обычно решает проблему.
AG>А удачный стиль программирования её вообще исключает: пиши себе код — хоть в студии, хоть в блокноте 
Да, со смартфона. Только хардкор.
mgu>>А за методы, превышающие по размеру 2 экрана, во времена моей программистской молодости били в коридоре ногами. И строк на экране тогда было мало.
AG>Это очень хорошо, для студенческих разработок. В объемных же проектах, иногда бывает так, что дробление метода на несколько кусков-методов
AG>(при этом — каждый из которых применяется только в одном месте) может существенно затруднить чтение кода.
Ну да, выбор размера метода -- это тоже искусство. В противоположность обезьянничанию по лекалам.
mgu>>Проблема же, на мой взгляд, в другом -- в начале функции инициализируются переменные,
AG>Почему же это не делать именно там, где каждая из них реально требуется?
Я только "за".
mgu>>затем идут проверки, после которых наши переменные могут и не понадобиться.
AG>Это только свидетельствует о непродуманном дизайне Вашего API, а возможно и всей архитектуры проекта 
AG>P.S. Все проверки — IMHO должны быть выделены в отдельный метод/методы (или даже класс).
AG>Обычно — это делается на уровне GUI приложения — чтобы в случае чего, показать user-у где и в чем он ошибся.
AG>Все расчеты, вычисления, обработка данных и т.д. — происходят в отдельном от GUI объекте,
AG>специально разработанного для этой цели класса (класса реализации бизнесс-логики либо вычислительного ядра).
Ох, не били вас в молодости ногами... Проверки должны быть и в гуях, и на принимающей стороне. Тем более, что данные могут приходить не только от морды. Да даже в частной функции -- открываем файл, а его уже умыкнули...
AG>Класс бизнесс-логики/ядра иногда удобно наследовать от интерфейса (aka абстрактный базовый класс в терминологии C++).
AG>Тогда можно применять указатель именно на базовый интерфейс Вашего класса, а не на объект класса. Это реализация паттерна "Стратегия".
Спасибо, мне уже доложили. (с) Брежнев.
AG>Такой подход позволяет:
AG>1) Отделить GUI от бизнес-логики — что значительно упростит чтение и понимание Вашего кода коллегами;
AG>2) При необходимости — проще переходить на другие GUI-фреймворки (если такое потребуется);
AG>3) Если потребуется менять алгоритмы бизнес-логики (вычислительного ядра) — то не нужно будет "сражаться" с переделкой GUI.
В моей вселенной обычно гуисты и разработчики промежности даже не догадываются о существовании друг друга.
