Coding style battle

Стандарт кодирования у нас в команде отсутствует.

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

Использование юниттестов

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

Тесты должны прорабатывать быстро, но есть одна проблема - время компиляции. И в таком контексте я не на шутку задумался о сценариях сборки тестового раннера.

Есть ли в Google суппорт?

- Доктор, меня никто не замечает
- Следующий!

В связи с изменением структуры организации, в которой я работаю - я уже два месяца, как ведущий программист в компании Код Безопасности в группе компаний Информзащита. Типа хвалюсь, что теперь я не хухры мухры, а уже ведущий.

Заодно у меня сменился адрес электронной почты. Вместо привычного мне dron@infosec.ru, которым я пользовался 10 лет, у меня появился новый @securitycode.ru

И решил я значит завести себе новый аккаунт в Google...

Ветвления в бранче

Все-таки это зло.

Mercurial позволяет двум разработчикам независимо сделать push, что приведет к тому что в бранче на сервере получится ветвление. Но что делать третьему разработчику, который это вытягивает? Заниматься слиянием? Да он вообще не в курсе что там куда.

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

Допустимая публичность

В C++ традиционным считается использование public методов в начале описания. И сразу слайды:

class foo {
public:
        foo();
        void doSomething();
private:
        ...
};

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