Здравствуйте, mgu, Вы писали:

AG>>Это просто ужасно...
AG>>Когда при чтении такого кода, я вынужден скроллить вверх и искать: где эта переменная и какое значение у неё в тот момент (точнее — в том месте),
AG>>когда она реально нужна (в том месте метода/функции, где она используется)!

mgu>Control-чпок в модных IDE обычно решает проблему.
А удачный стиль программирования её вообще исключает: пиши себе код — хоть в студии, хоть в блокноте

mgu>А за методы, превышающие по размеру 2 экрана, во времена моей программистской молодости били в коридоре ногами. И строк на экране тогда было мало.
Это очень хорошо, для студенческих разработок. В объемных же проектах, иногда бывает так, что дробление метода на несколько кусков-методов
(при этом — каждый из которых применяется только в одном месте) может существенно затруднить чтение кода.

mgu>Проблема же, на мой взгляд, в другом -- в начале функции инициализируются переменные,
Почему же это не делать именно там, где каждая из них реально требуется?

mgu>затем идут проверки, после которых наши переменные могут и не понадобиться.
Это только свидетельствует о непродуманном дизайне Вашего API, а возможно и всей архитектуры проекта

P.S. Все проверки — IMHO должны быть выделены в отдельный метод/методы (или даже класс).
Обычно — это делается на уровне GUI приложения — чтобы в случае чего, показать user-у где и в чем он ошибся.
Все расчеты, вычисления, обработка данных и т.д. — происходят в отдельном от GUI объекте,
специально разработанного для этой цели класса (класса реализации бизнесс-логики либо вычислительного ядра).
Класс бизнесс-логики/ядра иногда удобно наследовать от интерфейса (aka абстрактный базовый класс в терминологии C++).
Тогда можно применять указатель именно на базовый интерфейс Вашего класса, а не на объект класса (реализация паттрна "Стратегия").

Такой подход позволяет:
1) Отделить GUI от бизнес-логики — что значительно упростит чтение и понимание Вашего кода коллегами;
2) При необходимости — проще переходить на другие GUI-фреймворки (если такое потребуется);
3) Если потребуется менять алгоритмы бизнес-логики (вычислительного ядра) — то не нужно будет "сражаться" с переделкой GUI.

Здравствуйте, mgu, Вы писали:

AG>>Это просто ужасно...
AG>>Когда при чтении такого кода, я вынужден скроллить вверх и искать: где эта переменная и какое значение у неё в тот момент (точнее — в том месте),
AG>>когда она реально нужна (в том месте метода/функции, где она используется)!

mgu>Control-чпок в модных IDE обычно решает проблему.
А удачный стиль программирования её вообще исключает: пиши себе код — хоть в студии, хоть в блокноте

mgu>А за методы, превышающие по размеру 2 экрана, во времена моей программистской молодости били в коридоре ногами. И строк на экране тогда было мало.
Это очень хорошо, для студенческих разработок. В объемных же проектах, иногда бывает так, что дробление метода на несколько кусков-методов
(при этом — каждый из которых применяется только в одном месте) может существенно затруднить чтение кода.

mgu>Проблема же, на мой взгляд, в другом -- в начале функции инициализируются переменные,
Почему же это не делать именно там, где каждая из них реально требуется?

mgu>затем идут проверки, после которых наши переменные могут и не понадобиться.
Это только свидетельствует о непродуманном дизайне Вашего API, а возможно и всей архитектуры проекта

P.S. Все проверки — IMHO должны быть выделены в отдельный метод/методы (или даже класс).
Обычно — это делается на уровне GUI приложения — чтобы в случае чего, показать user-у где и в чем он ошибся.
Все расчеты, вычисления, обработка данных и т.д. — происходят в отдельном от GUI объекте,
специально разработанного для этой цели класса (класса реализации бизнесс-логики либо вычислительного ядра).
Класс бизнесс-логики/ядра иногда удобно наследовать от интерфейса (aka абстрактный базовый класс в терминологии C++).
Тогда можно применять указатель именно на базовый интерфейс Вашего класса, а не на объект класса. Это реализация паттерна "Стратегия".

Такой подход позволяет:
1) Отделить GUI от бизнес-логики — что значительно упростит чтение и понимание Вашего кода коллегами;
2) При необходимости — проще переходить на другие GUI-фреймворки (если такое потребуется);
3) Если потребуется менять алгоритмы бизнес-логики (вычислительного ядра) — то не нужно будет "сражаться" с переделкой GUI.