Это — показатель того, что вы, возможно, в ловушке золотого молотка. Не факт, просто повод задуматься.

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

Код-стайл — он для людей, а не для компиляторов.
Если вы применяете один и тот-же код-стайл в нескольких разных языках — возможно этот код-стайл для вас — золотой молоток. (подчеркиваю — возможно)

Возможно. Как вы предлагаете исправить ситуацию сейчас?

Это я писал, что Mercurial лучше Git по многим параметрам.
И я смогу Вас убедить перейти на hg, но не буду этого делать, оставайтесь на Git!

Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»

Окей, быстро и на пальцах, плюсы hg, по сравнению с git:
1. hg на один символ короче, чем git. Я серьезно.
2. В hg меньше команд, чем в git. Для минималиста это плюс.
3. git более популярен, чем hg. Благодаря, чему, зная hg, можно почувствовать себя уникальной личностью на тусовке фанатов git'а.
4. hg ведет двойную нумерацию ревизий (вместе с хешем, нумерует их по-порядку).
5. У git нет API (только делать каждый раз fork-exec)
6. В git нет хуков.
7. В hg намного рациональнее организованы команды.
8. revsets
9. hg incoming
10. hg grep

Пальцы, кончились.

Ну и напоследок:

%  git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?

Есть конечно доля шутки во всем этом, но hg действительно по многим показателям намного лучше, чем git.

Однако я использую git.

Я имел ввиду «По многим параметрам Mercurial лучше, чем Git, а многим — хуже».

И я хочу, чтобы люди выбирали Git, не потому, что он лучше, чем все остальные системы, а потому-что мне нравится Git.

Надеюсь Вам стало понятнее.

Спасибо за Ваше мнение, надеюсь дело в материале, а не в его подаче.

Надеюсь следующая статья Вам понравится.

Правильно подозреваете, спасибо, что заметили.

Ух и нелегко Вам!

Я обычно натыкался на простые отмазки, вроде «мне лень», «мне это не нужно», «мне надо работать», «начну использовать в следующем проекте» и другое.

Позволю себе прокомментировать Ваши наблюдения:

Я так делал 2 (3, 5, 7) лет назад и по-другому не буду. Нафиг мне это всё нужно.

Ну это совсем просто. Все знают, что программисту нужно постоянно учиться. Да что там, в любом виде деятельности необходимо постоянно быть открытым новому. Ну а парировать «Нафиг мне это нужно», наверное невозможно.

Профилировщики/Сонары/Анализаторы — это мне не нужно, я и так знаю, что я пишу

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

От опытного (10+ лет) ресурс/проджект менджера/тех. лида: программист не должен знать/уметь работать с системами контроля версий, он должен уметь писать код. Кнопку нажал и готово. Зачем тратить время на изучение этих систем, только база: как сделать commit/push/branch.

А вот тут я почему-то согласен с опытным кем-то. Если программист достаточно разбирается в гит (заменить на свою СКВ) и у него есть более интересные направления развития, то почему-бы и нет? Время наше ограничено и если бы мне дали выбор — выучить досконально git или выучить досконально lisp, я бы выучил лисп.

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

Как следствие предыдущего пункта: git. Я уже всё запушил, а потом закоммитал, забирайте

А вот тут — надо учиться.

Никак не могу переубедить, заставить что-то выучить.

Понимаю Вас, однако, зачем вам кого-то переубеждать, вспомните, может Вы сами относитесь также к чему-либо? Скажем я уже который год не могу разобраться с веб-разработкой, даже не пробовал ничего, кроме node.js и чувствую, что дело просто в страхе перед чем-то новым.

Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»

Это действительно было так?

Скорее всего три-четыре пункта. Обязательно будет что-то из этого:

— Инструменты для тестирования — пожалуй самая полезная штука, после систем контроля версий. Мне очень понравился подход TDD, но обычно я вручную писал мини-надстройку для автоматизации тестов.
— Библиотеки (+API, +Фреймворки), удивительно, но многие до сих пор предпочитают написать что-то ручками, чем залезть в документацию по стандартной библиотеке или использовать какой-нибудь сторонний пакет
— Отладчики — все знают, что они есть, но когда наступает момент истины, используют аналоги бубна.
— Системы баг-трекинга — просто полезная штука
— Инструменты статического анализа кода (привет, PVS Studio!)

Ну а по-поводу систем непрерывной интеграции… Это хорошая штука, но подойдет ли она тем, кто придерживается традиционного цикла разработки? Все-таки при использовании некоторых методологий разработки непрерывная интеграция невозможна, неудобна, ненужна или еще что-то.

А так да, я напишу и про нее, только в 3-ей или 4-ой части цикла.

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

Спасибо, дополню статью.

Всегда знал, что всегда буду узнавать что-то новое. Спасибо.