Обновить
24
0
Голованов Владимир@Colwin

Senior Java Developer

Отправить сообщение
Думаю, Вы правы, мало приятного, когда смотрят, как ты работаешь.
Так что если результат хороший или даже удовлетворительный — лучше пользоваться другими мерами, чем заглядывание в код со спины.
4. и 5. — очень хорошие ходы ) учат думать.
Обычно это люди, которые выбирают профессию программиста ради большой ЗП.
Соответственно, обычно они не мотивированы к обучению вообще, и являются кодерами ниже среднего уровня. IMHO, таких людей надо увольнять. Объясняя при этом, что они пытаются заниматься не своим делом.
Кстати, не только программисты этм грешат.
Видел я и CSS-файлы на 4000 строк…
ДО сборки, есс-но. Вся верстка в одном файле.
Да почему ж ) мне лично симпатизирует подход с выводом типов, когда не нужно их везде описывать, где можно понять из контекста. Однако при это необходима строгая типизация, чтобы при двусмысленном результате требовалось явное типизирование. Тогда проблем не будет, только плюсы.
По поводу длины имен.
Не помню, кто сказал:

Длина имени должна быть прямо пропорциональна размерам области видимости.
Автоматическое форматирование, конечно, помогает, но не во всем, увы.
Некоторые вещи после автоформатрования приходится доформатировать ручками, ибо иначе плохо читается.
Могу показать пример кода (довольно большой!), где нет ни единой строчки комментариев, однако он очень хорошо читается.
List, а не Lisp.
Даже если находится в критической секции ) Ибо всегда может найтись тот, кто чихать хотел на наши усилия по синхронизации (как правило, по незнанию).
Код не является потокобезопасным.

Вот пример:

template<class TYPE>
void LockFreeQueue2<TYPE>::Enqueue(TYPE* data)
{
...
    if (writerTop) // Если очередь Писателя уже существует, добавляем елемент в ее конец
    {
        // Здесь сейчас первый поток
        writerBottom->next = data;
        writerBottom = data;
    }
...
}

template<class TYPE>
bool LockFreeQueue2<TYPE>::Dequeue(volatile TYPE*& data)
{
...
         if (isWriterFinished && writerTop) // Проверяем Писетельскую очередь, если он закончил свою работу
        {
            readerTop = writerTop;
            // Здесь сейчас второй поток
            writerTop = NULL;
        }
}

template<class TYPE>
bool LockFreeQueue2<TYPE>::Flush()
{
    ...
    if (!readerTop) // Проверяем можно ли сбросить Читателю свой остаток
    {
        // Здесь сейчас третий поток
        readerTop = writerTop;
        return true;
    }
}
Я лично иногда спрашиваю PDF по конкретной технологии, т.к. не всегда удается быстро нагуглить ссылку.
Все равно ведь пишешь: «Помогите, плиз, не могу понять, в чем дело: %problem%»
Вторым они иногда позволяют сэкономить много времени.
Не могу сказать, что это неполезно.
Ага, вспоминаются портянки на несколько экранов.
И почему только при этом нет понимания, что человеку будет как минимум влом копаться в этом?
«Фундаментальность» в науке часто идет в разрез с требованиями современного производства.
Очень хороший взгляд на эту проблему изложен в этой книге.
Есть ли минусы? Вас начнут ужасно разочаровывать те интерфейсы и вещи, которые вы видите вокруг.


Si, amigo!
В целом статья ни о чем.
Много воды на одно смысловое заключение.
Принцип Keep It Simple. Не имеет смысл городить Builder'ы, когда можно обойтись интерфейсами. Они проще в понимании, особенно когда данное решение рассматривается в контексте проекта.
Как правило сделать код работающим очень не сложно


Только не в том случае, когда происходит race condition.

Информация

В рейтинге
Не участвует
Откуда
Новосибирск, Новосибирская обл., Россия
Дата рождения
Зарегистрирован
Активность