95% от заявленного объёма торгов Биткоина оказались фейком

Вы не поняли о чём я. На карточке написано EUR. Это основная валюта карты. Не биткоин, а доллар, рубль или евро. Совершив покупку рублёвым cryptopay'ем в Европе вы получите списание со своей карты в рублях. В рублях, а не в биткоинах. Потому что платить биткоинами не удобно, да и не дёшево. Поэтому биткоиновых карт нет и никогда не будет (если только кто-то не захочет принципиально опровергнуть это утверждение за свои собственные деньги).

Как отметил чуть ниже EgorKotkin, "средство платежа должно быть платёжеспособным", а в глазах большинства людей планеты Земля биткоин (в лучшем случае) конвертируемое средство, но не платёжеспособное. Заплатить биткоинами за чью-то недвижимость можно, в подавляющем большинстве случаев, только переведя биткоины во что-то более платёжеспособное — безнал, например, или хотя бы в цистерны соляры. Лишь очень небольшая доля процента может согласиться и на оплату биткоинами. Но… "Узок круг этих революционеров. Страшно далеки они от народа." (с) В. И. Ульянов (Ленин).

95% от заявленного объёма торгов Биткоина оказались фейком

У вас чёрно-белый взгляд на мир. Со временем это проходит.

95% от заявленного объёма торгов Биткоина оказались фейком

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

95% от заявленного объёма торгов Биткоина оказались фейком

Средство платежа должно быть надёжным, удобным и дешёвым. А то, что торгуется на биржах — это (а) ресурсы, (б) ожидания (товар для спекуляций). Вот когда появится первая биткоиновая карточка, которой я смогу расплатиться в магазине, вот тогда биткоин из второй категории переместится в первую. А пока что на биржах оценивается вера людей в биткоин. Хорошие люди хорошо верят в биткоин, плохие — плохо. Ужасные — не верят, вообще. Для того, чтобы верить в биткоин нужны деньги. У хороших людей с деньгами всё хорошо, у плохих — плохо. А когда у человека есть деньги, но он не покупает биткоин — это просто ужасно. Для биткоина. И для хороших людей, у которых с биткоином всё хорошо.

Debug Oriented Programming или печаль в глазах Интегратора

Согласен, несколько неточно. Нужно говорить о модифицируемости кода, а не о читабельности.

Debug Oriented Programming или печаль в глазах Интегратора

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

Если код легко править — он читабельный? А вот это, пожалуй, верное направление мысли. Меняются требования, добавляются функции, возникают ошибки — и в какой-то момент кому-то приходится править ваш код. А чтобы при этом не породить новые проблемы, разработчику нужно понимать, что конкретно он редактирует и как правки изменят поведение кода. Итак, мы нашли новое эвристическое правило: читабельный код должен легко редактироваться.

Debug Oriented Programming или печаль в глазах Интегратора

Код разбивается на классы/процедуры/функции не потому, что человек не может прочесть 2К строк подряд
Как раз таки именно потому! Прочитать код на 2к строк человек может

не находите противоречия?

где сайты представляли собой свалку файлов .php в корневой директории.

это ваше неверное представление о "ламповых" 2010-х, как неверно и ваше представление о том, что в свалке "легко менять" (возьмите на себя поддержку такой свалки хотя бы на пару лет).

У меня к вам такой неловкий вопрос…

У меня в профиле написаны языки, с которыми я имел дело. Magento использует Zend и Symfony для CLI. За Phalcon на могу ничего сказать — вообще не трогал. Laravel смотрел, но не более. Есть ещё неловкие вопросы?

Debug Oriented Programming или печаль в глазах Интегратора

А для чего вам понимание кода?

Debug Oriented Programming или печаль в глазах Интегратора

Правильно, потому что чья-то "религия" позволяет ставить return'ы где ни попадя, а чья-то нет. В результате имеем микс. С одной точкой возврата получится такая вложенность по if'ам, что придётся разбивать проверку на связные части. Придётся делать код, более устойчивый к модификациям, т.к. придётся глубже нырять в предметную область и лучше понимать её. Поставить ещё один return гораздо проще.

Debug Oriented Programming или печаль в глазах Интегратора

Я всего лишь переработал ваш код с $result'ами. Вы могли и его сделать чуть более красивым ;)

