Здравствуйте, Skorodum, Вы писали:
CC>>И когда у тебя кодобаза чуть ли не с 90х тянется там такое лоскутное одеяло за это время набирается. S>И в чем проблема-то?
Попробуй прочитать ещё раз.
S>1. Если никак решить задачу изменениями в одном файле, меняются несколько
Спасибо Кэп!
S>2. Если попутно надо что-то отрефакторить, оно рефакторится и коммится отдельно, потом основаная задача отдельным коммитом.
Это никак не помогает уменьшить лоскутность blame для того, кто будет смотреть на полный файл через год?
S>Да не придется, изменения в логике не могут быть разбиты на несколько коммитов, т.к. тогда коммиты будут не рабочие.
Да лехко
Добавляется логика которая пока не используется вне тестов или вовсе compiled out
S>По git blame сразу видно, какой коммит изменил больше всего
И как git blame заставить показать коммит 5летней давности, почти все строки которого были за это время потроганы сотней других коммитов?
У p4 был отличный тул timelapse, который позволял ходить по истории туда-сюда в наглядном виде и видеть что происходило в конкретном range строк.
Git так не умеет. Можно только врукопашку.
CC>>Так что не работает такой подход. S>Вот навскидку: давай взглянем на ядро линухи из 90-х. Найди там описанную тобой проблему.
У меня нет ни времени ни желания смотреть на ядро линуха.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
CC>>>И когда у тебя кодобаза чуть ли не с 90х тянется там такое лоскутное одеяло за это время набирается. S>>И в чем проблема-то? CC>Попробуй прочитать ещё раз.
Слова кончились? "Старые проект" само по себе ничего не значит. В чем проблема-то? В плохих коммитах? ССЗБ
S>>1. Если никак решить задачу изменениями в одном файле, меняются несколько CC>Спасибо Кэп!
Пожалуйста
S>>2. Если попутно надо что-то отрефакторить, оно рефакторится и коммится отдельно, потом основаная задача отдельным коммитом. CC>Это никак не помогает уменьшить лоскутность blame для того, кто будет смотреть на полный файл через год?
Да покажи где эту лоскутность-то на примере сложного кода который не очевиден и надо смотреть историю, так чтобы git blame не помог.
S>>Да не придется, изменения в логике не могут быть разбиты на несколько коммитов, т.к. тогда коммиты будут не рабочие. CC>Да лехко CC>Добавляется логика которая пока не используется вне тестов или вовсе compiled out
Да без проблем, только логическре изменение должно быт цельными или ССЗБ
CC>И как git blame заставить показать коммит 5летней давности, почти все строки которого были за это время потроганы сотней других коммитов?
Если были потраганы, значит логика изменилась
CC>У p4 был отличный тул timelapse, который позволял ходить по истории туда-сюда в наглядном виде и видеть что происходило в конкретном range строк. CC>Git так не умеет. Можно только врукопашку.
Это было бы полезное дополнение, согласен.
CC>У меня нет ни времени ни желания смотреть на ядро линуха.
Зато есть время на бла-бла-бла. Ты говоришь о проблеме, а привести пример этой проблемы в проекте где за коммитами более-менее следят — не можешь
Здравствуйте, Skorodum, Вы писали:
CC>>Попробуй прочитать ещё раз. S>Слова кончились? "Старые проект" само по себе ничего не значит. В чем проблема-то? В плохих коммитах? ССЗБ
В том что ты не понял про что тебе говорят.
S>Да покажи где эту лоскутность-то на примере сложного кода который не очевиден и надо смотреть историю, так чтобы git blame не помог.
Т.е. ты мне предлагаешь щас шарить по публичным репам чтоб найти тебе пример того, что ты на словах не понимаешь?
S>Если были потраганы, значит логика изменилась
Далеко не всегда изменения кардинально меняют логику. Например переименовали константу, что породило тьму лоскутных изменений но ничегошеньки в логике не поменялось.
S>Ты говоришь о проблеме, а привести пример этой проблемы в проекте где за коммитами более-менее следят — не можешь
Это несопоставимо по временным затратам.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вообще-то при разработке чего-то е совсем уж тривиального, я сначала пишу комментарий, чего и в каком порядке надо делать. LVV>Если после написания коммента понятно, что и как — пишу ниже код. LVV>Если нет, раскрываю коммент в несколько строк более детальных действий LVV>И так далее.
Ну да, я понимаю, олд скул ))
По моей практике это сработает если
1) Очень сложная предметка и приходится описывать не то что ты делаешь а почему ты это делаешь.
2) Недружелюбный язык/платформа разработки. Например, в юности программировал однокристалки на c/asm, причем asm такой себе извращенный. И там действительно на строчку кода по пять строчек комментов бывало, ибо строчка, например, выставляет нолик или единичку на ножку процессора, а комментарий описывает, накой черт там этот нолик или единичка и куда и зачем потом пойдет.
Щас давно уже прочно сижу на .NET
И пишу лучше чем по-русски. То есть, когда пишу рядовой код, он оказывается проще для понимания и лаконичнее нежели мысль по древу на русском.
К тому же, код меняется постепенно и в самых разным местах. Ну то есть сделал мелочь, протестил, еще дописал, еще протестил и т.д. Параллельно рефакторить не только код но и комменты — ну его нафиг. Двойная работа.
Писать комменты считаю нужным только для чего-то, что с первого раза непонятно. И то, если такое место есть — то может его отрефакторить чтобы было понятнее?
Ну а если вообще никак — ну ок, пусть будут комменты.
G>Ну да, я понимаю, олд скул )) G>По моей практике это сработает если G>1) Очень сложная предметка и приходится описывать не то что ты делаешь а почему ты это делаешь. G>2) Недружелюбный язык/платформа разработки. Например, в юности программировал однокристалки на c/asm, причем asm такой себе извращенный. И там действительно на строчку кода по пять строчек комментов бывало, ибо строчка, например, выставляет нолик или единичку на ножку процессора, а комментарий описывает, накой черт там этот нолик или единичка и куда и зачем потом пойдет.
Добавлю:
3) новая задача и/или предметная область, в которой надо еще с типовыми алгоритмами разобраться, понять нюансы и т.п.
Я так проги по перколяции писал. Сначала пишу, чего и в каком порядке надо делать на русском, а потом перевожу в код.
Или вот буду писать систему психологического тестирования программистов — тоже без осознания чего и как кода не напишешь.
4) При необходимости писать на новом языке — сначала на русском, потом подбираешь подходящие конструкции нового языка (ну, конечно, это не касается совсем уж тривиальных, которые есть в любом языке)
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, gress, Вы писали:
G>Столкнулась с новым веянием, согласно которому считается, что код комментирует себя сам.
Иногда да, иногда — нет.
G> И комментарии не только не нужны, а вообще вредны.
Лишние комментарии не нужны, нелишние — нужны. Универсального рецепта нет.
G>Поэтому интересно, я действительно динозавр и код теперь никто не комментирует?
1) Те кто против любых комментов. Берешь какой нибудь нетривиальный кусок кода (нетривиальный в плане логики или завязанный на какую то неочевидную тонкость), удаляешь все комменты. Потом просишь протестантов быстро посмотреть кусок кода и объяснить как он работает.
2) Те кто любит лишние комменты. Берешь кусок кода с комментами в стиле "Капитан Очевидность" и настоятельно просишь пояснить, в какой момент данный коммент упростит жизнь читающему код.
Здравствуйте, Denwer, Вы писали:
D>А писать понятный код не получается? Ну комментарии можешь для себя писать, но понятный код это обязательное условие по сути. А то бывает смотришь код, а там перменные а1, а2, а3 и к ним комментарии. А нельзя их обозвать более понятно и не пистаь комментарий?
Иногда бывает, что нельзя. Реализуешь какую-нибудь математику по стандартному описанию алгоритма, а там x, y, S. И что делать?
Здравствуйте, Hobbes, Вы писали:
H>Иногда бывает, что нельзя. Реализуешь какую-нибудь математику по стандартному описанию алгоритма, а там x, y, S. И что делать?
Ну, у математиков свой подход к именованию переменных и вообще к программированию.
Математики в злобной числодробительной программе делали такую шапку, в которую записывали, откуда взяты алгоритмы (монография, авторы, год издания; статья, название,журнал, №, год, авторы; диссертация, автор). И оставляли имена максимально близкими к тем, что в формулах. Выглядел код (на Фортране) для постороннего полным бредом. Но один математик свободно читал такой код, написанный другим математиком.
Здравствуйте, Privalov, Вы писали:
P>Математики в злобной числодробительной программе делали такую шапку, в которую записывали, откуда взяты алгоритмы (монография, авторы, год издания; статья, название,журнал, №, год, авторы; диссертация, автор). И оставляли имена максимально близкими к тем, что в формулах. Выглядел код (на Фортране) для постороннего полным бредом. Но один математик свободно читал такой код, написанный другим математиком.
Вот-вот, я про это и говорю.
И это необязательно математики и математика. Любая нетривиальная логика из предметной области упирается в то, что в коде надо откомментировать как минимум, откуда это взялось (прямо ссылкой на документацию), и что происходит на данном конкретном этапе.
Здравствуйте, Hobbes, Вы писали:
H>И это необязательно математики и математика. Любая нетривиальная логика из предметной области упирается в то, что в коде надо откомментировать как минимум, откуда это взялось (прямо ссылкой на документацию), и что происходит на данном конкретном этапе.
математику я взял исключительно в качестве примера. Просто потому, что у меня был некоторый опыт в числодробительной области. Работал с матерыми математиками. А комментарии в фортрановском коде оставлял больше для себя, чем для них. Я к проекту кое-где сишные модули подключил, оставлял заметки. До того случая у меня не было опыта сборки модулей, сделанных на разных языках.
Сегодня я обычно вставляю комментарии, если использую какую-либо конструкцию или структуру впервые. Или ставлю напоминалку на будущее: там изменить, а тут проверить. А вместо устаревшего объекта использовать новый (и такое бывает). Иногда неясно бывает, как написать метод. Тогда делаю его пустым и сначала пишу в нем, что нужно сделать. И постепенно заменяю комментарии кодом.
Иногда слишком подробные комментарии бывают вредными (для комментирующего). Но это уже другая история.
Здравствуйте, CreatorCray, Вы писали:
S>>По git blame сразу видно, какой коммит изменил больше всего CC>И как git blame заставить показать коммит 5летней давности, почти все строки которого были за это время потроганы сотней других коммитов? CC>У p4 был отличный тул timelapse, который позволял ходить по истории туда-сюда в наглядном виде и видеть что происходило в конкретном range строк. CC>Git так не умеет. Можно только врукопашку.
В Идее есть пункт контекстного меню Git/Show history for selection на выделенном фрагменте. Это не оно?
Здравствуйте, gyraboo, Вы писали:
G>В Идее есть пункт контекстного меню Git/Show history for selection на выделенном фрагменте. Это не оно?
У меня идеи нету, так что проверить не могу. Может таки и сделали наконец.
Надо бы пнуть Atlassian чтоб они в своём SourceTree сделали, вот только у них проблемы покруче пока — у них походу квадратичная сложность где то затесалась и на сколь либо больших репах оно тормозит просто ацки.
Здравствуйте, CreatorCray, Вы писали:
CC>Надо бы пнуть Atlassian чтоб они в своём SourceTree сделали, вот только у них проблемы покруче пока — у них походу квадратичная сложность где то затесалась и на сколь либо больших репах оно тормозит просто ацки.
Проще идею поставить Атлассиан не раскачаешь, больше 5 лет не могут сделать архивирование репозиториев в битбакете
В Идее есть локальная история тоже, иногда спасает и экономит часы работы
Здравствуйте, CreatorCray, Вы писали:
G>>В Идее есть пункт контекстного меню Git/Show history for selection на выделенном фрагменте. Это не оно? CC>У меня идеи нету, так что проверить не могу. Может таки и сделали наконец.
В Идее это сделали уже как много лет. Как и множество других ништяков, о которых в других IDE только грезят или даже не знают что такое вообще есть, хотя эти ништяки нехило бустят скорость и удобство разработки. Идея стала легендой не просто так.
Здравствуйте, gress, Вы писали:
G>Столкнулась с новым веянием, согласно которому считается, что код комментирует себя сам. И комментарии не только не нужны, а вообще вредны.
G>Так как я боец старой формации, для меня это дикость. Но тут так получилось, что я сейчас тим лид, а мнения в команде разделились.
G>Поэтому интересно, я действительно динозавр и код теперь никто не комментирует?
Напоминает табы против пробелов. Хочу отдельно отметить только один аспект комментариев — чисто визуальный, графический. Комментарии хорошо заметны в коде, и я их расставляю по своей системе в каких-то структурных местах, даже если там нет особой логики, комментировать, собственно, нечего. Разделяю/выделяю смысловые или структурные группы, блоки. Использую символы подчеркивания, звездочки — такое. Без попугайства, не разрисовываю, у меня выработалась простая система.
В результате, когда бегаешь по коду, глаз сам цепляется за нужные места, не надо использовать высшие функции мозга для навигации. Я, например, когда скроллю код, мгновенно расфокусирую и фокусирую зрение. Может быть, это позволило мне не убить зрение окончательно за 100 лет за компом. Каменты при скроллинге и расфокусировке глаз помогают останавливаться, где надо.
Естественно, таких каментов должн быть немного — один на 10-200 строчек.
А теперь о главном, моей прогрессивной новаторской идее. Исходя из общей логики развития цивилизации, выражющейся в миграции документации и вообще всего в ютуб и тик-ток, предлагаю предложить внедрить в IDE комментирование кода в формате видео. Видео, конечно же, сохранять в облаке.
Здравствуйте, goto, Вы писали:
G>А теперь о главном, моей прогрессивной новаторской идее. Исходя из общей логики развития цивилизации, выражющейся в миграции документации и вообще всего в ютуб и тик-ток, предлагаю предложить внедрить в IDE комментирование кода в формате видео. Видео, конечно же, сохранять в облаке.
Крутая идея кстати, давайте ее еще более расширим:
— лайки/дизлайки строкам/кускам кода/функциям/классам;
— подписаться на изменения какого-либо куска кода;
— возможность оставлять комменты кускам кода.
Здравствуйте, gress, Вы писали:
G>Поэтому интересно, я действительно динозавр и код теперь никто не комментирует?
У кода должна быть документация. Там надо описать как это собрать, что требуется установить, какая часть программы что делает.
Как отлаживать, что означают логи. Как настроить рабочее окружение с нуля новому человеку. И куча других неочевидных вещей
А в коде непонятно зачем нужны комментарии. Если комментируешь, значит код недостаточно выразителен. Лучше улучшить код, чем тратить время на комментарий.
А ещё комментарии не компилируются. И когда код изменится — они останутся, станет ещё хуже, т.к. вряд ли кто-то когда-то удалит этот комментарий. В любом случае на него будет тратится время.
Есть функция getUserName, и к ней написан комментарий "поменять имя текущего пользователя на новое случайно сгенерированное и вернуть предыдущее значение". Надо ли пояснять, что код плохой и комментарий не улучшает ситуацию?
Плохой код с комментариями лучше, чем просто плохой код. Но не на много. Лучше всё же тратить время на улучшения самого кода. А комментарии — это запашок, который подскажет, что здесь надо убрать.
Здравствуйте, blacktea, Вы писали:
B>Крутая идея кстати, давайте ее еще более расширим:
Да, очень крутая. Я убежден, что со временем ее воплотят.
B>- лайки/дизлайки строкам/кускам кода/функциям/классам; B>- подписаться на изменения какого-либо куска кода; B>- возможность оставлять комменты кускам кода.
Как ни парадоксально, но развитие идеи уже новаторским не является. Давно есть форумы, репозитории, где куски кода и комментарии лайкают и делают с ними все.
Здравствуйте, Hobbes, Вы писали:
H>Иногда бывает, что нельзя. Реализуешь какую-нибудь математику по стандартному описанию алгоритма, а там x, y, S. И что делать?
Обычно просто дают ссылку на книгу или статьи, где это всё подробно описано.
Атлассиан не раскачаешь, больше 5 лет не могут сделать архивирование репозиториев в битбакете 
