Здравствуйте, thesz, Вы писали:


T>Ещё раз: все контексты поддаются описанию. Вне зависимости от их природы.

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

Здравствуйте, VladD2, Вы писали:

VD>Твое суждение было "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот...". Если уж строить аналогии, которые в прочем не уместны, то про автомобили нужно было писать "автомобиль может быть использован как по делу, так и не эффективно, например в соседний ларёк ездить за пивом на авто не эффективно".

VD>В таком же, извращенном, виде — это высказывание принципиально ложно, так как нарушает базовые законы логики.

Высказывание "любой (абсолютно) инструмент может быть использован как во благо, так и совсем наоборот..." не ложно, оно принципиально истинно
Можно всю строку заменить заменить на true или хоть на коня в вакууме — ничего не изменится

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, VGn, Вы писали:

IT>>> Видимо всё таки стоило начинать и не такая уж это муть
VGn>> Или тебе о верности твоих гипотез напели звёзды?

IT>Вообще же мы общаемся, если ты не заметил, в форуме "Философия программирования" и обсуждаем здесь всякую чушь, которую практически никогда нельзя ни доказать, ни опровергнуть формально.

Не все чушь оформляют в статьи.

IT>Есть вещи, которые в принципе нельзя описать формально, но они ещё как влияют на процесс разработки. Тебе их перечислить? Вот немногие из них: интуиция, озарение, талант, лень, ответственность, опыт, уровень образования, удача, усталось, комфортные условия работы.

Такие вещи принимают во внимание, а не формулируют законы сохранения лени
и однозначного преобразования удачи в другие виды

IT> Учитывая, что управление сложностью — это ключевой момент в разработке софта, то понимание структуры сложности, внутренних механизмов и влияния на код, для меня является гораздо важнее, чем формулы для вычисления абстрактных попугаев.

Без весовых характеристик анализ структуры никому не нужен.
Но это тебе уже и без меня объяснили.

IT>Если завтра будет холодно, скажем 5-10 С, ты просто оденешься потеплее или будешь до посинения требовать более точного числа для принятия решения, скажем до сотой градуса?

5-10 С — уже количественный диапазон. Оценив его я надену осеннюю куртку, а не ватник или футболку.

IT>А если ещё и дождик будет моросить, тебя будет интересовать сколько точно накапает в пробирки метеорологов или может просто взять зонтик и одним махом решить проблему?

Бывает такой дождик, который мне абсолютно по**й. Выгляну в окно и оценю качественно, как может развиться погода.
Может там вообще ураган назревает.

Так что не сработали твои аналогии.

Здравствуйте, IT, Вы писали:

IT>Скоро выйдет обновление статьи с этими дополнениями.

Мне кажется полезно будет обозначить сложности, которые тут накопали символами (напр. Sm — сложность модели, So — сложность обьекта, Sr — сложность решения, и т.д.). Чтоб не путаться. Также формально написать зависимости "больше", "меньше", "равно сумме".

Также разделить две задачи — уменьшение и перераспределение сложности. (не путать!!)

IT>Ещё мне было бы крайне интересно поговорить о метриках сложности. Идея использовать в качестве общего знаменателя для видов сложности время весьма занятна, но пока буксует на месте.

Для того, чтобы колличественно сравнить разные виды сложности не нужно "разноцветные попугаи сложности" переводить в один цвет.
Курс можно вивести статистически, я ж написал. И не заморачиваться внутренними причинами откуда какой коефициент появился и почему "8.42 часов написания раздутого быдлокода равно 1 часу обучения правильному программированию"

IT>в строго научном смысле такого закона не существует

Существует в строго научном. Есть минимальный обьем знаний, который вмещает модель. В процессе построения решения, ети знания трансформируются в различные сложности. В каких пропорциях — зависит от программиста. Рефакторинг в большей степени направлен на уменьшение сложности, в меньшей — на перераспределение. Но минимальная сложность решения сохраняется.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.

