Pull to refresh

Comments 91

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

К примеру, функция, выполняющая слияние двух отсортированных массивов на 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;
}


Какой вариант легче читается, а следовательно легче поддерживается и меньше шансов допустить ошибку?
UFO just landed and posted this here
Видимо, я не очень удачный пример выбрал. Ну суть в том, что если в коде часто встречается «someArray.Length», то можно заменить его на «n». И читать, и писать код будет удобнее.
блин, ну someArrayLength тогда. Просто вам хотели сказать, что если вы много раз в коде бездумно считываете некоторое свойство, то можно попасть, если это ресурсоемкий геттер. В случае длинны массива не так очевидно, ну а если допустим есть объект со свойством числового типа, а также свойством, содержащим факториал данного числа. :)
В предыдущем посте как раз были обсуждения геттеров и их ресурсоемкости.

It depends, короче. Тот же foreach, например, оптимизирует вызов, так что геттер на Length вызывается 1 раз.
> геттер на Length вызывается 1 раз

Блин, а мы спорили… Спасибо.
А почему нет? Точно также, как и в случае с i, j понятно, что это счётчики цикла. Я считаю, что длина имени идентификатора должна быть адекватна его цели. В общем случае длина должна быть пропорциональна области видимисти идентификатора. Локальные переменные в функциях вполне можно называть однобуквенными именами.
ага, а как придется отрефакторить свой же код (который, кстати вообще без комментов, так как делался в перманентной спешке) через полгода придется детально разбираться, что это за такие красивые одно-двух буквенные «штучки». i да j — оно классичненько, для for. Но не панацея.
Ну суть в том, что если в коде часто встречается «someArray.Length», то можно заменить его на «n». И читать, и писать код будет удобнее.

в подавляющем большинстве случаев за вас это сделает компилятор ;)
В данном случае я говорил не про эффективность, а про читабельность кода. Компилятор же не будет менять текст в исходном файле.
применительно к данному примеру согласен. читать и писать удобнее
Если я правильно понимаю, то первый вариант предпочтительней использовать ещё и потому, что операция получения длинны массива занимает больше времени, чем получение значения переменной. Т.е. первый код должен работать быстрее.
>Если функция работает с массивом и в ней содержится много обращений к длине массива, то проще
>сохранить длину в отдельной переменной с коротким и понятным именем, например n.

Офигительно понятное имя! :)
Вы просто не работали с функциональными языками :)
UFO just landed and posted this here
По-моему, право на существование имеет только i и то в редких случаях.
Неужели так сложно назвать переменную nArrayLen? Польза ведь очевидна — говорить о назначении переменной будет ее имя, а не алгоритм, в котором она используется.
UFO just landed and posted this here
В чём польза длинных имён для локальных переменных функции? Вы думаете, что если счётчик цикла назвать loopCounter вместо i, то от этого повысится читабельность кода? Мне кажется наоборот придётся читать много лишних букв.
Вот и вторая сторона именования. Я тоже, когда пытался всё именовать в локальных функциях «по правилам» заметил, что порой такие вещи ухудшают чтение.

По этому, для себя я решил использовать именование таких переменных односложными простыми именами. Потипу name, i, x, result, request итд.
Возврат через параметр — это для языков, которые не поддерживают кортежи (tuple). Кортежи как раз для того и придумали, чтобы можно было:

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 есть, но с ним страшновато выглядит :)
окей :) меня смутил сильно похожий синтаксис и то что я не знаю ни одного языка, где кортежи звались бы tuples, кроме питона :)
псевдокод слишком императивен чтобы быть эрлангом
Не, я про то что есть еще языки где кортежи называют tuples =)
А эрланг слишком императивен, что бы быть функциональным в классическом понимании этого определения.
Я угадаю эту мелодию с 3х нот? ;)
или хаскелем )
Ну, если мы говорим о двух параметрах, в C++ есть стандартный std::pair.

std::pair<int, std::string> a = foo(bar);
кортеж — фактически — неизменяемый список значений
В следующем примере, ясно видно, что функция возвращает array():

function sql2array($query, $field=false) {
$Result = array();


function sql2array($query, $field=false) {
$Result = null;

А в этом примере ясно видно, что функция возвращает null :)

Пользуйтесь phpDoc. Оно в разы эффективнее :)

