90 рекомендаций по стилю написания программ на C++

О нет… похоже, мы начинаем холивар.

Одна из причин, по которой не люблю python (ой сейчас я огребу), именно _.__.___.
Тут надо знать меру, IMHO больше одного символа "_" подряд — недопустимо.

Благодаря throw не забываешь об исключениях, когда используешь метод.

А по поводу algorithm:

for(auto item : vect) {
    /* do some stuff */
}

Читается легче, чем

std::for_each(vect.begin(), vect.end(), [] (some_type item) -> void {
    /* do some stuff */
});

или

struct some_functor {
    void operator() (some_type item) {
        /* do some stuff */
    }
} my_functor;

/* ... */

std::for_each(vect.begin(), vect.end(), my_functor);

Давайте закроем тему, все равно в итоге каждый останется при своем мнении.

Mozilla предлагает создавать «тяжёлые» 3D-игры для web на их новом движке

Местами похоже на машинный перевод.
«визуальный опыт» (очевидно «visual experience»),
«для улучшения пользовательского опыта» (очевидно «user experience»).

по теме — при использовании asm.js они расчитывают получить код, который выполняется всего вдвое медленнее, чем нативный (буквально на днях была об этом статья), учитывая, что сейчас получаются довольно неплохие игры, работающие на мобильных устройствах, то написать игру, которая не будет тормозить в десктопном браузере — реально. А целесообразность покажет время.

90 рекомендаций по стилю написания программ на C++

Знаю, сам как-то для мелкой команды пытался составить.

Всё учесть не реально, к примеру во всей статье и в комментариях нет ни одного упоминания тернарного оператора. Хотя обычно тот, кто составляет такой документ прямо его зарещает (еще одна тема для холивара — не редко он читается легче, чем конструкция if/else).

Читаемость кода — очень субъективная штука. Если мне доводится писать подобные рекомендации, то я пишу примерно следующее:

• K&R стиль для скобок;
• строчное написание везде, кроме имен типов, там — CamelCase;
• #pragma once;
• отступ — 4 пробела;
• строго 80 колонок;
• только блочные комментарии;
• длинные самодокументирующиеся имена;
• никакой венгерской нотации;
• метки — на уровень левее кода, case, private, protected, public приравниваются к меткам;
• использование auto и decltype;
• использование static_assert;
• там, где можно — циклы по коллекции, вместо итераторов;
• обязательное использование const в параметрах методов;
• использование final, override;
• использование constexpr;
• явное указание всех исключений, которые может выбросить метод.

Остальное — на собственное усмотрение. Уже в перечисленном обычно находится пяток тем для споров, из которых уже выводятся окончательные требования к стилю в проекте.

Уведомления о завершении консольных команд

Тогда понятно. Хотя если мне ясно, что команда будет работать долго, то я прибиваю её, если уже запустил, запускаю её в screen и просто занимаюсь другими делами на других тегах. Благодаря тому, что теги повешены на хоткеи, мне нужно около двух секунд, чтобы проверить, закончилось ли выполнение.

Уведомления о завершении консольных команд

Простите, но эта штука не стоит отдельного репозитория на гитабе и отдельного пакета.

Есть же notify-send (через который эта штука и работает, судя по сообщению).

function notify_complete {
    notify-send -i terminal -t 10000  "Task complete" "$1"
}

в .bashrc делает тоже самое. Запускается так:

sleep 10; notify_complete sleep

90 рекомендаций по стилю написания программ на C++

Годный вброс. Очень много спорных пунктов, не смотря на аргументацию (кстати местами довольно хилую).

К примеру, на мой взгляд, строчное написание с подчеркиванием в качестве отступов читается_лучше, чем верблюжийШрифт.
(Не надо холивара на эту тему, пожалуйста).

Кстати, принятый в GNU формат отступов, тут назван неприемлемым.

void
some_function()
  {
    do_some_stuff();
  }

Почему вам стоит использовать TypeScript