IT>Ну допустим мы получили три числа: 25, 42 и 18. Что с ними дальше делать?

Хочется уточнить, какая именно задача стоит:
1) уменшить сложность
2) перераспределить сложность
3) оценить насколько сложность решения выше минимальной

Простой пример. Есть "индусский" код.
Измерили "колличественную сложность" СКол, "сложность восприятия" СВоспр

СКол = 50
СВоспр = 10

Можно просто почистить явные дублирования, будет СКол = 40, СВоспр = 10 (уменьшение сложности)
Можно переделать решение на трех-етажных шаблонах, будет СКол = 10, СВоспр = 80 (перераспределение сложности)

Дальше, допустим по статистике 3 СКол = 1 СВоспр.
Вводим "абстрактного попугая сложности" АПС.
Пусть 1 АПС = 3 СКол = 1 СВоспр.

Переводим все колличества сложностей решения в АПС, суммируем и получаем сложность конкретного кода в АПС. Можно смело сравнивать со сложностью другого кода, решающего ту же задачу. Лучше код, у которого сложность ниже.


А вот как "оценить насколько сложность решения выше минимальной" — отдельная тема...
Наверно надо найти способ колличественно измерить сложность самой модели решения (колл. понятий, зависимостей)...

Хотя есть еще нюанс — сложность можно засунуть в инструмент (напр. использовать библиотечный алгоритм). Но вот вопрос — как в общем случае количественно оценить, сколько единиц сложности модели можно засунуть в используемые инструменты.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:


T>>Ещё раз: все контексты поддаются описанию. Вне зависимости от их природы.

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

Тем не менее, существует язык, в котором можно описать любое выбранное множество.

Это важней.

Здравствуйте, thesz, Вы писали:

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

T>Тем не менее, существует язык, в котором можно описать любое выбранное множество.

Расскажи про него.

Здравствуйте, gandjustas, Вы писали:

G>Также из студии можно использовать полезные вещи, такие как "цикломатическая сложность" и "свзяность классов".
G>Причем имеют смысл эти метрики на строку кода по всему проекту.
G>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.

IT>>Гибкость — сложность модификации кода. Как будем квантовать?
G>Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода.
G>Гибкость падает при увеличении количества строк и константных других параметров.

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

---------------
Class Coupling:
(именно из студии а не вобще связности разные)
Считает связи у каждого класса, а затем для всего кода считается как объединение множеств.Со всеми вытекающими последствиями...
При фиксированном обьеме кода,если один и то-то же код модифицируем. Увеличение показателя Class Coupling всего кода, увеличивает читабельность кода и качество кода... но так продолжается до точки оптимума затем качество наоборот уменьшается.

Если взять уже оптимальный код, все классы объединить в один класс (там где это возможно), то этот показатель СС из студии уменьшится (нет классов нет и CC), а качество резко упадет.
Если разбиваем сложный смешанный класс на два простых по ответственностям, для повышения читабельности. То студийный CC для всего кода увеличится на 1. Т.е. это увеличение качества вместе с CC.
Но увеличение CC выше оптимума начинает ухудшть код.
Связь CC с качеством чисто статистическая,слабая, зашумленная случайными отклонениями. Случайный шум здесь из-за неучтенных факторов. Но связь есть, она прямая до точки оптимума, после нее обратная.
Т.е. тоже в очень грубом приближении но в более близком, качество определяется не абсолютным значением студийного CC а величиной(обратной) его отклонения от оптимума в любою сторону.

Интереснее было бы смотреть такой CC между двумя частями проекта. Т.е. возможность фильтровать связи, в том числе например учитывать связи с классами стандартной библиотеки или нет.