Debug Oriented Programming или печаль в глазах Интегратора

Вы правы, читаю я чаще, чем изменяю. Но читаю я именно для того, чтобы понять, где и что мне нужно изменить (или что здесь ничего менять не нужно). Код разбивается на классы/процедуры/функции не потому, что человек не может прочесть 2К строк подряд ("Войну и Мир" многие осилили). А для того, чтобы ограничить влияние изменений, особенно неправильных. Так что говорить, что мы пишем код для того, чтобы его читать — в корне не верно. Мы читаем, чтобы понимать. А понимаем, чтобы изменять. В противном случае было бы достаточно один раз написать код и один раз тесты к нему. Поэтому код должен быть не легко читаем, а легко изменяем. Кстати, удобнее читать код, который написан в одном файле, чем скакать от файла к файлу и обратно.

Debug Oriented Programming или печаль в глазах Интегратора

А вот за это — спасибо! Попробую.

Debug Oriented Programming или печаль в глазах Интегратора

В таком случае ставьте return'ы — я буду дебажить с первой строки метода. Со временем ваш код может превратиться в подобие этого:

сэволюционировавший код

public function isApplicable()
{
    $p = $this->getProduct();
    if (!$p) {
        return false;
    }
    // has image for the current mode
    if (!$this->getValue('img'))
        return false;
    $now = Mage::getModel('core/date')->date();
    if ($this->getDateRangeEnabled() && ($now < $this->getFromDate() || $now > $this->getToDate())) {
        return false;
    }
    // individula products logic
    $inArray = in_array($p->getSku(), explode(',', $this->getIncludeSku()));
    if (!$p->getSku())
        $inArray = false;
    // include skus
    if (0 == $this->getIncludeType() && $inArray)
        return true;
    // exclude skus
    if (1 == $this->getIncludeType() && $inArray)
        return false;
    // use for skus only
    if (2 == $this->getIncludeType())
        return $inArray;

    if ($this->getPriceRangeEnabled()) {
        switch ($this->getByPrice()) {
            case '0': // Base Price
                $price = $p->getPrice();
                break;
            case '1': // Special Price
                $price = $p->getSpecialPrice(); // or $this->_info['special_price']
                break;
            case '2': // Final Price
                $price = Mage::helper('tax')->getPrice($p, $p->getFinalPrice());
                break;
            case '3': // Final Price Incl Tax
                $price = Mage::helper('tax')->getPrice($p, $p->getFinalPrice(), true);
                break;
            case '4': // Starting from Price
                $price = $this->_getMinimalPrice($p);
                break;
            case '5': // Starting to Price
                $price = $this->_getMaximalPrice($p);
                break;
        }
        if ($p->getTypeId() == 'bundle'){
            $priceMin = $p->getMinPrice();
            $priceMax = $p->getMaxPrice();
            if ($priceMin < $this->getFromPrice() && $priceMax > $this->getToPrice()) {
                return false;
            }
        }
        else if ($price < $this->getFromPrice() || $price > $this->getToPrice()) {
            return false;
        }
    }
    $attrCode = $this->getAttrCode();
    if ($attrCode) {
        if (!array_key_exists($attrCode, $p->getData())) { // has attribute condition
            return false;
        }
        // compatibility with the `Amasty: Custom Stock Status` extension
        // if the `Use Quantity Ranges Based Stock Status` property setted to `Yes`
        // so the value of the `Custom Stock Status` is dynamic
        // and setted to the product value is not used
        if (('custom_stock_status' === $attrCode) && (Mage::helper('core')->isModuleEnabled('Amasty_Stockstatus'))) {
            if ($this->getAttrValue() != Mage::helper('amstockstatus')->getCustomStockStatusId($p)) {
                return false;
            }
        } elseif ($this->getAttrValue()) {
            $v = $p->getData($attrCode);
            if (preg_match('/^[0-9,]+$/', $v)){
                if (!in_array($this->getAttrValue(), explode(',', $v))){
                    return false;
                }
            }
            elseif ($v != $this->getAttrValue()){
                return false;
            }
        } elseif (!$p->getData($attrCode)) { // sometimes needed for has attribute condition too
            return false;
        }
    }
    $catIds = $this->getCategory();
    if ($catIds) {
        $ids = $p->getCategoryIds();
        if (!is_array($ids))
            return false;
        $found = false;
        foreach (explode(',', $catIds) as $catId) {
            if (in_array($catId, $ids))
                $found = true;
        }
        if (!$found)
            return false;
    }
    $stockStatus = $this->getStockStatus();
    if ($stockStatus){
        $inStock = $p->getStockItem()->getIsInStock() ? 2 : 1;
        if ($inStock != $stockStatus)
            return false;
    }
    if ($this->getIsNew()){
        $isNew = $this->_isNew($p) ? 2 : 1;
        if ($this->getIsNew() != $isNew)
            return false;
    }
    if ($this->getIsSale()){
        $isSale = $this->_isSale() ? 2 : 1;
        if ($this->getIsSale() != $isSale)
            return false;
    }
    if ($this->getCustomerGroupEnabled() && ('' === $this->getCustomerGroups() || // need this condition, because in_array returns true for NOT LOGGED IN customers
        (!in_array(Mage::getSingleton('customer/session')->getCustomerGroupId(), explode(',', $this->getCustomerGroups())))))
        return false;
    // finally ...
    return true;
}

