Не логично.
Если вы, например, гражданин РФ, поедете в США погулять-посмотреть, то вас можно убить, так как запрет на убийство только на граждан США распространяется? Только они защищены законом?
Вспоминается старый метод описания, применявшийся в 60-70х:
«48 разрядное машинное слово». Или «объем памяти — 2048 15 разрядных слов», если минимальная адресуемая единица — 15 бит.
Я больше про UB, который может «сломать» программу. Плохо, когда оптимизация делается втихую. Я бы предпочел видеть, что инструкции удалены или изменены из-за UB.
Классная отмазка. То-есть, взломать сервер подозреваемого как бы нельзя, а взломать сервер какого-то другого Джона Смита можно. И пока Джон Смит сам не подаст в суд на ФБР, все чисто. Круто, чо.
там где можно 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, и к этому вот коду надо достучаться извне (или экспорт и тому подобное), либо если код вызывается из двух и более точек.
И разбивка метода на визуальные куски с комментариями, и разбивка на процедуры — способы визуального выделения логических кусков. Но первый позволяет при необходимости все же все куски прочесть как единое целое.
Если вы, например, гражданин РФ, поедете в США погулять-посмотреть, то вас можно убить, так как запрет на убийство только на граждан США распространяется? Только они защищены законом?
«48 разрядное машинное слово». Или «объем памяти — 2048 15 разрядных слов», если минимальная адресуемая единица — 15 бит.
Это зависит от конкретного процессора.
Бывает так, что десяток простых работает быстрее, чем 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, и к этому вот коду надо достучаться извне (или экспорт и тому подобное), либо если код вызывается из двух и более точек.
И разбивка метода на визуальные куски с комментариями, и разбивка на процедуры — способы визуального выделения логических кусков. Но первый позволяет при необходимости все же все куски прочесть как единое целое.