--------------
Цикломатическая сложность:
Для блока кода(функция класс,namespase,project) cуммируется общее количество if,"?:",циклов, функций(статических,обычных,конструкторов), проопертей. Причем у пропертей get,set считаются отдельно(добавляют сразу 2).
Т.е. пустой класс с 10 пустыми пропертями int prop{get;set;} дает цикломатическую сложность 21 (1 конструктор и по 2 на каждый prop). Функция с 20 вложенными циклами даст тоже 21. Там где можно считать что это одно и тоже(10 пропертей против 20 циклов), там можно этот показатель и использовать.

Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности.

Связь прямая до оптимума, после него обратная.
Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.

Количество if и циклов может показывать не столько качество, сколько тип кода. Если нужнно много циклов в алгоритмах их не так-то просто убрать. Ну в обработке коллекций, циклы на Linq выражения заменить конечно можно, но .... Нельзя сказать что программа некачественная потому что слишком много if,for.

А если просуммировать количество циклов и функций(как делает цикл. слож.) то что в результате получится? Количество функций связано с качеством совсем другой зависимостью, чем количество if,for.
MaintainabiltyIndex замученый арифметическимми преобразованиями уже не понятно что показывает и как им пользоваться.

--------------
Лучше бы студия отдельно все считала, отдельно циклы, отдельно функции,отдельно if'ы, ...
А потом показывала бы красивые картинки, диаграммы. Какие-то диаграммы распределения функций по числу вызовов, по размеру функции, классов по числу членов, по соотношению числа приватных и публичных членов... Эти картинки хоть можно принять к сведению будет, какая то инфа о характере кода.
И желательна возможность написания своих скриптов для получения суммарных показателей.

А для связей между классами какие-то картинки где бы была видна кластеризация, и чтобы сотни классов на одной картинке было видно, но это уже сложно.

Еще можно было бы подсчитывать показатель объема повторной используемости функций. Т.е. взять число IL инструкций программы, затем все функции условно подставить(распаковать) в точку вызова, и вычислить на сколько процентов вырастет число инструкций. Когда функция вызывается из одного места, то повторной используемости нет, ее могли выделить только для уменьшения сложности. А когда большая функция вызывается из разных 10 мест, то это уже совсем другое...

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:

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

T>>Тем не менее, существует язык, в котором можно описать любое выбранное множество.

I>Расскажи про него.

Берем язык L. Берем контекст, который им описан быть не может. Добавляем в L конструкции по описанию контекста, получаем L'.

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

Вуаля.

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

Кстати, так обычно и поступают: добавляют в язык конструкции, потом упрощают. См. историю развития языка математики, физики и прочих наук.

Здравствуйте, thesz, Вы писали:

I>>Расскажи про него.

T>Берем язык L. Берем контекст, который им описан быть не может. Добавляем в L конструкции по описанию контекста, получаем L'.

T>Таким образом мы можем сконструировать язык для описания любого набора контекстов.

Ну да, не хватает только волшебной палочки.

Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:

I>>>Расскажи про него.

T>>Берем язык L. Берем контекст, который им описан быть не может. Добавляем в L конструкции по описанию контекста, получаем L'.

T>>Таким образом мы можем сконструировать язык для описания любого набора контекстов.
I>Ну да, не хватает только волшебной палочки.

I>Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.

Ты, что, никогда не описывал то, что никогда раньше не встречал?

Ты с самого рождения знал всё на свете?

Если нет, не знал и да, описывал, то у тебя есть такой опыт.

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

Здравствуйте, Silver_s, Вы писали:

S_>Здравствуйте, gandjustas, Вы писали:

G>>Также из студии можно использовать полезные вещи, такие как "цикломатическая сложность" и "свзяность классов".
G>>Причем имеют смысл эти метрики на строку кода по всему проекту.
G>>Вот эти 3 метрики + количество строк кода дают вполне пригодную оценку "качества кода", при минимизации метрик качество растет.

IT>>>Гибкость — сложность модификации кода. Как будем квантовать?
G>>Обратная величина к линейной функции от связности и цикломатической сложности при фиксированном объеме кода.
G>>Гибкость падает при увеличении количества строк и константных других параметров.

