Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
Ещё можно добавить по поводу хранения размера массива в отдельной переменной. Согласен, что дублирование данных — это, как правило, плохая практика, но иногда дублирование упрощает код или повышает его эффективность. Если функция работает с массивом и в ней содержится много обращений к длине массива, то проще сохранить длину в отдельной переменной с коротким и понятным именем, например n.
К примеру, функция, выполняющая слияние двух отсортированных массивов на C#.
С хранением размера в отдельных переменных:
Без хранения размера:
Какой вариант легче читается, а следовательно легче поддерживается и меньше шансов допустить ошибку?
К примеру, функция, выполняющая слияние двух отсортированных массивов на C#.
С хранением размера в отдельных переменных:
static int[] MergeArrays(int[] firstArray, int[] secondArray)
{
int n1 = firstArray.Length, n2 = secondArray.Length;
int[] res = new int[n1 + n2];
int p1 = 0, p2 = 0, p = 0;
while (p1 < n1 || p2 < n2)
{
if (p1 < n1 && (p2 == n2 || firstArray[p1] < secondArray[p2]))
res[p++] = firstArray[p1++];
else
res[p++] = secondArray[p2++];
}
return res;
}
Без хранения размера:
static int[] MergeArrays(int[] firstArray, int[] secondArray)
{
int[] res = new int[firstArray.Length + secondArray.Length];
int p1 = 0, p2 = 0, p = 0;
while (p1 < firstArray.Length || p2 < secondArray.Length)
{
if (p1 < firstArray.Length && (p2 == secondArray.Length || firstArray[p1] < secondArray[p2]))
res[p++] = firstArray[p1++];
else
res[p++] = secondArray[p2++];
}
return res;
}
Какой вариант легче читается, а следовательно легче поддерживается и меньше шансов допустить ошибку?
Видимо, я не очень удачный пример выбрал. Ну суть в том, что если в коде часто встречается «someArray.Length», то можно заменить его на «n». И читать, и писать код будет удобнее.
n очень понятно, ага…
блин, ну someArrayLength тогда. Просто вам хотели сказать, что если вы много раз в коде бездумно считываете некоторое свойство, то можно попасть, если это ресурсоемкий геттер. В случае длинны массива не так очевидно, ну а если допустим есть объект со свойством числового типа, а также свойством, содержащим факториал данного числа. :)
А почему нет? Точно также, как и в случае с i, j понятно, что это счётчики цикла. Я считаю, что длина имени идентификатора должна быть адекватна его цели. В общем случае длина должна быть пропорциональна области видимисти идентификатора. Локальные переменные в функциях вполне можно называть однобуквенными именами.
Ну суть в том, что если в коде часто встречается «someArray.Length», то можно заменить его на «n». И читать, и писать код будет удобнее.
в подавляющем большинстве случаев за вас это сделает компилятор ;)
Если я правильно понимаю, то первый вариант предпочтительней использовать ещё и потому, что операция получения длинны массива занимает больше времени, чем получение значения переменной. Т.е. первый код должен работать быстрее.
>Если функция работает с массивом и в ней содержится много обращений к длине массива, то проще
>сохранить длину в отдельной переменной с коротким и понятным именем, например n.
Офигительно понятное имя! :)
>сохранить длину в отдельной переменной с коротким и понятным именем, например n.
Офигительно понятное имя! :)
Вы просто не работали с функциональными языками :)
По-моему, право на существование имеет только i и то в редких случаях.
Неужели так сложно назвать переменную nArrayLen? Польза ведь очевидна — говорить о назначении переменной будет ее имя, а не алгоритм, в котором она используется.
Неужели так сложно назвать переменную nArrayLen? Польза ведь очевидна — говорить о назначении переменной будет ее имя, а не алгоритм, в котором она используется.
=)))
Возврат через параметр — это для языков, которые не поддерживают кортежи (tuple). Кортежи как раз для того и придумали, чтобы можно было:
def foo():
return True, 42
fOk, nValue = foo()
if fOk:
…
def foo():
return True, 42
fOk, nValue = foo()
if fOk:
…
питон == масс исключения, какие нафиг статусы возвращать? o_O
При чем тут питон? Я про tuple. Они в половине языков реализованы. Исключения, это для контроля ошибок на мой взгляд, оно отдельно.
тоесть псевдокод выше не питон?
Нет, это иллюстрация того, что многие языки позволяют сделать return a, b, c и a, b, c = foo() соответственно. К сожалению, c++ и php без буста так не умеют :(. В php, правда, list construct есть, но с ним страшновато выглядит :)
В следующем примере, ясно видно, что функция возвращает array():
function sql2array($query, $field=false) {
$Result = array();
function sql2array($query, $field=false) {
$Result = null;
А в этом примере ясно видно, что функция возвращает null :)
Пользуйтесь phpDoc. Оно в разы эффективнее :)
Может и еще по нескольким вопросам похоливарил бы, только бесполезно это все :) Мне ближе точка зрения автора предыдущего топика. там я вроде только по 1-2 пунктам имел возражения. И также как и он люблю js :)
Извините, пример просто не совсем удачный я выбрал. То, что я здесь описал, не касается конкретно PHP.
Например, в C/C++ ясно будет видно, что мы возвращаем.
Например, в C/C++ ясно будет видно, что мы возвращаем.
И опять неудачный пример. В С++ мы описываем возвращаемый тип в сигнатуре функции:
int Sum(int a, int b) — как-то так :)
int Sum(int a, int b) — как-то так :)
Пример и правда не совсем удачный. Но об этом я и хотел сказать.
В PHP я просто стараюсь делать максимально говорящие переменные. И определять в начале явно не null (если они возвращают array()). Просто для того, чтобы было яснее происходящее c первых строчек кода метода/функции.
В некоторых случаях это не работает — тогда уже (как было сказанно ниже), деклорации @return (и другие хелперы) спасут программистов :).
В PHP я просто стараюсь делать максимально говорящие переменные. И определять в начале явно не null (если они возвращают array()). Просто для того, чтобы было яснее происходящее c первых строчек кода метода/функции.
В некоторых случаях это не работает — тогда уже (как было сказанно ниже), деклорации @return (и другие хелперы) спасут программистов :).
Просто для того, чтобы было яснее происходящее c первых строчек кода метода/функции.
Происходящее должно стать понятным не при просмотре текста функции, а по подсказке редактора кода, там где эту функцию вызывают. Смотреть как объявлены служебные переменные, чтобы понять, что возвратит функция — сори конечно, но это бред.
Одно из другого не вытекает, сами понимаете. Если я использую phpDoc, мне ничего не мешает писать понятным языком тело функций.
Нет конечно. Но специально выносить декларацию переменных в неудобное место ради неясных целей — это не есть понятный язык для тела функции. Переменная должна быть объявлена там, где это удобно. И если код хорошо задокументирован, то этому вообще ничего не мешает — никакие уловки насчет $result = array();
В общем, я хочу, чтобы вы отказались от своего первого возражения :) Остальные — вполне объяснимы и понятны.
В общем, я хочу, чтобы вы отказались от своего первого возражения :) Остальные — вполне объяснимы и понятны.
Зря вы так. Всякие *Doc это конечно хорошо, но требует дополнительных затрат, а в данном случае у нас код сам себя документирует. ИМХО, это полезно, а в случае VB, например, еще и предохраняет от определенного вида ошибок.
а в данном случае у нас код сам себя документирует
Нет. Документированный код — это такой код, в котором без всяких домыслов понятно — что делает этот код. Назвать переменную «Result» и присвоить ей массив в самом начале — это не документация. У типизированных языков — что возвращает функция указывается в коде. У любого нетипизированного языка всегда есть чтото вроде phpDoc(jsDoc), который и помогает нам преодолеть вышеописанные проблемы.
Это оправданные затраты. Нормальная IDE, типа Eclipse, при наведении на метод будет показывать его описание из PHPDoc, например. И вообще, это полезно: сначала написать комментарий, а потом написать код, т.к. сначала думаешь, а потом делаешь.
Как видите, функция теперь возвращает два параметра — это $error — статус выполнения функции и массив, в случае правильного выполнения.
============
В таком случае, лучше использовать Exception и его дальнейшую обработку
============
В таком случае, лучше использовать Exception и его дальнейшую обработку
function sql2array($query, $field=false) {
$Result = array();
if [...] {
return false;
}
[...]
return $Result;
}
</code>
это тоже путь темной стороны. Даже если язык позволяет, функция не должна возвращать значения разных типов в зависимости от пути выполнения - уж лучше кинуть эксепшн.Не соглашусь. Это зависит от архитиктуры.
Граблей этим мы не плодим, и куда приятнее и нагляднее в PHP сравнивать get_length(...) не с -1, а с false.
Граблей этим мы не плодим, и куда приятнее и нагляднее в PHP сравнивать get_length(...) не с -1, а с false.
Программирование это уже не как раньше. Десяток языков и кругом задач в 20-30 направлениях. Программирование это уже целая отрасль с огромных количеством языков и направлений.
Было бы странно видеть проектировщика электросетей который спорит с архитектором, как именно ставить размеры на чертежах.
Так и в программирование, под каждое направление определяется свой набор правил. Главное чтобы эти правила было обдуманными и логичными.
Было бы странно видеть проектировщика электросетей который спорит с архитектором, как именно ставить размеры на чертежах.
Так и в программирование, под каждое направление определяется свой набор правил. Главное чтобы эти правила было обдуманными и логичными.
при сложности возвращаемого значения оборачивайте функцию в обьект.
и пусть результаты будут доступны как свойства обьекта.
и пусть результаты будут доступны как свойства обьекта.
Жизненно, в отличие от :-)
Come to the dark side… we have cookies!
будто ты не читал гайды про исключения… не везде исключения хорошая практика. Пример функция FileExists с доп. выходным параметром «bool canWriteThisFile».
Хмм… Это в каком языке такая конструкция? Функция должна делать только, то как она называется. Если функция проверки существования файла еще показывает, можно ли в него что-то писать это, извиняюсь, говнокод.
Скорее всего тут необходимо привести пример из C#: bool Int32.TryParse(string s, out int result), вот тут исключения как раз — плохая идея.
Скорее всего тут необходимо привести пример из C#: bool Int32.TryParse(string s, out int result), вот тут исключения как раз — плохая идея.
> В следующем примере, ясно видно, что функция возвращает array():
Надо не объявлять $Result в начале функции а написать толковый комментарий:
/**
* Returns query result as array
*
* @param string $query
* @param bool $field
* @return array;
*/
Тогда можно будет понять, что функция возвращает массив либо по комментариям, либо по документации, даже не заглядывая в код.
С предыдущим автором согласен — переменные должны быть там, где они нужны!
Надо не объявлять $Result в начале функции а написать толковый комментарий:
/**
* Returns query result as array
*
* @param string $query
* @param bool $field
* @return array;
*/
Тогда можно будет понять, что функция возвращает массив либо по комментариям, либо по документации, даже не заглядывая в код.
С предыдущим автором согласен — переменные должны быть там, где они нужны!
«Доступ к свойствам объекта»… ИМХО должны быть set\get методы, если set подразумевает какую-то логику работы (например ресайз массива или влияние на значение других property или возвратов функций).
Если логики особой нет, то и городить два метода (в случае поддержки property) не имеет большого смысла…
Если логики особой нет, то и городить два метода (в случае поддержки property) не имеет большого смысла…
ой, сори не туда написал.
> Если-бы я поставил $Result после проверки !$queryResource, то глазами пришлось-бы бегло перечитывать код в поисках типа этой переменной.
Если бы вы добавили в код больше структуры, вот так:
сразу бы стало ясно какого типа переменная $Result.
>Именно для этого в C все переменные определяются в начале.
Это просто ограничение Си, введенное для пущей простоты реализации компилятора.
>Возврат результата функции через ее параметр.… Автор правильно говорит, что, когда нет необходимости, стоит пользоваться return'ом. Но, необходимость иногда возникает!
Для возврата более одного результата можно воспользоваться кортежами или tagged unions. Так как в PHP нет ни того, ни другого, приходится возвращать результат через параметр. Это ограничение PHP, а не фейл структурного программирования.
>Автор предлагает объявлять и использовать (на примере С) для каждого объекта свою структуру. То есть получается, что для каждой функции, необходима своя структура — это согласитесь бред.
Тут нужен tagged union, тогда это будет не бред.
>В функциональном программировании по хорошему счёту — разделяют на «атомарные» функции предварительной инициализации.
Вы говорите про процедурное программирование. Процедурное != функциональное.
Если бы вы добавили в код больше структуры, вот так:
function sql2array($query, $field=false, &$error=NO_ERROR) {
if (DEBUG)
print ("Query: $query\n");
$queryResource = $this->query($query);
if (!$queryResource){
$error = QUERY_ERROR;
return false;
}
else {
$Result = array();
while($Data = $this->fetch_array($queryResource)) {
if(!$field)
$Result[] = $Data;
elseif (isset($Data[$field]))
$Result[$Data[$field]] = $Data;
else{
$error = FIELD_ERROR;
return false;
}
}
$this->free_result($queryResource);
return $Result;
}
}
сразу бы стало ясно какого типа переменная $Result.
>Именно для этого в C все переменные определяются в начале.
Это просто ограничение Си, введенное для пущей простоты реализации компилятора.
>Возврат результата функции через ее параметр.… Автор правильно говорит, что, когда нет необходимости, стоит пользоваться return'ом. Но, необходимость иногда возникает!
Для возврата более одного результата можно воспользоваться кортежами или tagged unions. Так как в PHP нет ни того, ни другого, приходится возвращать результат через параметр. Это ограничение PHP, а не фейл структурного программирования.
>Автор предлагает объявлять и использовать (на примере С) для каждого объекта свою структуру. То есть получается, что для каждой функции, необходима своя структура — это согласитесь бред.
Тут нужен tagged union, тогда это будет не бред.
>В функциональном программировании по хорошему счёту — разделяют на «атомарные» функции предварительной инициализации.
Вы говорите про процедурное программирование. Процедурное != функциональное.
На счёт tagged unions.
В PHP можно возвращать любые классы, значения или массивы. При всём, tagged можно проверять c помощью get_type($result). Если класс — то добавив сравнение get_class($result).
Только это не поможет, если необходимо возвращать несколько значений.
Более-менее интерестный вариант рассмотрен здесь. Но опять, не универсальный — имеет ряд преимуществ и недостатков.
В PHP можно возвращать любые классы, значения или массивы. При всём, tagged можно проверять c помощью get_type($result). Если класс — то добавив сравнение get_class($result).
Только это не поможет, если необходимо возвращать несколько значений.
Более-менее интерестный вариант рассмотрен здесь. Но опять, не универсальный — имеет ряд преимуществ и недостатков.
Вот, кстати, верно подмечено в исходной статье (я тоже заметил, но как-то комментарий не написал): если автор так борется за красоту кода, то о каких 300 строчках кода в одной функции может идти речь?
> Как видите, функция теперь возвращает два параметра — это $error — статус выполнения функции и массив, в случае правильного выполнения.
Пример нехороший, ошибка это побочный эффект, а функция должна возвращать либо сообщение об ошибке, либо результат, а не одно со вторым вместе. (см. tagged/discriminated unions)
> Но так делать в таких случаях, тоже не панацея. Так как это метод класса — то самым правильным будет — добавить в этот класс методы SetError(errorType) и errorType GetLastError(). И использовать их во всех методах.
Это неудобно проверять, поэтому непрактично. Либо исключения, либо то, о чем я говорил выше (впрочем, в языках с нужными фичами одно можно выразить через другое). В Smalltalk тоже хорошо сделано, но перенять этот способ в PHP нельзя.
Тут еще такая фишка: FIELD_ERROR является ошибкой caller'а (вызывающего кода), а не callee (самой функции — с ней все в порядке), поэтому упасть должен именно он (вы ведь сами захотите узнать, откуда пришел вызов, чтобы исправить ошибку).
Пример нехороший, ошибка это побочный эффект, а функция должна возвращать либо сообщение об ошибке, либо результат, а не одно со вторым вместе. (см. tagged/discriminated unions)
> Но так делать в таких случаях, тоже не панацея. Так как это метод класса — то самым правильным будет — добавить в этот класс методы SetError(errorType) и errorType GetLastError(). И использовать их во всех методах.
Это неудобно проверять, поэтому непрактично. Либо исключения, либо то, о чем я говорил выше (впрочем, в языках с нужными фичами одно можно выразить через другое). В Smalltalk тоже хорошо сделано, но перенять этот способ в PHP нельзя.
Тут еще такая фишка: FIELD_ERROR является ошибкой caller'а (вызывающего кода), а не callee (самой функции — с ней все в порядке), поэтому упасть должен именно он (вы ведь сами захотите узнать, откуда пришел вызов, чтобы исправить ошибку).
> Всё зависит напрямую от архитектуры (и языка программирования). Можно (и нужно) использовать свойства там, где они есть, а методы, где нет свойств. :)
На самом деле это все (методы, свойства, аксессоры, etc.) ограничения языка. Передача сообщений должна быть, причем сообщение должно быть first-class value.
> В одних случаях, оправданно использовать public (без лишних перегрузок, когда необходимо просто сохранять/считывать значения структур), в других перегрузку операторов, в третьих — методы воздействия, в четвертых — свойства.
Немного не так. Есть ситуации, когда нужно знать структуру объекта (это просто данные), и есть ситуации, когда от данных нужно абстрагироваться.
Перегрузка операторов нужна для ad-hoc полиморфизма (специального полиморфизма). Это немного не то, что dynamic dispatch (полиморфизм в понимании ООП), но близко.
На самом деле это все (методы, свойства, аксессоры, etc.) ограничения языка. Передача сообщений должна быть, причем сообщение должно быть first-class value.
> В одних случаях, оправданно использовать public (без лишних перегрузок, когда необходимо просто сохранять/считывать значения структур), в других перегрузку операторов, в третьих — методы воздействия, в четвертых — свойства.
Немного не так. Есть ситуации, когда нужно знать структуру объекта (это просто данные), и есть ситуации, когда от данных нужно абстрагироваться.
Перегрузка операторов нужна для ad-hoc полиморфизма (специального полиморфизма). Это немного не то, что dynamic dispatch (полиморфизм в понимании ООП), но близко.
Буду категоричным. Несмотря на то что, да, на меня после этого свалится куча минусов. Статья ужасна.
Совсем непонятно, почему. Лично я думаю, что объяснение здесь высосано из пальца. Впрочем, объяснение в исходной статье тоже хромает, но она хотя бы есть.
А вот как показывает моя практика, не всегда это возможно делать. Да, я и сам стараюсь делать методы максимально компактными. Но иногда не выходит. Тут надо понимать, что нагородив методов, мы перейдём от спагетти в одном методе к спагетти из кучи непонятных private-методов. Да и не всегда методам удаётся дать внятное название, вот и получается набор методов вида DoMysteryousThing и DoSomeOtherMysteriousThing. Конечно, к ним можно подписать комментарии. Но! Почему бы тогда не написать всё в одном методе, разделив его этими самыми комментариями на логические блоки?
А вот тут автор вообще приводит абсурдный пример. Нехорошая это практика возвращать массив или bool. Тем более, это не прокатит в статически типизированных языках. А следующий пример — это возврат к тёмным временам C (поморщился). Вообще, если так уж нужно избежать выбрасывания исключения, то идеальное решение — вернуть структуру вроде Error, конкретизированную типом результата метода.
Мне не становится ясным ничуть. Вообще, своё мнение об уместности использования свойств я оставил в развёрнутом комментарии к исходной статье.
Вопрос к автору? А вы вообще осознаёте, что такое «функциональное программирование»? И при чём тогда OpenGL и «инициализация»?
Из приведённого ниже фрагмента кода вообще не ясно, почему не стоит делать, как он говорит. И, кстати, я бы этот код написал как-то так:
Да, как видите, не очень удобно. Зато не надо запоминать в какой последовательности надо передавать параметры. Хотя да, IDE зачастую в помощь. А вот читается код всё равно гораздо лучше. Разумеется, всё было бы ещё лучше, если бы были именованные параметры. Да, надо заметить, что обычно рисование происходит через некий «контекст», который хранится либо внутри самого объекта, через который производится рисование, либо передаётся параметром. Обычно этот контекст и содержит информацию о кистях, шрифтах, преобразованиях. Собственно, это то, про что автор хотел сказать в случае с OpenGL. Вот только к функциональному программированию это никак не относится. И с ООП, кстати, вполне себе уживается.
Если-бы я поставил $Result после проверки !$queryResource, то глазами пришлось-бы бегло перечитывать код в поисках типа этой переменной.
Совсем непонятно, почему. Лично я думаю, что объяснение здесь высосано из пальца. Впрочем, объяснение в исходной статье тоже хромает, но она хотя бы есть.
Поэтому, хороший программист первым делом избавится от излишнего кода, проделав простейший Рефакторинг каждого метода (особенно, когда они занимают 300 строчек), разбив его на более легкие методы и функции с ясными очевидными названиями.
А вот как показывает моя практика, не всегда это возможно делать. Да, я и сам стараюсь делать методы максимально компактными. Но иногда не выходит. Тут надо понимать, что нагородив методов, мы перейдём от спагетти в одном методе к спагетти из кучи непонятных private-методов. Да и не всегда методам удаётся дать внятное название, вот и получается набор методов вида DoMysteryousThing и DoSomeOtherMysteriousThing. Конечно, к ним можно подписать комментарии. Но! Почему бы тогда не написать всё в одном методе, разделив его этими самыми комментариями на логические блоки?
Возврат результата функции через ее параметр
А вот тут автор вообще приводит абсурдный пример. Нехорошая это практика возвращать массив или bool. Тем более, это не прокатит в статически типизированных языках. А следующий пример — это возврат к тёмным временам C (поморщился). Вообще, если так уж нужно избежать выбрасывания исключения, то идеальное решение — вернуть структуру вроде Error, конкретизированную типом результата метода.
Полностью классы я не привожу. Но уже становится ясным, по каким причинам стоит задуматься о том, каким методом пользоваться для изменения переменной. При всём при том, стоит задуматься о том, как ваш класс может использовать в многопоточных приложениях, или например, при работе с БД.
Мне не становится ясным ничуть. Вообще, своё мнение об уместности использования свойств я оставил в развёрнутом комментарии к исходной статье.
В функциональном программировании по хорошему счёту — разделяют на «атомарные» функции предварительной инициализации. Например — это реализовано в OpenGL. Но я приведу пример автора:
Вопрос к автору? А вы вообще осознаёте, что такое «функциональное программирование»? И при чём тогда OpenGL и «инициализация»?
А теперь о минусах подхода автора. Почему не стоит делать, как он говорит (в языках без поддержки именованных параметров):
Из приведённого ниже фрагмента кода вообще не ясно, почему не стоит делать, как он говорит. И, кстати, я бы этот код написал как-то так:
void DrawRectangle (RectangleInfo rectInfo)
{
var polyline = new Polyline();
polyline.Points = rectInfo.Rectangle.Corners.Select(pt => pt.ApplyTransformation(rectInfo.Transform));
polyline.Close = true;
polyline.Pen = rectInfo.Pen;
this.DrawPolyLine(polyline);
}Да, как видите, не очень удобно. Зато не надо запоминать в какой последовательности надо передавать параметры. Хотя да, IDE зачастую в помощь. А вот читается код всё равно гораздо лучше. Разумеется, всё было бы ещё лучше, если бы были именованные параметры. Да, надо заметить, что обычно рисование происходит через некий «контекст», который хранится либо внутри самого объекта, через который производится рисование, либо передаётся параметром. Обычно этот контекст и содержит информацию о кистях, шрифтах, преобразованиях. Собственно, это то, про что автор хотел сказать в случае с OpenGL. Вот только к функциональному программированию это никак не относится. И с ООП, кстати, вполне себе уживается.
Вообще, в последнем примере можно было написать и так:
polyline.Points = rectInfo.Rectangle.Corners; polyline.Transform = rectInfo.Transform
Вы для каждой функции Draw будете писать свой трансформ?
Нет, для каждой функции DrawFoo я буду писать свой FooInfo. И, кстати, автор и сам говорит об ущербности такого подхода. А что поделать?
Что поделать? Программисту — обязательно думать :), а не нестись реализовывать всё одним подходом.
Ваш вариант решения красив, но и в то-же время — наворочен.
Я предпочитаю не городить огород, особенно где не нужно передавать один и тот же параметр используя его в нескольких места.
Ваш код хорош, когда мы RectangleInfo передаём не только в DrawRectangle, а используем где-нибудь ещё. Реализация:
1) Присутствует ясность — сколько линий будут рисоваться. Что вообще происходит в функции.
2) Не производится лишних действий (и преобразований из пустого в порожнее).
3) Нет необходимости писать лишние методы/функции для трансформации.
Ваш вариант решения красив, но и в то-же время — наворочен.
Я предпочитаю не городить огород, особенно где не нужно передавать один и тот же параметр используя его в нескольких места.
Ваш код хорош, когда мы RectangleInfo передаём не только в DrawRectangle, а используем где-нибудь ещё. Реализация:
- void DrawRectangle (float x, float y, float length, float width)
- {
- Rectangle rect;
-
- rect.x1 = x - length/2;
- rect.y1 = y - height/2;
- rect.x2 = x + length/2;
- rect.y2 = y + height/2;
-
- this.DrawPolyLine(rect.x1, rect.y1);
- this.DrawPolyLine(rect.x2, rect.y1);
- this.DrawPolyLine(rect.x2, rect.y2);
- this.DrawPolyLine(rect.x1, rect.y2);
- this.ClosePolyLine(this.FILL);
- }
1) Присутствует ясность — сколько линий будут рисоваться. Что вообще происходит в функции.
2) Не производится лишних действий (и преобразований из пустого в порожнее).
3) Нет необходимости писать лишние методы/функции для трансформации.
Задача посложнее — есть 2 координаты, определяющие прямоугольник. Его надо повернуть на угол 45 градусов, отмасштабировать по оси Х в 2 раза (в любую сторону) и нарисовать.
Без структур.
Без структур.
Как вариант — добавить в метод два вызова:
rect.rotate(this.angle);
rect.zoom(this.zoom);
которые преобразуют координаты.
Почему вы мне запрещаете использовать структуры — я не понимаю.
rect.rotate(this.angle);
rect.zoom(this.zoom);
которые преобразуют координаты.
Почему вы мне запрещаете использовать структуры — я не понимаю.
Становится понятно, зачем нужны структуры и когда.
И почему в GDI многие функции доступны в одном варианте вызова (через координаты), а в OpenGL — в другом (через структуры).
И почему в GDI многие функции доступны в одном варианте вызова (через координаты), а в OpenGL — в другом (через структуры).
Я с вами полностью согласен.
В статье я придерживаюсь мнения, что всё зависит от поставленной задачи, и шаблонов «как надо делать» нет.
И тот и другой способы действенны, но не нужно превращать код в фарс (описывая всё по шаблонам) делая лишнее, когда в этом нет необходимости :).
В статье я придерживаюсь мнения, что всё зависит от поставленной задачи, и шаблонов «как надо делать» нет.
И тот и другой способы действенны, но не нужно превращать код в фарс (описывая всё по шаблонам) делая лишнее, когда в этом нет необходимости :).
Вот такой вот вариант:
- void DrawRectangle (Rectangle rect)
- {
- this.DrawPolyLine(rect.point1);
- this.DrawPolyLine(rect.point2);
- this.DrawPolyLine(rect.point3);
- this.DrawPolyLine(rect.point4);
- this.ClosePolyLine(this.FILL);
- }
-
- //...
- Color cl1, cl2;
- Rectangle rect;
-
- cl1.RGB(255, 1, 1);
- cl1.Alpha(20);
- drawer.ForegoundColor(cl1);
-
- cl2.RGBA(1, 1, 255, 255);
- drawer.FillColor(cl2);
-
- rect.CoordinatesWH(x, y, width, height);
- rect.Rotate(angle);
- rect.Zoom(zoom);
-
- drawer.DrawRectangle(rect);
Я ошибся. У нас в этом случае будут использоваться 4 координаты. Но смысл, я думаю, ясен.
Объявление всех переменных в начале программы
function sql2array($query, $field=false, &$error=NO_ERROR) {
$Result = array();
$queryResource = $this->query($query);
if (!$queryResource){
$error = QUERY_ERROR;
return false;
}
Для возврата ошибок сущетсвует станрный механизм try catch exception
И приведенный Вами следовало бы переписать следующим образом
function sql2array($query, $field=false, &$error=NO_ERROR) {
$Result = array();
$queryResource = $this->query($query);
if (!$queryResource) throw new Query_Error_Exception("Error description", Error_Code);
>В следующем примере, ясно видно, что функция возвращает array():
>function sql2array($query, $field=false) {
> $Result = array();
Во-первых по названию функции и так понятно что она возвращает.
Во-вторых у вас она возвращает еще и bool, чего не видно ни по названию, ни по объявленной переменной $result.
В-третьих — ваша функция может перестать выполняться до использования $result — зачем же под него выделять память в начале?
>function sql2array($query, $field=false) {
> $Result = array();
Во-первых по названию функции и так понятно что она возвращает.
Во-вторых у вас она возвращает еще и bool, чего не видно ни по названию, ни по объявленной переменной $result.
В-третьих — ваша функция может перестать выполняться до использования $result — зачем же под него выделять память в начале?
Пример 1:
Автор не правильно понял утверждение.
$Result = array(); не являет строго локальной переменной, да и т.к. она возвращается, то область видимости переменной уже будет не локальная.
Поэтому пример наоборот показывает правильность определение возвращаемой переменной в самом начале кода. К этому примеру я бы еще добавил, что return должен быть всегда один(за редким исключением).
В изначальном утверждение имелось ввиду временные переменные для некоторых блоков функции, или циклов.
Пример 2:
Я уже лет 5-7 с пхп не имел дело, но какое там многопоточное программирование простите? Да и даже если оно было, то установка функция присвоения далеко не атомарна. Да и вообще тут метод get с локальной переменной, где тут concurrency?
Автор правильно подметил, что надо использовать обработку исключений.
Пример 3:
Тут думаю надо задуматься об ООП и архитектуре, потому что если есть те вопросы, которые там задаются, то зачем вообще тогда городить такой код ??? Да и опять причем тут многопоточность? где тут синхронизации(х3 возможны ли они в пхп ?) и присвоение переменной какого-либо значения не является атомарной во многих языках программирования.
пример Про дублирование данных:
любой дубликат кода в ООП исходит из плохой архитектуры(даже при оптимизации). только за редким исключением это не так.
Автор не правильно понял утверждение.
$Result = array(); не являет строго локальной переменной, да и т.к. она возвращается, то область видимости переменной уже будет не локальная.
Поэтому пример наоборот показывает правильность определение возвращаемой переменной в самом начале кода. К этому примеру я бы еще добавил, что return должен быть всегда один(за редким исключением).
В изначальном утверждение имелось ввиду временные переменные для некоторых блоков функции, или циклов.
Пример 2:
Я уже лет 5-7 с пхп не имел дело, но какое там многопоточное программирование простите? Да и даже если оно было, то установка функция присвоения далеко не атомарна. Да и вообще тут метод get с локальной переменной, где тут concurrency?
Автор правильно подметил, что надо использовать обработку исключений.
Пример 3:
Тут думаю надо задуматься об ООП и архитектуре, потому что если есть те вопросы, которые там задаются, то зачем вообще тогда городить такой код ??? Да и опять причем тут многопоточность? где тут синхронизации(х3 возможны ли они в пхп ?) и присвоение переменной какого-либо значения не является атомарной во многих языках программирования.
пример Про дублирование данных:
любой дубликат кода в ООП исходит из плохой архитектуры(даже при оптимизации). только за редким исключением это не так.
Нет такого понятия в программировании — оптимальное решение. Есть Приемленые решения и НЕ Приемленые решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Палка о двух концах или ещё раз о хрупкости кода