Извините, ничего не найдено.

Hurrit · 12.11.2010, 22:35

На лекциях говорили, что одна функция, должна выполнять одну задачу, тогда легче будет исправлять ошибки, и следить за кодом. Собственно говоря, я всегда придерживаюсь трех правил:
1. Выносить всё возможное в функции.
2. Давать функциям, типам и переменным нормальные имена.
3. Если функция приняла окончательный вид, то выносить функцию в отдельный инклуд файл.
И благодаря этим трем функциям, я легко через 10 минут могу разобраться в коде годовой давности.

Crayzi · 12.11.2010, 22:51

Сообщение от Hurrit

На лекциях говорили, что одна функция, должна выполнять одну задачу, тогда легче будет исправлять ошибки, и следить за кодом. Собственно говоря, я всегда придерживаюсь трех правил:
1. Выносить всё возможное в функции.
2. Давать функциям, типам и переменным нормальные имена.
3. Если функция приняла окончательный вид, то выносить функцию в отдельный инклуд файл.
И благодаря этим трем функциям, я легко через 10 минут могу разобраться в коде годовой давности.

+
Я тоже стараюсь все что относится к одному типу действий выносить в функции и задавать им параметры, правда восновном так поступаю со сложными частями кода, чтобы было проще править либо с повторяющимися более 1 раза.

ffinder · 12.11.2010, 23:11

А вы правда отличаете функциональное программирование от процедурного?
Думаю, что не все.

Если у вас функции изменяют глобальные массивы и переменные это не "совсем" функции. Это процедуры.

Функция это трансформация. Черный ящик с входами и одним выходом. Принимает аргументы - возвращает результат.

Хорошая программа это несколько модулей с функциями по одной-две-три строчки каждая. Это - идеал.

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

pepel · 12.11.2010, 23:15

ffinder спасибо .оч полезно . не знал этого

EvilChaotic · 12.11.2010, 23:34

Пора разбавить картинками все вышесказанное!
Ы. Управление всеми наземными единицами. Открыл одну функцию для наглядности, справа почти все бб'шники. Удачи в больших проектах!

IGR · 13.11.2010, 01:11

Сообщение от pepel

это как?

Ну в блице классов как таковых нет !! Да и класс не обезательно нужен !!

я имел ввиду что высший по иерархии объект должен управлять теми кто ниже !! Но никак не наоборот !!

pepel · 13.11.2010, 01:13

ааа ясно.

Mr_F_ · 13.11.2010, 17:44

http://www.insidecpp.ru/antipatterns/spaghetti/

Hurrit · 13.11.2010, 22:22

Сообщение от ffinder

А вы правда отличаете функциональное программирование от процедурного?
Думаю, что не все.

Если у вас функции изменяют глобальные массивы и переменные это не "совсем" функции. Это процедуры.

Функция это трансформация. Черный ящик с входами и одним выходом. Принимает аргументы - возвращает результат.

Хорошая программа это несколько модулей с функциями по одной-две-три строчки каждая. Это - идеал.

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

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

ffinder · 14.11.2010, 01:37

Сообщение от Hurrit

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

Ни процедура ни функция не являются модулем. Остальное верно.

Hurrit · 16.11.2010, 20:00

Сообщение от ffinder

Ни процедура ни функция не являются модулем. Остальное верно.

moka · 17.11.2010, 13:35

Давно уже б3д не использую из-за его убоговсти как языка.
Дома, BlitzMax, всё выношу в классы, никогда не работаю с глоабльными списками, лучше создать пару списков и хранить их в озу (это копейки памяти), и бегать по ним, чем иметь какой-нибудь убер список.
Пишу код модульно, таким образом что вставить например между двумя связями двух классов, посреднеческий класс, например система распределяющая списки объектов на сектора, для оптимизации друг-друго зависемых просчётов, такое не состовляет никаких проблемм.
Пишу обычно классы в стиле "интерфейсов", как таковой он может работать самостоятельно, даже если я пишу его в прототипе, это не составит труда его внедрить потом таким какой он есть в готовый продукт, только используя функции доступа к информации которая нужна для основной логики программы, или для визуализирования.
Код нужно писать таким образом чтобы он был более структуризирован.
Например в C# никогда не ссылаюсь к параметрам эллемента, всегда использую функцию set/get посредника. Такой подход всегда даст возможность удобно читать код, и делает сам класс, более как интерфейс отвечающий на запросы.
К сожалению Blitz3D подобного не предастовляет, можно конечно извращаться с хэндлами там и т.п. но это уже быдло кодерство..
Ну и естественно стиль, придерживаюсь таких правил:
все приватные и локальные переменные начинаются с "_", и маленькой буквы. В середине переменной никогда не использую "_", а использую каждую первую букву слова в имени переменной заглавной, например: _videoPreviewEventEx - локальная пременная относиться к ловле событий из элемента предпросмотра видео.
Для функций и классов всегда использую первую как заглавную: OpenFile, и т.п.
Имена дают о себе понять.
Например есть у нас класс по работе с DirectShow фильтрами, и там есть класс для записи видео с камеры: Video.Capture.Start(_fileName);
Что нибудь такого рода.