S_> На количество строк делить конечно надо, или как-то учитывать.
S_> Но все же подобные количественные метрики имеют смысл только с учетом здравого смысла. А чем больше арифметических преобразований над ними проделано тем меньше возможностей применить здравый смысл. Потому что эти преобразования грубое приближение.

S_>---------------
S_>Class Coupling:
S_>(именно из студии а не вобще связности разные)
S_>Считает связи у каждого класса, а затем для всего кода считается как объединение множеств.Со всеми вытекающими последствиями...
S_>При фиксированном обьеме кода,если один и то-то же код модифицируем. Увеличение показателя Class Coupling всего кода, увеличивает читабельность кода и качество кода... но так продолжается до точки оптимума затем качество наоборот уменьшается.

S_> Если взять уже оптимальный код, все классы объединить в один класс (там где это возможно), то этот показатель СС из студии уменьшится (нет классов нет и CC), а качество резко упадет.
S_>Если разбиваем сложный смешанный класс на два простых по ответственностям, для повышения читабельности. То студийный CC для всего кода увеличится на 1. Т.е. это увеличение качества вместе с CC.
S_>Но увеличение CC выше оптимума начинает ухудшть код.
S_> Связь CC с качеством чисто статистическая,слабая, зашумленная случайными отклонениями. Случайный шум здесь из-за неучтенных факторов. Но связь есть, она прямая до точки оптимума, после нее обратная.
S_> Т.е. тоже в очень грубом приближении но в более близком, качество определяется не абсолютным значением студийного CC а величиной(обратной) его отклонения от оптимума в любою сторону.

Это надо брать очень маленький изолированный кусок кода чтобы стабильно получать такой эффект. Если мерять по всему проекту, то запихивание всего в один класс приведет к дублированию кода (увеличению количества строк) и увеличению цикломатической сложности.


S_>--------------
S_>Цикломатическая сложность:
S_> Для блока кода(функция класс,namespase,project) cуммируется общее количество if,"?:",циклов, функций(статических,обычных,конструкторов), проопертей. Причем у пропертей get,set считаются отдельно(добавляют сразу 2).
S_>Т.е. пустой класс с 10 пустыми пропертями int prop{get;set;} дает цикломатическую сложность 21 (1 конструктор и по 2 на каждый prop). Функция с 20 вложенными циклами даст тоже 21. Там где можно считать что это одно и тоже(10 пропертей против 20 циклов), там можно этот показатель и использовать.

S_> Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности.

А повторное использование таких функций даст уменьшение кода и цикломатической сложности для всего проекта.

S_>Связь прямая до оптимума, после него обратная.
S_>Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.

Опять чтобы получать стабильно такой эффект надо мерить очень маленький изолированный кусок кода.

S_> Количество if и циклов может показывать не столько качество, сколько тип кода. Если нужнно много циклов в алгоритмах их не так-то просто убрать. Ну в обработке коллекций, циклы на Linq выражения заменить конечно можно, но .... Нельзя сказать что программа некачественная потому что слишком много if,for.

S_>А если просуммировать количество циклов и функций(как делает цикл. слож.) то что в результате получится? Количество функций связано с качеством совсем другой зависимостью, чем количество if,for.
S_>MaintainabiltyIndex замученый арифметическимми преобразованиями уже не понятно что показывает и как им пользоваться.

А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков.

Для качества нужна другая метрика, но она вероятнее всего будет состоять из тех-же компонент: строки, связность итп, только в совершенно другой зависимости.

Здравствуйте, gandjustas, Вы писали:

G>Это надо брать очень маленький изолированный кусок кода чтобы стабильно получать такой эффект. Если мерять по всему проекту, то запихивание всего в один класс приведет к дублированию кода (увеличению количества строк) и увеличению цикломатической сложности.

