Странная статья, конечно. Но куда более странные комментарии. Автор же ясно дал понять, что он новичок. А вы просите объяснения почему сделано так, а не иначе. На этом этапе
пробуют, а не принимают решения.
Ну то есть теоретически, конечно, важно указать на ошибки, но практически опыта чтобы вообще эти ошибки понять ещё нет (я, конечно, могу ошибаться).
А что они понимают под мобильным мессенджером? Если я напишу свое приложение и буду по сокетам общаться со своими друзьями я нарушу закон?
ps. Хотя тут, наверное, логика как с бабушками, продающими семечки.
— участниками дорожного движения сейчас могут быть мотоциклы
Думаю если дойдет до момента, когда автопилоты технически и экономически смогут вытеснить остальные автомобили, то правила движения существенно изменятся. Например будет запрещено движение не автопилотам.
— «проактивность» мозга — это «факт»,
Сильно зависит от определений, то есть от того на каком уровне абстракций смотреть.
На высоком уровне абстракции это действительно очевидно, что мозг работает исходя из каких-то «целей».
На низком уровне абстракции очевидно, что никаких целей в принципе нет, там есть куча клеток, взаимодействующих друг с другом по законам физики.
А ученые зачастую (не всегда, но зачастую) крутят определениями так, чтобы в статье лучше смотрелось (увы).
По опыту, если у ученика проблемы с пониманием стека, то у ученика проблемы с пониманием того, что такое структуры данных и зачем они нужны. Ну то есть если абстрактно начать ни с того ни с сего рассказывать про стек, то единственным вопросом будет «эээ, ну ок, и че дальше?».
Нужно для начала показать зачем нужны разные структуры данных, как с помощью них можно опускать большие куски размышлений.Что это не то как мы организуем память, а то как мы работаем с нашими данными.
с индексами больше возможности ошибки. С range-based for вероятность ошибки ещё меньше, но его не везде можно использовать (как, например, тут, где нужны 2 значения одновременно)
по поводу пустого route справедливо. По поводу понятливости… Он точно более понятен, чем первый вариант, тут вопросов нет. Со вторым вариантом (через абстракции) все сложнее. Как я говорил, пример слишком мал, чтобы что-то утверждать наверняка. В таком виде мне сложнее парсить что такое FartherThan и consecutive (тем более, если они находятся не прямо рядом с кодом где используется, а где-нибудь в другом файле, что вполне возможно).
С другой стороны, если принять во внимание возможность модификации, то дополнительные абстракции нужны. Но скорее всего не такие.
Все довольно относительно. Казалось бы функция computeNumberOfBreaks тоже своим названием вполне показывает что она делает. Зачем лезть внутрь? Внутрь нужно лезть если хочешь понять как именно считаются эти остановки. Точно также мне нужно будет посмотреть внутрь ещё одной сущности, если мне нужно будет понять как все-таки считаются эти остановки (по какому пути? По карте? По прямому расстоянию? По какой геометрии?)
С другой стороны эту же проблему можно было бы решить нормальным наименованием переменных. Использовать не it1, it2, а cur, prev. Использовать auto, чтобы не перезагружать код. Записать географические точки в переменные с хорошим названием, чтобы было понятно. Вообще пример слишком мал для какого-то вывода. Нужно понимать в каком контексте будут использоваться эти функции и классы, оправданно ли перегрузка абстракциями или нет. Но мне бы такой код было бы читать приятнее.
код
int computeNumberOfBreaks(const std::vector<City> &route)
{
static const double MaxDistance = 100;
int breaks_num = 0;
auto cur = route.cbegin()
auto prev = cur++;
for ( ;cur != route.cend(); prev++, cur++)
{
auto cur_location = cur->getGeographicalAttributes().getLocation();
auto prev_location = prev->getGeographicalAttributes().getLocation();
if(cur_location.DistanceTo(prev_location) > MaxDistance)
{
breaks_num++;
}
}
return breaks_num ;
}
Это зависит от размера компании. Если есть 3 разработчика — потеря одного будет критической. Если разработчиков 20-100 то потеря одного будет уже не такой существенной. Вполне возможно в такой ситуации, что компании будет дешевле подождать, чем заного искать и обучать нового сотрудника (а найти хорошего специалиста — тоже не быстрое дело, поиск вполне может также вылиться в полгода).
Единственное, что меня смущает в а автоматических форматтерах — то, что они не могут распознавать случаи, когда программист сам выставляет пробелы для форматирования. Они их убирают и код наоборот становится нечитаемым.
> Любой здравомыслящий человек понимает что это утверждение нелепо.
Статья, конечно так себе, но вот эта фраз, без всякого контекста, сама по себе прекрасна.
пробуют, а не принимают решения.
Ну то есть теоретически, конечно, важно указать на ошибки, но практически опыта чтобы вообще эти ошибки понять ещё нет (я, конечно, могу ошибаться).
ps. Хотя тут, наверное, логика как с бабушками, продающими семечки.
По-сути. Это вообще что? 0_о
Думаю если дойдет до момента, когда автопилоты технически и экономически смогут вытеснить остальные автомобили, то правила движения существенно изменятся. Например будет запрещено движение не автопилотам.
Сильно зависит от определений, то есть от того на каком уровне абстракций смотреть.
На высоком уровне абстракции это действительно очевидно, что мозг работает исходя из каких-то «целей».
На низком уровне абстракции очевидно, что никаких целей в принципе нет, там есть куча клеток, взаимодействующих друг с другом по законам физики.
А ученые зачастую (не всегда, но зачастую) крутят определениями так, чтобы в статье лучше смотрелось (увы).
Нужно для начала показать зачем нужны разные структуры данных, как с помощью них можно опускать большие куски размышлений.Что это не то как мы организуем память, а то как мы работаем с нашими данными.
С другой стороны, если принять во внимание возможность модификации, то дополнительные абстракции нужны. Но скорее всего не такие.
ps. Ну а длина кода вообще не аргумент.
С другой стороны эту же проблему можно было бы решить нормальным наименованием переменных. Использовать не it1, it2, а cur, prev. Использовать auto, чтобы не перезагружать код. Записать географические точки в переменные с хорошим названием, чтобы было понятно. Вообще пример слишком мал для какого-то вывода. Нужно понимать в каком контексте будут использоваться эти функции и классы, оправданно ли перегрузка абстракциями или нет. Но мне бы такой код было бы читать приятнее.
Единственное, что меня смущает в а автоматических форматтерах — то, что они не могут распознавать случаи, когда программист сам выставляет пробелы для форматирования. Они их убирают и код наоборот становится нечитаемым.
ps. Ещё интересно почему этот пост на гиктаймсе, а не на хабре.
Ненормально по сравнению с чем? С лесом?
Статья, конечно так себе, но вот эта фраз, без всякого контекста, сама по себе прекрасна.