Всецело поддерживаю. Такое ощущение, что в Майкрософт снова у кого-то NIH синдром причем эти люди не осилили прототипное ООП и динамическую типизацию.

Поживем — увидим, во что это выльется, больше велосипедов языков — больше разнообразия.

Экспериментальное демо Google Chrome — превращаем любой сайт в интерактивный 3D-лабиринт

my bad… мне надо драйвер на видюху обновить, и когда WebGL сломаться успел.

Экспериментальное демо Google Chrome — превращаем любой сайт в интерактивный 3D-лабиринт

Действительно странно.

Редиректит на /maze/pc/not-supported/ и пишет connection lost.

screenshot

В системных требованиях про linux нет ничего, до Windows и Mac требований разве что по видеопамяти комп не дотягивает.
chrome.com/maze/pc/requirements/

Экспериментальное демо Google Chrome — превращаем любой сайт в интерактивный 3D-лабиринт

На chromium под linux пишет, что не поддерживается и предлагает скачать хром.
Жалко, а ведь WebGL у меня вполне себе работает.

Иголка, нитка и число пи

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

(Строго говоря мы тоже бросали гвоздь с откусаной шляпкой, на лист А3)

Иголка, нитка и число пи

Просто иногда действительно произвольные события даже при большом количестве повторов не дают рассчитанного теоретически процента удовлетворительных исходов. Параллельно с нами этим занимались еще две-три пары человек, у них получилось что-то близкое к 3.1, 3.2. при том, что они бросали иголку раз в двадцать меньше.

При этом на компьютере такие эксперименты моделируются всегда с удовлетворительным результатом, так как компьютер почти всегда использует генератор псевдослучайных чисел, которые иногда дают гораздо более равномерное распределение значений, чем действительно случайные события.

Иголка, нитка и число пи

Помню, как три года назад в реальности бросали иголку на разлинованный лист бумаги, после 10000 падений иголки мы получили пи равное 2.5, что сильно расстроило Все таки вероятностные методы не всегда работают так, как должны.

Проверка входных параметров или косвенные ссылки на BASH

Безусловно классно. Правда я в таком случае использовал бы что-то более приспособленное для этих целей вроде Perl или lua.

Опрос. Выравниваете ли код по столбцам?

Собственно сам открыл комментарии, чтобы написать такой же вариант. Ответил «Выравниваю», но это все-таки не совсем верно.

А еще был Интернет

А собственно зачем тогда мак? для пафоса?

Про средства ввода, имхо, правда — островные клавиатуры с плоскими клавишами это убожество, плевать, что за эту фразу я сейчас отхвачу минусов.

Включите мой комп!

Но согласитесь, что простая перезагрузка в ситуации, когда отвалился даже ssh, совсем не поможет. Тут уже нужен полноценный KVM.

Включите мой комп!

Кстати при BSoD и kernel panic компьютер должен перезагружаться сам (даже если это выключено, то включается довольно легко). Проблема все-таки несколько надумана.

Включите мой комп!

Много раз запускал такие процессы, ни разу дело не доходило до перезагрузки. Обычно минут за пять (в крайнем случае) удается снять такой процесс.

BSoD сейчас — очень редкая аномалия(разве что вы под ReactOS сидите), но если он возник один раз, то он обязательно появится позже. Перезагрузка не решает эту проблему окончательно.

P.S. На своих компах уже очень давно не видел BSoD и kernel panic. Что я делаю не так? У соседа частенько ноут выпадает в BSoD, но тот никак не решает эту проблему и каждый раз тратит нервы.

Включите мой комп!

Только не говорите, что в нем нет способа удаленно выключить или перезагрузить компьютер, как вы тогда собрались работать с ним удаленно? Опять же тяжело довести систему до BSoD, а если довели, то простая перезагрузка — это не выход.

Скажу яснее, в ситуации, когда компьютер, с которым вы работаете удаленно, не поддается управлению, такая система — костыль, а не решение проблемы. Для решения скорее всего потребуется непосредственное вмешательство.