Ну пусть даже и не всего. Взять все классы не наследующиеся от базовых поставить на них partial и переименовать к одному имени.(плюс мелкие детали пофиксить). Class Coupling уменьшится в результате такого эксперимента. Цикл.сложн. не изменится. Вместо кучи мелких классов получится один жирный. Который может все если попросить, и может использоваться вместо каждого из мелких. Метрики никак не отреагируют на такое извращение, а если и отреагируют то намекнут на улучшение кода. Извращения метрики даже поощряют (если их интерпретировать как метрики качества).


S_>> Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности.
G>А повторное использование таких функций даст уменьшение кода и цикломатической сложности для всего проекта.
Если повторное использование удастся, то да.

S_>>Связь прямая до оптимума, после него обратная.
S_>>Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.

G>Опять чтобы получать стабильно такой эффект надо мерить очень маленький изолированный кусок кода.
Ну если во всем проекте все функции вызывающиеся из одного места в коде (были разбиты на отдельные функции только для упрощения) подставить в точку вызова(раскрыть) то могут и огромные нечитабельные функции возникнуть при уменьшении Ц.Слож.
Конечно никто специально так не хулиганит. Но все же цикл.слож больше меряет количество кода, но более крупными объектами, чем строки. А не качество,простоту.

G>А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков.
Но то как он усредняется для всех классов любых размеров, как среднее арифметическое, сильно его портит.

G>Для качества нужна другая метрика, но она вероятнее всего будет состоять из тех-же компонент: строки, связность итп, только в совершенно другой зависимости.
Да но она не простая получится.

Здравствуйте, VGn, Вы писали:

IT>>Вообще же мы общаемся, если ты не заметил, в форуме "Философия программирования" и обсуждаем здесь всякую чушь, которую практически никогда нельзя ни доказать, ни опровергнуть формально.

VGn>Не все чушь оформляют в статьи.

И не говори, большинство оформляет чушь в чушь.

IT>>Есть вещи, которые в принципе нельзя описать формально, но они ещё как влияют на процесс разработки. Тебе их перечислить? Вот немногие из них: интуиция, озарение, талант, лень, ответственность, опыт, уровень образования, удача, усталось, комфортные условия работы.

VGn>Такие вещи принимают во внимание, а не формулируют законы сохранения лени
VGn>и однозначного преобразования удачи в другие виды

И до этого очередь дойдёт. Есть у меня одно интересное наблюдение, в том числе и в этой теме, которое всё больше и больше тянет на закон.

IT>> Учитывая, что управление сложностью — это ключевой момент в разработке софта, то понимание структуры сложности, внутренних механизмов и влияния на код, для меня является гораздо важнее, чем формулы для вычисления абстрактных попугаев.

VGn>Без весовых характеристик анализ структуры никому не нужен.
VGn>Но это тебе уже и без меня объяснили.

Мне нужен. Более того, весовые характеристики, которые тут пытаются объяснять точно нафиг никому не нужны. Проку от них ноль, а неокрепшие умы способны запутать окончательно.

IT>>Если завтра будет холодно, скажем 5-10 С, ты просто оденешься потеплее или будешь до посинения требовать более точного числа для принятия решения, скажем до сотой градуса?
VGn>5-10 С — уже количественный диапазон. Оценив его я надену осеннюю куртку, а не ватник или футболку.

Это ты расскажи кому-нибудь другому. А в 6-11 ты что оденешь? А в 4-9? И где грань? 4.52 или 10.46? Этот диапазон ты автоматически даже не напрягаясь переведёшь в тепло, холодно или теплее, холоднее. Холодно для футболки, тепло для фуфайки. На самом деле в прогнозе было бы вообще достаточно сказать, что будт немногим выше 0. И всё. Для принятия решения этого достаточно.

IT>>А если ещё и дождик будет моросить, тебя будет интересовать сколько точно накапает в пробирки метеорологов или может просто взять зонтик и одним махом решить проблему?

VGn>Бывает такой дождик, который мне абсолютно по**й. Выгляну в окно и оценю качественно, как может развиться погода.
VGn>Может там вообще ураган назревает.

