Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.97.14.91] |
|
Страницы: (7) « Первая ... 4 5 [6] 7 все ( Перейти к последнему сообщению ) |
Сообщ.
#76
,
|
|
|
Цитата Ещё такие вещи оправданы в пхп-скриптах, когда необходимо всю функциональность разместить в одном файле. Патологоанатому расскажешь, хорошо? Мне хочется удушить своего бывшего сотрудника, оставившего на меня одну такую макаронную фабрику. |
Сообщ.
#77
,
|
|
|
Ho Im, скажем так: разобраться в чужом коде часто нелегко, но зависит это не от длинны функций, а ОТ СТИЛЯ ВООБЩЕ.
Грамотно комментированный линейный код намного понятнее, чем сотни плохо комментированных функций. короче, народ, надоело мне с вами спорить... и вааще, здесь не место для холивара. кто хочет продолжать - в холиварах есть тема про goto, там поддержу беседу... |
Сообщ.
#78
,
|
|
|
Использование goto и размер функций - лишь косвенные признаки структурированности кода.
Само по себе введение новой функции - это минус к читаемости программы, как и введение любого нового объекта. Поэтому функцию вводить оправдано, только если плюсы перевешивают. Золотая середина здесь в каждом конкретном случае своя. ..Но список функций на 2 экрана часто гораздо менее читаем, чем функция на 2 экрана (потому что для функций подразумевается некоторый сценарий их взаимодействия, который из самого списка никак не виден, в то время как код имеет логику). При этом в разный языках оптимальный размер функций разный. Так в Паскале он меньше, поскольку Паскаль допускает локальные функции, но не допускает переменных в блоке. В С - соответствено больше, поскольку функцию можно разбить на полностью изолированные блоки. Правда, в языке С не хватает прагмы отмены видимости глобальных переменных в локальном блоке. |
Сообщ.
#79
,
|
|
|
Цитата nvm @ Само по себе введение новой функции - это минус к читаемости программы, как и введение любого нового объекта. зы. категорически не согласен. представь тебе надо пощитать злую формулу.. и есть выбор между y = CountZlo(x); и y = sqrt(x*66 -77 %x -94 +x*cos(x+7)); что будет читаемее? Добавлено Цитата BlackSnake @ в time-critical функциях это ОЧЕНЬ оправдано, т.к. вызов функции (даже из этого проекта) занимает достаточно много времени. хорошо написанные функции станут встраиваемыми ,и вызова не будет вообще. и даже если он будет то push, pop,call,ret особой роли в производительности не играют. если уж думать о таких вещах -- то проще прогить на асме. |
Сообщ.
#80
,
|
|
|
Цитата LuckLess, 26.02.2006, 18:13:38, 1027381 представь тебе надо пощитать злую формулу.. и есть выбор между y = CountZlo(x); и y = sqrt(x*66 -77 %x -94 +x*cos(x+7)); что будет читаемее? если такое вычисление встречается многократно - то да, функция рулит, т.к. есть смысл запомнить мозгом, что она делает и зачем. иначе - мне намного удобнее не ходить в ту функцию посмотреть (запоминать-то её незачем, если она всего пару раз встречается) что она такое, а потратить 10 секунд на визуальный анализ строки sqrt(x*66 -77 %x -94 +x*cos(x+7)). (более того, если меня в опр. момент не интересует математика, то и читать эту строку я не стану.), а если написано y = CountZlo(x); , то если я не помню, что такое CountZlo, придётся идти читать её, причём в любом случае. Цитата LuckLess, 26.02.2006, 18:13:38, 1027381 хорошо написанные функции станут встраиваемыми ,и вызова не будет вообще. и даже если он будет то push, pop,call,ret особой роли в производительности не играют. если уж думать о таких вещах -- то проще прогить на асме. хм. ты хотел сказать "хорошо написанный компилер сделает их встроенными", наверное? Я предпочитаю не нагружать компилер лишней работой, особенно если не уверен в интеллектуальности его оптимизации. |
Сообщ.
#81
,
|
|
|
BlackSnake, если не секрет, что ты пишешь?(на чём?)
Просто никогда ранее не встречал людей, так... увлечённых оптимизацией :-) |
Сообщ.
#82
,
|
|
|
Цитата BlackSnake @ Я предпочитаю не нагружать компилер лишней работой, особенно если не уверен в интеллектуальности его оптимизации. Цитата Э.Дейкстра Premature optimization is the root of all evil |
Сообщ.
#83
,
|
|
|
Цитата LuckLess @ представь тебе надо пощитать злую формулу.. и есть выбор между y = CountZlo(x); и y = sqrt(x*66 -77 %x -94 +x*cos(x+7)); что будет читаемее? Второй вариант читаемее, т.к. сразу видно, в чем зло. Функция здесь оправдана, только если выражение вычисляется более одного раза. |
Сообщ.
#84
,
|
|
|
Цитата BlackSnake @ хм. ты хотел сказать "хорошо написанный компилер сделает их встроенными", наверное? Я предпочитаю не нагружать компилер лишней работой, особенно если не уверен в интеллектуальности его оптимизации. это не лишняя , а совершенно обычная для компилятора работа. компилятор без нормального оптимизатора - редкость , которая никому не нужна. Цитата nvm @ Второй вариант читаемее, т.к. сразу видно, в чем зло. не видно ничего , в том то и дело. я для примера привел простое вычисление , имееться ввиду что оно большое , скажем в пол экрана кода. совершенно нечитаемо для варианта без функции. моэно конечно выделить этот кусок кода коментариями. Но зачем ?? Для таких случаев придуманы функции. Добавлено PS:перенечите плз тему в холи варзз )) |
Сообщ.
#85
,
|
|
|
Цитата Я предпочитаю не нагружать компилер лишней работой А я предпочитаю. Ибо не люблю напрягаться. Пусть лошковатый компилер за меня понапрягается, пока я еще одно пивцо наверну. |
Сообщ.
#86
,
|
|
|
Цитата Gregory Petrosyan, 26.02.2006, 20:45:15, 1027495 BlackSnake, если не секрет, что ты пишешь?(на чём?) Просто никогда ранее не встречал людей, так... увлечённых оптимизацией :-) Сейчас основная моя работа на VBA (не VB, а VBA - который встроен в МС-Оффис). Увлечённость оптимизацией происходит, вероятно со времён Спектрума... когда у компа тактовая частота что-то порядка 2 МГц - тут хошь-нехошь думаешь об оптимизации. |
Сообщ.
#87
,
|
|
|
Лично я goto уважаю за то, что этот оператор иногда позволяет упростить логику программы. Вот несколько ситуаций когда самому приходилось пользоваться (чистый C).
1. Выход из вложенных циклов. Кстати, использование return здесь не всегда оправданно, так как если он расположен где-нибудь в середине цикла, глубоко среди остального текста, то его не видно. Из-за чего обычно делаются неправильные выводы о работе функции. Что не есть хорошо. 2. Имитация рекурсивного вызова функции. Многим это кажется излишним, но иногда встречаются функции, которые при рекурсивном вызове махом съедают стек, а на компилятор надеяться непереносимо, мало ли на каком старье решат откомпилировать (Встречаются еще компиляторы, которые концевую рекурсию не оптимизируют). 3. Небольшой трюк в switch. Иногда бывает, что несколько из case'ов подразумевают практически одинаковую обработку. Отличие в начальном присваивании одной-двум переменным. Тогда бывает имеет смысл вместо объединения их в один блок case'ов и проверки, по какому же из них произошел вход, пометить общую часть меткой и сделать из всех case'ов на нее переход. Правда это имеет смысл только в том случае, если по каким-то причинам не подходит обработка в отдельной функции, что было-бы поудобнее. 4. Ситуация описанная в одном из топиков выше. В парсерах в начале обработки одной из веток case (состояние автомата) иногда выясняется, что мы попали не в ту ветку (находимся не в том состоянии). Лучшим выходом было бы пересмотреть таблицу переходов, чтобы всегда попадать туда, куда нужно, но иногда из-за этого раздувается код парсера. Если таких ситуаций немного, проще бывает сделать прыжок на нужную ветку. 5. Прыжок к блоку обработки ошибок. Если не подходит обработка на месте возникновения, несколько ошибок требуют одинаковой обработки и при этом не годится вызов функции. Можно вынести обработку ошибки в конец функции и дать ей нормальную метку с "говорящим" именем. Причем всегда приходится объяснять, для чего эта метка нужна. К сожалению некоторые этим оператором злоупотребляют. В моей работе был случай. Надо было внести в общем-то пустяковое изменение в программу ввода (редактирования) и обработки некоторых данных. Исходник был оформлен в виде одного файла длиной около двух с половиной тысяч строк. Кроме функции main в нем присутствовало еще с десяток функций длиной строк по десять и одна функция строк на двести. Автор недавно перешел с фортрана (хотя наверно с год уже с языком С был знаком). По этой причине функция была полна переходов, на них была построена львиная доля циклов, они использовались для организации переходов между полями таблицы и т.д. и т.п. Перед внесением этого изменения пришлось перерыть всю программу, вынести в функции некоторые повторяющиеся операции (последствия операции копирования-вставки в редакторе), переписать циклы и еще кучу всякой всячины, иначе я не мог представить, что у меня перестает работать. В результате, на работу, которая должна была занять часа два (ну может день), было потрачено больше полумесяца. И то, мне было проще чем остальным - я хоть в общих чертах знал, что эта программа должна была делать, застал время ее написания. |
Сообщ.
#88
,
|
|
|
Цитата Правила некоторых компаний запрещают использование вложенных циклов И языков программирования, надо полагать, тоже? Цитата Про исключения один я здесь слышал?! Если в языке С -- то да ;-) |
Сообщ.
#89
,
|
|
|
Бугага, а как тот же алгоритм флойда без вложенных циклов писать? |
Сообщ.
#90
,
|
|
|
Цитата LuckLess, 27.02.2006, 15:42:31, 1028197 совершенно нечитаемо для варианта без функции. моэно конечно выделить этот кусок кода коментариями. Но зачем ?? Для таких случаев придуманы функции. Функции придуманы не для таких случаев, а для выноса ПОВТОРЯЮЩИХСЯ вычислений (действий). в данном случае - всё-таки правильнее написать два коммента, типа "//тут мы будем вычислять какую-то ерунду" в начало вычислений и "//ну вот мы её и вычислили". Вынос подобного кода, если он не периодичен, не имеет смысла и противоречит принципам структурного программинга. Цитата LuckLess, 27.02.2006, 15:42:31, 1028197 нормальность оптимизера - вещь спорная. если ты, например, зачем-то применишь неподходящий тип для данных (например Integer вместо Long), то компилер вероятнее всего этого не заметит, если это не вызовет ошибок, но оптимальность от этого пострадает. В данном случае, вероятно, уменьшится скорость.это не лишняя , а совершенно обычная для компилятора работа. компилятор без нормального оптимизатора - редкость , которая никому не нужна. Цитата Ho Im, 27.02.2006, 17:03:12, 1028315 А я предпочитаю. Ибо не люблю напрягаться. Пусть лошковатый компилер за меня понапрягается, пока я еще одно пивцо наверну. Пивцо это канешна харашо, но... я предпочитаю потратить час своего времени на оптимизацию кода, чем терять 5 минут в сутки на протяжении полугода, пока прогой пользуюсь... Цитата LuckLess, 27.02.2006, 15:42:31, 1028197 Да там уже есть такая тема. PS:перенечите плз тему в холи варзз )) |