Может и еще по нескольким вопросам похоливарил бы, только бесполезно это все :) Мне ближе точка зрения автора предыдущего топика. там я вроде только по 1-2 пунктам имел возражения. И также как и он люблю js :)
Извините, пример просто не совсем удачный я выбрал. То, что я здесь описал, не касается конкретно PHP.

Например, в C/C++ ясно будет видно, что мы возвращаем.
И опять неудачный пример. В С++ мы описываем возвращаемый тип в сигнатуре функции:

int Sum(int a, int b) — как-то так :)
Пример и правда не совсем удачный. Но об этом я и хотел сказать.

В PHP я просто стараюсь делать максимально говорящие переменные. И определять в начале явно не null (если они возвращают array()). Просто для того, чтобы было яснее происходящее c первых строчек кода метода/функции.

В некоторых случаях это не работает — тогда уже (как было сказанно ниже), деклорации @return (и другие хелперы) спасут программистов :).
Просто для того, чтобы было яснее происходящее c первых строчек кода метода/функции.

Происходящее должно стать понятным не при просмотре текста функции, а по подсказке редактора кода, там где эту функцию вызывают. Смотреть как объявлены служебные переменные, чтобы понять, что возвратит функция — сори конечно, но это бред.
Одно из другого не вытекает, сами понимаете. Если я использую phpDoc, мне ничего не мешает писать понятным языком тело функций.
Нет конечно. Но специально выносить декларацию переменных в неудобное место ради неясных целей — это не есть понятный язык для тела функции. Переменная должна быть объявлена там, где это удобно. И если код хорошо задокументирован, то этому вообще ничего не мешает — никакие уловки насчет $result = array();

В общем, я хочу, чтобы вы отказались от своего первого возражения :) Остальные — вполне объяснимы и понятны.
Зря вы так. Всякие *Doc это конечно хорошо, но требует дополнительных затрат, а в данном случае у нас код сам себя документирует. ИМХО, это полезно, а в случае VB, например, еще и предохраняет от определенного вида ошибок.
а в данном случае у нас код сам себя документирует


Нет. Документированный код — это такой код, в котором без всяких домыслов понятно — что делает этот код. Назвать переменную «Result» и присвоить ей массив в самом начале — это не документация. У типизированных языков — что возвращает функция указывается в коде. У любого нетипизированного языка всегда есть чтото вроде phpDoc(jsDoc), который и помогает нам преодолеть вышеописанные проблемы.
Приведенный для пхп пример, согласен, не очень красив.
1) У некоторых типизированных языков есть тип Variant (или что-то типа того), который иногда приходится применять.
2) Поверьте, не у любого)
Это оправданные затраты. Нормальная IDE, типа Eclipse, при наведении на метод будет показывать его описание из PHPDoc, например. И вообще, это полезно: сначала написать комментарий, а потом написать код, т.к. сначала думаешь, а потом делаешь.
Как видите, функция теперь возвращает два параметра — это $error — статус выполнения функции и массив, в случае правильного выполнения.
============
В таком случае, лучше использовать Exception и его дальнейшую обработку
При условии, конечно, если оно доступно в языке/среде разработки
А в php 4.0 вобще можно возвращать «кортеж» в первом из которых статус выполнения функции, а во втором сам результат. И делить его при помощи list…
function sql2array($query, $field=false) {
  $Result = array();
  if [...] {
    return false;
  }
  [...]
  return $Result;
}
</code>
это тоже путь темной стороны. Даже если язык позволяет, функция не должна возвращать значения разных типов в зависимости от пути выполнения - уж лучше кинуть эксепшн.
Не соглашусь. Это зависит от архитиктуры.

Граблей этим мы не плодим, и куда приятнее и нагляднее в PHP сравнивать get_length(...) не с -1, а с false.
Не знаю такую функцию get_length, но вот count выдает интересные значения, на которые многие новички натыкаются…

<?php
$s = false;
echo count($s);

$s = array();
echo count($s);
А я и не говорю про функцию в PHP. Ну а перед тем, как использовать count стоит сначала проверить на false.
  1. $result=find(...);
  2. if ($result !== false){
  3.         //...
  4. }
Программирование это уже не как раньше. Десяток языков и кругом задач в 20-30 направлениях. Программирование это уже целая отрасль с огромных количеством языков и направлений.
Было бы странно видеть проектировщика электросетей который спорит с архитектором, как именно ставить размеры на чертежах.
Так и в программирование, под каждое направление определяется свой набор правил. Главное чтобы эти правила было обдуманными и логичными.
при сложности возвращаемого значения оборачивайте функцию в обьект.