Т.е. количественные характеристики для принятия решения тебе не нужны? Что и требовалось доказать.

VGn>Так что не сработали твои аналогии.

Как раз наоборот. Ты сам продемонстрировал полную бесполезность и бессмысленность своей теории метрик.

Здравствуйте, Silver_s, Вы писали:

S_>Здравствуйте, gandjustas, Вы писали:

G>>Это надо брать очень маленький изолированный кусок кода чтобы стабильно получать такой эффект. Если мерять по всему проекту, то запихивание всего в один класс приведет к дублированию кода (увеличению количества строк) и увеличению цикломатической сложности.

S_> Ну пусть даже и не всего. Взять все классы не наследующиеся от базовых поставить на них partial и переименовать к одному имени.(плюс мелкие детали пофиксить). Class Coupling уменьшится в результате такого эксперимента. Цикл.сложн. не изменится. Вместо кучи мелких классов получится один жирный. Который может все если попросить, и может использоваться вместо каждого из мелких. Метрики никак не отреагируют на такое извращение, а если и отреагируют то намекнут на улучшение кода. Извращения метрики даже поощряют (если их интерпретировать как метрики качества).
Посмотрел свои проекты, количество таких классов незаметно отличается от нуля.

S_>>> Если сложную функцию разбить для простоты на 3 функции, цикл.слож. увеличится на 2. Хотя разбивали то для снижения сложности.
G>>А повторное использование таких функций даст уменьшение кода и цикломатической сложности для всего проекта.
S_> Если повторное использование удастся, то да.
Разбиение кода на мелкие независимые части повышает вероятность повторного использования. (что вообще говоря увеличивает качество кода).

S_>>>Связь прямая до оптимума, после него обратная.
S_>>>Чем больше функций в коде тем код качественнее, читабельнее (при том же объеме,с тем же поведением в рантайм). После точки оптимума наоборот чем больше функций тем код хуже. Тоже связь статистическая зашумленная неучтенными факторами.

G>>Опять чтобы получать стабильно такой эффект надо мерить очень маленький изолированный кусок кода.
S_> Ну если во всем проекте все функции вызывающиеся из одного места в коде (были разбиты на отдельные функции только для упрощения) подставить в точку вызова(раскрыть) то могут и огромные нечитабельные функции возникнуть при уменьшении Ц.Слож.
Это если не используется полиморфизм и функциональная композиция.

S_> Конечно никто специально так не хулиганит. Но все же цикл.слож больше меряет количество кода, но более крупными объектами, чем строки. А не качество,простоту.
Никто обратного и не утверждал.

G>>А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков.
S_> Но то как он усредняется для всех классов любых размеров, как среднее арифметическое, сильно его портит.
Ничего не портит. Еще раз: mantainability index — некоторый показатель сложности поддержки кода (с качетсвом корелляция очень слабая). Большой качественный код поддерживать сложнее, чем маленький и некачественный.

Здравствуйте, gandjustas, Вы писали:

G>>>А кто вообще сказал что mantainability index == качество кода? Его стоит понимать буквально — как некий показатель сложности поддержки кода. Причем он имеет смысл только для всего проекта, а не для отдельных кусков.
S_>> Но то как он усредняется для всех классов любых размеров, как среднее арифметическое, сильно его портит.
G>Ничего не портит. Еще раз: mantainability index — некоторый показатель сложности поддержки кода (с качетсвом корелляция очень слабая). Большой качественный код поддерживать сложнее, чем маленький и некачественный.

Разберем по косточкам.
Во первых ляп, то что mantainability index считается и для enum,delegate,interface для них всегда он равен 100, на уровне всего проекта эти штуки учавствуют в усреднении наравне с классами. Что приводит к случайному результату. Если проект такой где много enum то они исказят результат.

Но даже если есть только классы одинаковой крупности.

