там где можно 1 специфическую инструкцию — пилят десять общих, ведь так безопасней и слоупочней).
Это зависит от конкретного процессора.
Бывает так, что десяток простых работает быстрее, чем 1 специализированная. Как, например, с LODSB — MOV/INC на некоторых моделях x86.
Поначалу был у меня R400. Не мог нарадоваться — все отлично. Лет через 5 сдал экран (шлейф, точнее), был куплен T420.
Оказался фигня фигней. Клавиатура не та, эргономика хуже. Петли экрана разболтались через год (на R400 через 4 года). Тачпад уже от легкого прикосновения генерирует клик. Драйвера убогие, с внешним монитором работает примерно никак.
Вроде всего одно поколение вперед, а разница — небо и земля.
И не надо. Код вы пишете, а не компилятор. С таким же успехом вы можете утверждать, а вдруг, мол, мы используем по ошибке имя не локальной переменной, а поля данных класса. Что ж делать-то, компилятор же это не контроллирует!
То есть метод разбит на логические куски коментариями
Он может быть разбит на логические куски просто пустыми строками, если код очевиден. Это то же самое.
Далее — заголовок метода у меня в колстеке (такое окно в дебагерре) а комментарий вообще может быть не в этом окне
Его может и вовсе не быть. Но код-то вы вызывающий видите.
например я поставил точку останова в функции MessageBox и вижу колстек main \ ParseFile \ MessageBox а не main \ MessageBox
Это зависит от среды. Наприме, в IDE Delphi, которой я пользуюсь в данный момент, строка, откуда был сделан вызов, подсвечивается красным при переходе из колстека. Т.е. блок кода виден сразу. Если блок кода такого размера, что не вмещается в экран, то нужна разбивка.
// parse file
....
int i = MaxParseIterations;
while (i>0)
{
}
...
// transform
...
while (i < 1000 )
{
}
...
Используйте IterationIdx и TransformIdx, в чем проблема?
То, что вы описали для меня — за гранью.
Это очень сильно повышает читаемость кода, потому что позволяет сходу, не разбираясь, отличать локальные, глобальные перменные, формальные параметры и функции (скобки () не используются), а самое главное, — properties класса.
В-общем, компилятор и тулзы они хорошие — если им рассказать побольше — они помогут, а коментариев они не понимают.
Мне кажется, вы оптимизируете крайний случай. В среднем разницы не должно быть.
Опять же — это основано на личных предпочтениях, как уже выяснилось выше.
Изначальный смысл безразличен, главное — как удобнее.
Каждый инструмент для своей задачи.
Не видим, комментарий может быть сверху за границами экрана.
Не далее, чем заголовок метода при той же разбивке. Лично мне удобнее смотреть на код — где я, callstack для того откуда я пришел.
Осталось по номеру определить комментарий, которым был помечен блок и отличить его от комментария к конкретной строке.
Зачем? Если разбивка на блоки идет с таким же размером, как для методов, комментарий — в зоне видимости. Да его и вовсе может не быть, если код понятен сам по себе, дались вам эти комментарии :)
Как увидеть общий план?
Просматриваем метод сверху вниз, просто скроллингом. Вее видно, все потоки управления, и скакать по процедурам туда-сюда не надо.
Я не очень хорошо знаю C++ он позволяет писать так?
Пример, даже не скомпилируется:
{
int i;
i = 5;
cout << i;
}
cout << i;
2. Ключевые слова — язык не контролирует то есть если вы и будете использовать уникальные переменные для блока легко ошибиться.
Приведите пример.
трудно понять что код берет в качестве исходных данных, что возвращает,
Ну почему же? В вашем примере, если блок предварен чем-то вроде «парсим файл, находим клиента», и при этом есть переменные FileName и Customer, то понять несложно. Если еще использовать что-то вроде венгерской нотации (вроде), то еще проще: например, у нас в команде принято все поля данных в методе предварять F, все локальные переменные — l, формальные параметры — A. тут будет уже lCustomer и AFileName.
вообще говоря непонятно, к чему относится комментарий, к первой строке, к 10 строкам или к чему
Ну, как — к следующему блоку кода, отделенному либо комментарием, либо пустой строкой. Комментария может и вовсе не быть.
Я не против разбивки на методы, это было бы глупо. Я против разбивки ради разбивки.
По-моему, рассматривать организацию процедур, как средство поименования блоков кода некорректно. Изначальный смысл еще с эпохи машинного кода совсем иной — переход к куску и возврат обратно. Помнится, в Фортране подпрограммы реализовывались методом прямого копирования — это больше смахивает на поименование блока. Использовать именно для поименования-то можно, но это, кмк гвозди микроскопом. Хотя, иногда может быть удобным. Иногда.
— мы не увидим в стектрейсе этого названия
Если просто в callstack'е при отладке — не страшно, мы и так видим, где мы сейчас. Если при exception'е — есть инструменты, которые выдают номер строки (у нас используется Eurekalog для Delphi, в лог при обвале идет callstack с номерами строк в модулях).
В общем, зависит от используемых инструментов.
— мы не сможем свернуть его в редакторе
Ни разу не приходилось сворачивать. Видимо, по-разному с кодом работаем.
— язык не контролирует использование переменных (во-первых можно случайно использовать переменную из верхнего закомментированного блока, во-вторых, при чтении всегда придется учитывать эту структуру
Вполне можно использовать переменные с ограниченной областью видимости (в С++, например) или определять переменные для каждого блока свои и не использовать их повторно. На стеке столько же места займет.
Насчет закомментированного — предпочитаю следовать правилу — никаких закомментированных блоков в репозитории. Комментарии — для комментариев, для остального — система контроля версий.
— нет возможности декларировать исходные данные и результаты для каждого куска
Очень общее утверждение, сложно что-то обсуждать.
Для меня прокрутка менее удобна чем охватывание одним взглядом одним взглядом :)
В общем, это сугубо индивидуально. Непонятно, за что понаставили минусов — ведь просто мнениями обменялись. Выделение кода в отдельные модули также «раздувает» сам исходник. Зачастую получается, что процедурка, которая практически полностью влазила в экран, разбивается на куски и из-за заголовков/блоков часть кода уползает еще дальше. И если поначалу не видно было пару строк, но вся логика работы куска кода была как на ладони, то теперь надо прыгать по процедурам туда-сюда, последняя(ие) из которых уже в экран не влазят совсем.
Но посыл автора считаю верным — не стоит выделять код в процедуру просто потому что слишком много строк.
Для меня наоборот — когда четкую и ясную последовательность, каждая часть которой используется только один раз и только здесь разбивают на методы. Каждый из которых будет вызван только один раз из только одного места.
В результате понятный код, которых можно было охватить взглядом за раз (прокрутку не считаем, это легче, чем перемещаться между процедурами) прячется в абстракции, которые никакой информации, кроме названия метода не дают.
Код стоит выделить в процедуру, если это либо callback, и к этому вот коду надо достучаться извне (или экспорт и тому подобное), либо если код вызывается из двух и более точек.
И разбивка метода на визуальные куски с комментариями, и разбивка на процедуры — способы визуального выделения логических кусков. Но первый позволяет при необходимости все же все куски прочесть как единое целое.
когда вашу вегетососудистую дистонию поставят на место
Почему вы думаете, что у него в.с.д.? Спрашиваю из любопытства — у меня постоянная усталость, постоянно вымотанный — уже после 4 часов работы ощущение, будто сейчас упаду и усну. А раньше, бывало, по 12-15 мог работать без устали (с отдыхом нормально, не вкалываю сутками).
Мне говорили, что может с всд быть связано, поэтому и интересуюсь. Одно время элеутерокок помогал, и очень хорошо — голова ясная, работоспособность на высоте. Сейчас думаю, что бы еще поробовать.
В SVN невозможно собрать билд, откинув все что писали B и C, но при этом сохранив весь код ими написанный, т.к. ветка одна
А что мешает в SVN иметь release ветку и dev и не выкладывать рефакторинг и опасные фичи в релиз ветку?
Кто мешает выкладывать все фичи _только_ в dev и мерджить их в продакшн только после тестирования?
Да и далеко не всегда можно просто «откинуть все, что писали B и C». У нас полно ситуаций, когда коммиты совсем-совсем не атомарные, и их нельзя полностью откинуть. Например, допустим, я пррограммист B, дебажу что-то, исправляю ошибку, чекиню код. А паралелльно пишет свою фичу, но она затрагивает куски, над которым работал и я, B. После того, как я закинул свой код, А подкорректировал свой. Его фияа прошла тестирование. Потом оказалось, что мой фикс ломает что-то другое. А откатить его атомарно нельзя — фича А в своем коде уже пользуется переименованными мною переменными, функциями, вновь созданными мною функциями взамен удаленных. Если откатить мой коммит, код просто не соберется теперь. И тут Git (классный инструмент, согласен) никак не поможет. И в моем случае коммитов, которые можно откатить автоматом, да так, чтобы ничего не сломать, да хотяб чтобы проект собрался — мизер. «Магия» Git в стиле, описанном вами (повторю — гит классный инструмент и я им тоже пользуюсь) напоминает мне юмореску про магазин на диване, продававший штаны с подогревом. Вот мол, допустим, вы в голом поле, вы замерзли. Вам надо все-го то найти столб с проводами, залезть на него, подключить штаны и можно греться. Так и тут — еще поищи такой случай, когда можно коммиты отдельно друг от друга рассматривать.
Это зависит от конкретного процессора.
Бывает так, что десяток простых работает быстрее, чем 1 специализированная. Как, например, с LODSB — MOV/INC на некоторых моделях x86.
Оказался фигня фигней. Клавиатура не та, эргономика хуже. Петли экрана разболтались через год (на R400 через 4 года). Тачпад уже от легкого прикосновения генерирует клик. Драйвера убогие, с внешним монитором работает примерно никак.
Вроде всего одно поколение вперед, а разница — небо и земля.
Он может быть разбит на логические куски просто пустыми строками, если код очевиден. Это то же самое.
Его может и вовсе не быть. Но код-то вы вызывающий видите.
Это зависит от среды. Наприме, в IDE Delphi, которой я пользуюсь в данный момент, строка, откуда был сделан вызов, подсвечивается красным при переходе из колстека. Т.е. блок кода виден сразу. Если блок кода такого размера, что не вмещается в экран, то нужна разбивка.
// parse file .... int i = MaxParseIterations; while (i>0) { } ... // transform ... while (i < 1000 ) { } ...Используйте IterationIdx и TransformIdx, в чем проблема?
Это очень сильно повышает читаемость кода, потому что позволяет сходу, не разбираясь, отличать локальные, глобальные перменные, формальные параметры и функции (скобки () не используются), а самое главное, — properties класса.
Мне кажется, вы оптимизируете крайний случай. В среднем разницы не должно быть.
Опять же — это основано на личных предпочтениях, как уже выяснилось выше.
Каждый инструмент для своей задачи.
Не далее, чем заголовок метода при той же разбивке. Лично мне удобнее смотреть на код — где я, callstack для того откуда я пришел.
Зачем? Если разбивка на блоки идет с таким же размером, как для методов, комментарий — в зоне видимости. Да его и вовсе может не быть, если код понятен сам по себе, дались вам эти комментарии :)
Просматриваем метод сверху вниз, просто скроллингом. Вее видно, все потоки управления, и скакать по процедурам туда-сюда не надо.
Пример, даже не скомпилируется:
{
int i;
i = 5;
cout << i;
}
cout << i;
Приведите пример.
Ну почему же? В вашем примере, если блок предварен чем-то вроде «парсим файл, находим клиента», и при этом есть переменные FileName и Customer, то понять несложно. Если еще использовать что-то вроде венгерской нотации (вроде), то еще проще: например, у нас в команде принято все поля данных в методе предварять F, все локальные переменные — l, формальные параметры — A. тут будет уже lCustomer и AFileName.
Ну, как — к следующему блоку кода, отделенному либо комментарием, либо пустой строкой. Комментария может и вовсе не быть.
Я не против разбивки на методы, это было бы глупо. Я против разбивки ради разбивки.
Если просто в callstack'е при отладке — не страшно, мы и так видим, где мы сейчас. Если при exception'е — есть инструменты, которые выдают номер строки (у нас используется Eurekalog для Delphi, в лог при обвале идет callstack с номерами строк в модулях).
В общем, зависит от используемых инструментов.
Ни разу не приходилось сворачивать. Видимо, по-разному с кодом работаем.
Вполне можно использовать переменные с ограниченной областью видимости (в С++, например) или определять переменные для каждого блока свои и не использовать их повторно. На стеке столько же места займет.
Насчет закомментированного — предпочитаю следовать правилу — никаких закомментированных блоков в репозитории. Комментарии — для комментариев, для остального — система контроля версий.
Очень общее утверждение, сложно что-то обсуждать.
В общем, это сугубо индивидуально. Непонятно, за что понаставили минусов — ведь просто мнениями обменялись. Выделение кода в отдельные модули также «раздувает» сам исходник. Зачастую получается, что процедурка, которая практически полностью влазила в экран, разбивается на куски и из-за заголовков/блоков часть кода уползает еще дальше. И если поначалу не видно было пару строк, но вся логика работы куска кода была как на ладони, то теперь надо прыгать по процедурам туда-сюда, последняя(ие) из которых уже в экран не влазят совсем.
Но посыл автора считаю верным — не стоит выделять код в процедуру просто потому что слишком много строк.
Хм… я думал, определенное заболевание. Никто не берется диагностировать.
В результате понятный код, которых можно было охватить взглядом за раз (прокрутку не считаем, это легче, чем перемещаться между процедурами) прячется в абстракции, которые никакой информации, кроме названия метода не дают.
Код стоит выделить в процедуру, если это либо callback, и к этому вот коду надо достучаться извне (или экспорт и тому подобное), либо если код вызывается из двух и более точек.
И разбивка метода на визуальные куски с комментариями, и разбивка на процедуры — способы визуального выделения логических кусков. Но первый позволяет при необходимости все же все куски прочесть как единое целое.
Почему вы думаете, что у него в.с.д.? Спрашиваю из любопытства — у меня постоянная усталость, постоянно вымотанный — уже после 4 часов работы ощущение, будто сейчас упаду и усну. А раньше, бывало, по 12-15 мог работать без устали (с отдыхом нормально, не вкалываю сутками).
Мне говорили, что может с всд быть связано, поэтому и интересуюсь. Одно время элеутерокок помогал, и очень хорошо — голова ясная, работоспособность на высоте. Сейчас думаю, что бы еще поробовать.
А что мешает в SVN иметь release ветку и dev и не выкладывать рефакторинг и опасные фичи в релиз ветку?
Кто мешает выкладывать все фичи _только_ в dev и мерджить их в продакшн только после тестирования?
Да и далеко не всегда можно просто «откинуть все, что писали B и C». У нас полно ситуаций, когда коммиты совсем-совсем не атомарные, и их нельзя полностью откинуть. Например, допустим, я пррограммист B, дебажу что-то, исправляю ошибку, чекиню код. А паралелльно пишет свою фичу, но она затрагивает куски, над которым работал и я, B. После того, как я закинул свой код, А подкорректировал свой. Его фияа прошла тестирование. Потом оказалось, что мой фикс ломает что-то другое. А откатить его атомарно нельзя — фича А в своем коде уже пользуется переименованными мною переменными, функциями, вновь созданными мною функциями взамен удаленных. Если откатить мой коммит, код просто не соберется теперь. И тут Git (классный инструмент, согласен) никак не поможет. И в моем случае коммитов, которые можно откатить автоматом, да так, чтобы ничего не сломать, да хотяб чтобы проект собрался — мизер. «Магия» Git в стиле, описанном вами (повторю — гит классный инструмент и я им тоже пользуюсь) напоминает мне юмореску про магазин на диване, продававший штаны с подогревом. Вот мол, допустим, вы в голом поле, вы замерзли. Вам надо все-го то найти столб с проводами, залезть на него, подключить штаны и можно греться. Так и тут — еще поищи такой случай, когда можно коммиты отдельно друг от друга рассматривать.