И это сделаете не вы, а те, кто будет модифицировать ваш код после вас.

Debug Oriented Programming или печаль в глазах Интегратора

Не знаю, у меня не получается. Научите. Я под IDEA работаю (PhpStorm).

Debug Oriented Programming или печаль в глазах Интегратора

PhpStorm. По F9 открывается debug-меню:

Debug Oriented Programming или печаль в глазах Интегратора

А я пишу код для того, чтобы его изменять. Изменять код буду я сам и мои коллеги. Изменяемость написанного кода — вот это "наше всё!" Я читал в детстве некоторые образчики perl-кода — ничего не понятно, но красиво-о-о. Занимательное чтиво.

Debug Oriented Programming или печаль в глазах Интегратора

Если вы пишите код для того, чтобы его читать, то да — так удобнее. Особенно, если для вас замена $result на return превращает ктулху-гирлянду в true-code-гирлянду:

function foo($baz)
{
    if ($baz < 0) {
        return 0;

    } else if ($baz > 100 && $baz <= 1000) {
        return do_f1();

    } else if ($baz > 1000 && $baz <= 10000) {
        return  do_f2();

    } else if ($baz > 10000 && $baz <= 100000) {
        return  do_f3();

    } else {
        return  do_f4();

    }
}

Лично у меня return из начала-середины метода вызывает ассоциации только с goto.

Debug Oriented Programming или печаль в глазах Интегратора

Делая ранний ретурн — ты гарантируешь что логика метода только про это.

Делать единственный возврат — вот это гарантия, что логика метода только про это. Ваш пример, переписанный для одной точки возврата:

if ($cond){
    //...
    $res = 'value';
} else {
    //...
}
return $res;

Такой подход заставляет читать код метода до конца, а не до первого return'а, и понимать его во всей полноте, а не только "основную логику" (или "наиболее часто встречающуюся"? или "самую тривиальную"? — что там обычно первым возвратом ставят?).

я не буду писать хорошо

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

Debug Oriented Programming или печаль в глазах Интегратора

Не используй код код который...

Отличный совет! Жаль, что интеграторы не могут им воспользоваться.

Debug Oriented Programming или печаль в глазах Интегратора

Согласен со всем, кроме:

2) читаемость кода важнее удобности дебага. Единый ретурн ухудщает читаемость.
У тебя есть метод. в определенный моент он ветвится. Психологически легче быстро отработать короткий случай и забыть о нем.

При чтении кода возврат в третей-пятой строке кода не отменяет необходимости читать метод до конца, чтобы его понять. Это при отладке можно выскочить на третей-пятой строке по return'у и не парится, что там далее (если условия так сработали), а для понимания всего метода нужно читать метод целиком. В таком случае

....
$result = 1234;
...
return $result;

ненамного хуже для читабельности, чем

...
return 1234;
...

если, разумеется, использовать для возврата переменную $result по-умолчанию. К тому же единая точка возврата дисциплинирует, заставляя надёжнее изолировать различные результаты через if-else, что весьма пригождается при рефакторинге. Но это мне мой опыт так говорит, у вас он может быть другим.