и пусть результаты будут доступны как свойства обьекта.
Главное — не переборщить. Иначе из калькулятора получится монстр
UFO just landed and posted this here
будто ты не читал гайды про исключения… не везде исключения хорошая практика. Пример функция FileExists с доп. выходным параметром «bool canWriteThisFile».
Хмм… Это в каком языке такая конструкция? Функция должна делать только, то как она называется. Если функция проверки существования файла еще показывает, можно ли в него что-то писать это, извиняюсь, говнокод.
Скорее всего тут необходимо привести пример из C#: bool Int32.TryParse(string s, out int result), вот тут исключения как раз — плохая идея.
ну я просто пример привел, когда неуместны исключения. Вы подобрали гораздо более хороший и реальный пример.
> В следующем примере, ясно видно, что функция возвращает array():
Надо не объявлять $Result в начале функции а написать толковый комментарий:
/**
* Returns query result as array
*
* @param string $query
* @param bool $field
* @return array;
*/

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

С предыдущим автором согласен — переменные должны быть там, где они нужны!
«Доступ к свойствам объекта»… ИМХО должны быть set\get методы, если set подразумевает какую-то логику работы (например ресайз массива или влияние на значение других property или возвратов функций).

Если логики особой нет, то и городить два метода (в случае поддержки property) не имеет большого смысла…
ой, сори не туда написал.
> Если-бы я поставил $Result после проверки !$queryResource, то глазами пришлось-бы бегло перечитывать код в поисках типа этой переменной.

Если бы вы добавили в код больше структуры, вот так:

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).

Только это не поможет, если необходимо возвращать несколько значений.

Более-менее интерестный вариант рассмотрен здесь. Но опять, не универсальный — имеет ряд преимуществ и недостатков.
Вот, кстати, верно подмечено в исходной статье (я тоже заметил, но как-то комментарий не написал): если автор так борется за красоту кода, то о каких 300 строчках кода в одной функции может идти речь?
> Как видите, функция теперь возвращает два параметра — это $error — статус выполнения функции и массив, в случае правильного выполнения.

Пример нехороший, ошибка это побочный эффект, а функция должна возвращать либо сообщение об ошибке, либо результат, а не одно со вторым вместе. (см. tagged/discriminated unions)

> Но так делать в таких случаях, тоже не панацея. Так как это метод класса — то самым правильным будет — добавить в этот класс методы SetError(errorType) и errorType GetLastError(). И использовать их во всех методах.

Это неудобно проверять, поэтому непрактично. Либо исключения, либо то, о чем я говорил выше (впрочем, в языках с нужными фичами одно можно выразить через другое). В Smalltalk тоже хорошо сделано, но перенять этот способ в PHP нельзя.

Тут еще такая фишка: FIELD_ERROR является ошибкой caller'а (вызывающего кода), а не callee (самой функции — с ней все в порядке), поэтому упасть должен именно он (вы ведь сами захотите узнать, откуда пришел вызов, чтобы исправить ошибку).
Мне вообще не нравится, когда функция может возвращать либо результат, либо ошибку. Ошибка должна обрабатываться общим механизмом исключений, а не отдельно после каждого вызова функции.
> Мне вообще не нравится, когда функция может возвращать либо результат, либо ошибку

Почитайте о discriminated unions, я о них говорю. Динамическая типизация PHP позволяет, конечно, возвращать «либо то, либо это, либо вообще что-то с потолка», но это другое совсем, ортогонально к вопросу.
> Всё зависит напрямую от архитектуры (и языка программирования). Можно (и нужно) использовать свойства там, где они есть, а методы, где нет свойств. :)

На самом деле это все (методы, свойства, аксессоры, etc.) ограничения языка. Передача сообщений должна быть, причем сообщение должно быть first-class value.

> В одних случаях, оправданно использовать public (без лишних перегрузок, когда необходимо просто сохранять/считывать значения структур), в других перегрузку операторов, в третьих — методы воздействия, в четвертых — свойства.

Немного не так. Есть ситуации, когда нужно знать структуру объекта (это просто данные), и есть ситуации, когда от данных нужно абстрагироваться.

Перегрузка операторов нужна для ad-hoc полиморфизма (специального полиморфизма). Это немного не то, что dynamic dispatch (полиморфизм в понимании ООП), но близко.
Буду категоричным. Несмотря на то что, да, на меня после этого свалится куча минусов. Статья ужасна.