Maintainability Index = 100 — (3.04*Ln(Halstead Volume) + 0.134* (Cyclomatic Complexity) + 9.47*Ln(Lines of Code) )
С обрезанием ниже нуля.
Выражение в скобках это получается сложность поддержки. Также можно сказать судя по формуле это мера количества кода, но более сбалансированная как-то, логарифмы даже берут от строк. Halstead Volume — тоже количество кода, с учетом операндов и др. фичей.
Он как бы показывает накопление сложности при накоплении объема кода.
На уровне функции вроде все нормально. На уровне класса, как они делают не говорят, но не просто среднее арифметическое по функциям, и результат похож на правду. Но на уровне проекта совсем по-другому.

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

Причем внутри класса также подсчет делается усреднением сложности функций а не накоплением. Просто это усреднение улучшенное, а не просто ср. арифметическое(как на уровне проекта). Например только одна функция в классе со сложностью 50%, то и класс будет сложностью поддержки около 50%. Если еще 1000 таких функций добавить у каждой по 50%, показатель сложности класа не изменится.

Так что на уровне проекта этот Maintainability Index не является интегрированным показателем учитывающим множество факторов,
а фактически показывает усредненный размер функций в проекте. Хотя и размер не в строках, а сбалансированный. Но суть то не меняется.

Здравствуйте, thesz, Вы писали:

I>>Теоретически это и ежу ясно. На практике — возможности человека очень сильно ограничены. Меня интересует именно практика и решение хочется получить скажем, если не завтра, то в следуюещем году, ждать две-три тысячи лет как с математикой как то скучновато.

T>Ты, что, никогда не описывал то, что никогда раньше не встречал?

9. Принцип соответствия.
Язык описания сложной системы должен соответствовать характеру располагаемой о ней информации (уровню знаний или неопределенности). Точные логико-математические, синтаксические модели не являются универсальным языком, также важны нестрогие, приближенные, семиотические модели и неформальные методы. Один и тот же объект может описываться семейством языков различной жесткости [Налимов, 1979].

T>Ты с самого рождения знал всё на свете?
T>Если нет, не знал и да, описывал, то у тебя есть такой опыт.

Целые институты работают и не могут описать многие проблемы и на это уходят даже не годы, а десятилетия.

Здравствуйте, Silver_s, Вы писали:

S_> Ну пусть даже и не всего. Взять все классы не наследующиеся от базовых поставить на них partial и переименовать к одному имени.(плюс мелкие детали пофиксить). Class Coupling уменьшится в результате такого эксперимента. Цикл.сложн. не изменится. Вместо кучи мелких классов получится один жирный. Который может все если попросить, и может использоваться вместо каждого из мелких. Метрики никак не отреагируют на такое извращение, а если и отреагируют то намекнут на улучшение кода. Извращения метрики даже поощряют (если их интерпретировать как метрики качества).

Ну потому что все упирается в то, насколько грамотно соблюдается SRP. А вот к нему метрики придумать непросто, потому что сама responsibility штука не особо формализуемая.

AndrewVK wrote:

> Ну потому что все упирается в то, насколько грамотно соблюдается SRP.
> А вот к нему метрики придумать непросто, потому что сама
> responsibility штука не особо формализуемая.

Соблюдение SRP хорошо коррелирует с высоким cohesion, как и обратное — а
все виды cohesion вычисляются по формулам

Здравствуйте, mazurkin, Вы писали:
M>AndrewVK wrote:

>> Ну потому что все упирается в то, насколько грамотно соблюдается SRP.
>> А вот к нему метрики придумать непросто, потому что сама
>> responsibility штука не особо формализуемая.

M>Соблюдение SRP хорошо коррелирует с высоким cohesion, как и обратное — а
M>все виды cohesion вычисляются по формулам

А тулзы какие нибудь существуют? Которые могли бы сказать этот класс надо рзбить на 2 части — в первой части, такие фунции и мемберы, во второй части такие. Не обязательно чтобы сами разбивали, хотя бы указали такой класс.