Если-бы я поставил $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. void DrawRectangle (float x, float y, float length, float width)
  2. {
  3.     Rectangle rect;
  4.  
  5.     rect.x1 = x - length/2;
  6.     rect.y1 = y - height/2;
  7.     rect.x2 = x + length/2;
  8.     rect.y2 = y + height/2;
  9.    
  10.     this.DrawPolyLine(rect.x1, rect.y1);
  11.     this.DrawPolyLine(rect.x2, rect.y1);
  12.     this.DrawPolyLine(rect.x2, rect.y2);
  13.     this.DrawPolyLine(rect.x1, rect.y2);
  14.     this.ClosePolyLine(this.FILL);
  15. }

1) Присутствует ясность — сколько линий будут рисоваться. Что вообще происходит в функции.
2) Не производится лишних действий (и преобразований из пустого в порожнее).
3) Нет необходимости писать лишние методы/функции для трансформации.
Задача посложнее — есть 2 координаты, определяющие прямоугольник. Его надо повернуть на угол 45 градусов, отмасштабировать по оси Х в 2 раза (в любую сторону) и нарисовать.

Без структур.
Как вариант — добавить в метод два вызова:
rect.rotate(this.angle);
rect.zoom(this.zoom);
которые преобразуют координаты.

Почему вы мне запрещаете использовать структуры — я не понимаю.
Становится понятно, зачем нужны структуры и когда.

И почему в GDI многие функции доступны в одном варианте вызова (через координаты), а в OpenGL — в другом (через структуры).
Я с вами полностью согласен.
В статье я придерживаюсь мнения, что всё зависит от поставленной задачи, и шаблонов «как надо делать» нет.
И тот и другой способы действенны, но не нужно превращать код в фарс (описывая всё по шаблонам) делая лишнее, когда в этом нет необходимости :).
Вот такой вот вариант:
  1. void DrawRectangle (Rectangle rect)
  2. {
  3.     this.DrawPolyLine(rect.point1);
  4.     this.DrawPolyLine(rect.point2);
  5.     this.DrawPolyLine(rect.point3);
  6.     this.DrawPolyLine(rect.point4);
  7.     this.ClosePolyLine(this.FILL);
  8. }
  9.  
  10. //...
  11. Color cl1, cl2;
  12. Rectangle rect;
  13.  
  14. cl1.RGB(255, 1, 1);
  15. cl1.Alpha(20);
  16. drawer.ForegoundColor(cl1);
  17.  
  18. cl2.RGBA(1, 1, 255, 255);
  19. drawer.FillColor(cl2);
  20.  
  21. rect.CoordinatesWH(x, y, width, height);
  22. rect.Rotate(angle);
  23. rect.Zoom(zoom);
  24.  
  25. 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 — зачем же под него выделять память в начале?
Пример 1:
Автор не правильно понял утверждение.
$Result = array(); не являет строго локальной переменной, да и т.к. она возвращается, то область видимости переменной уже будет не локальная.
Поэтому пример наоборот показывает правильность определение возвращаемой переменной в самом начале кода. К этому примеру я бы еще добавил, что return должен быть всегда один(за редким исключением).
В изначальном утверждение имелось ввиду временные переменные для некоторых блоков функции, или циклов.
Пример 2:
Я уже лет 5-7 с пхп не имел дело, но какое там многопоточное программирование простите? Да и даже если оно было, то установка функция присвоения далеко не атомарна. Да и вообще тут метод get с локальной переменной, где тут concurrency?
Автор правильно подметил, что надо использовать обработку исключений.
Пример 3:
Тут думаю надо задуматься об ООП и архитектуре, потому что если есть те вопросы, которые там задаются, то зачем вообще тогда городить такой код ??? Да и опять причем тут многопоточность? где тут синхронизации(х3 возможны ли они в пхп ?) и присвоение переменной какого-либо значения не является атомарной во многих языках программирования.
пример Про дублирование данных:
любой дубликат кода в ООП исходит из плохой архитектуры(даже при оптимизации). только за редким исключением это не так.
Нет такого понятия в программировании — оптимальное решение. Есть Приемленые решения и НЕ Приемленые решения.
Займитесь лучше делом :)
UFO just landed and posted this here
Sign up to leave a comment.

Articles