Группа разработчиков Scala получила грант Евросоюза

> setupSuccessfulAuthResult

в смысле, мои названия по началу ничем не лучше

Почему эти строки не учтены?

потому что у исчерпывающих match-tq надо учитывать все кейсы кроме первого — а иначе получим увеличение числа от конструкции

None match {
  case None => do_something();
}

и еще — с точки зрения написания тестов || надо учитывать и последний case _ который является мертвым кодом тоже надо учитывать, так что там можно считать 10

и еще у цикломатического числа есть особенность — оно равно увеличивается как от иф-а с 1 веткой, так и с 2-мя, хотя мне кажется человеком легче воспринимаются иф-ы с 1 веткой

> оно равно увеличивается как от иф-а с 1 веткой, так и с 2-мя, хотя мне кажется человеком легче воспринимаются иф-ы с 1 веткой

Всё условие либо выполняется, либо нет - т.е. два варианта. И один стейтмент в операторе if может быть пустым ;)

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

допустим выбран перл (можно руби) и регулярные выражения вместо парсинга хтмл

все это будет колоночкой регулярных выражений с комментариями, причем возможно зачастую по 2 строки комментариев на 1 выражение; теперь представь это в виде набора функций с телом по 1 строке каждая, да еще с шапками параметров — раздувание примерно в 10 раз, и от комментариев ты все равно не избавишься — их нельзя будет полность запихать в названия функций

>потому что у исчерпывающих match-tq надо учитывать все кейсы кроме первого — а иначе получим увеличение числа от конструкции

Так вот первый матч исчерпывающий, т.к. в нем стоит вариант «_» - его учитывать не надо, в отличие от None. А второй не исчерпывающий, там надо оба ветвления учесть.

Так что 10. :)

и еще у цикломатического числа есть особенность — оно равно увеличивается как от иф-а с 1 веткой, так и с 2-мя, хотя мне кажется человеком легче воспринимаются иф-ы с 1 веткой

Что-то не понял. Речь об else if? Тогда вы не правы, его тоже надо считать.

> Всё условие либо выполняется, либо нет - т.е. два варианта. И один стейтмент в операторе if может быть пустым

иф-ы с 1 веткой зачастую не нарушают линейность кода; они играют примерно такую роль как «сигарета выкурена — выбросить в ближайшую урну» и не делают маршрут нелинейным

> А второй не исчерпывающий, там надо оба ветвления учесть.

где там не исчерпывающий?

З.Ы. иф с 1 веткой это тот, который без else

> иф-ы с 1 веткой зачастую не нарушают линейность кода; они играют примерно такую роль как «сигарета выкурена — выбросить в ближайшую урну» и не делают маршрут нелинейным

это если нет вложенных if'ов/других условных операторов

где там не исчерпывающий?

Ну вот этот не исчерпывающий:

match {
    case None => respond(FORBIDDEN, .......
    case Some(scheme) =>
        debug("authenticating with " + scheme.command)
        ........
}

Где гарантия, что придет обязательно None или Some?

иф с 1 веткой это тот, который без else

Понятно. Но все равно это ветвление, ИМХО.

1. судя по такому названию, как setupSuccessfulAuthResult, тебе лучше записывать их сначала на человеческом языке в виде комментариев (для себя это уже давно понял)

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

Например, вот это плохо:

// Нужно сохранить информацию о том, что юзер аутентифицирован.
logged(user);

setupSuccessfulAuthResut(user)

Комментарий нужен, если есть какая-то неочевидная особенность. Ну, скажем:

// Сохраняем результат аутентификации сейчас, чтобы для последующих
// операций он был уже доступен.
setupSuccessfulAuthResut(user)

2. если несколько секунд подумать над функцией handleInactiveUser, то будет понятно, что все «handle» сведется к «reject»; дальше очевидно, что никакие глобальные данные менять не придется; функция чистая, нужная только здесь — ну так незачем ее городить

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

Где гарантия, что придет обязательно None или Some?

Гарантии обеспечивает сам тип Option[T]

А, ну понятно.

Интересно, а если бы это был не «системный» тип, а пользовательский? Что произойдет, если я туда добавлю еще один вариант (будет None, Some и Cool)? :) Свитч перестанет быть исчерпывающим или будет ошибка рантайма при попытке использовать модуль с новым типом?

Интересно, а если бы это был не «системный» тип, а пользовательский?

Так а он и не системный, просто часть стандартной библиотеки.

Что произойдет, если я туда добавлю еще один вариант (будет None, Some и Cool)? :) Свитч перестанет быть исчерпывающим или будет ошибка рантайма при попытке использовать модуль с новым типом?

Не знаю, что будет если не делать перекомпиляции. Но если определение типа изменилось, то компилятор выдаст ошибку из-за того, что не все варианты перечислены. Именно этим паттерн-матчинг и Scala-овские case-классы хороши.

Однако, если в match добавить case _, то изменение списка вариантов в исходном типе уже не будет приводить к ошибке компиляции. Т.к. case _ «проглатывает» все.

>А итог написанного там прост: в приведенном вами коде паттерн-матчинг никаких преимуществ над if-ами не демострирует.

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

То мой стиль работы хотите пообсуждать, то байки про CMM рассказываете, то Фаулера с Беком опускаете, теперь вот на собеседования вас потянуло.

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

Воздержитесь от потоков сознания, пожалуйста.

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

* машина едет соскорость 40км/ч
вывод - машина едет зря.

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

Учись не бояться выражать свое _мнение_.

>Поскольку, как только вы вставили в match с Option[User] пару гуардов, ни о какой надежности Option[T] речь уже не идет.

То есть гварды - зло? Правильно? Их применять нельзя потому что ведут к
«ненадежному» коду?

Ты только что страницу флеймил что это не то что ты сказал и предлагал мне пойти перечитать что именно ты сказал, а теперь что?

(почему см.выше в обсуждении).

Да я видел. Потому что не нравится.

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

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

> в воздухе явно запахло РНР...

В воздухе запахло параметрическим полиморфизмом.

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

Она типизированная.

То есть гварды - зло? Правильно? Их применять нельзя потому что ведут к «ненадежному» коду?

Ваша способность домысливать с чужих слов превосходит мои самые прачные предположения.

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

>Насколько я могу судить на первый взгляд, у вас она раза в 2 превышает норму. :)

Посчитал, мультиэкзитная программа, формула: π - s + 2 = 7 - 8 + 2 = 1

Сюрприз?


Теперь я ее посчитаю для рефактореной программы (*)multiexit (1) singleexit сформулой M = E − N + 2P:
login(*) = 1
doLogin(*) = 1
KnownUserLoginHandler(1) = 1
....handle(*) = 2 - 3 + 2 = 1
....handleInactiveUserLogin(1) = 1
....handlePetrivkaAuthSchemeLogin(*) = 1
....handleUsualAuthSchemeLogin(*) = 1
....setupSuccessfulAuthResult(1) = 1
....findAuthScheme(?) = 1?

согласно:

For a single program (or subroutine or method), P is always equal to 1. Cyclomatic complexity may, however, be applied to several such programs or subprograms at the same time (e.g., to all of the methods in a class), and in these cases P will be equal to the number of programs in question, as each subprogram will appear as a disconnected subset of the graph.

cyclomatic complexity всей программы после рефакторинга = 9 + ?.

Гениальный ход был.

>Посчитал руками: приближенное значение 16

Ты что-то не то посчитал. Методику в студи.

http://en.wikipedia.org/wiki/Cyclomatic_complexity

с тобой не согласна.

>Итак, это все ваши аргументы (я бы вообще это к аргументан на отнёс)?

Ты привел ссылку на фаулера как на авторитета. Я показал что он не авторитет по указанной теме (ты ж не будешь спорить с этим?). Что тебе не нравится?

Приведи конкретные параметры восприятия по фаулеру - будем говорить по конкретным понятиям.

Видать, вы более известный специалист, чем Фаулер?

Видать есть такой раздел психологии - психология восприятия. Можешь привести хотя бы одну цитату из фаулера где он ссылается на указанный раздел психологии (или употребляет терминологию оттуда), а не просто пишет что-то типа «так читается лучше» или «это лучше для понимания»?

>точки расставлены там, где оно увеличивается на 1, так что получаем 8

Это мультиэкзитная программа. 8 получилось бы если бы после каждого respond был переход на exit - что и свяжет граф переходов усложнив. Здесь это не так - формула для мультиэкзита - другая.

> Но все равно не 8, а 11 (оператор ||,

Ты неправильно считаешь CC. Почитай что такое CC в теории сначала.

CC считается по control flow. Выхода control и if - 2. Сколько в один if условий не вставляй - это не отразится на control flow - все равно decision point 1 и выходов 2.

>>case None => respond(UNAUTHORIZED, «User not found»)

Потому что это else в if. decision point - 1.

>а пользовательский?

он «пользовательский».

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

Можно пример когда гварды не зло с учетом пунктов 1 и 2? В обоснование.

А то мало ли я еще чего придумаваю.

>Посчитал, мультиэкзитная программа, формула: π - s + 2 = 7 - 8 + 2 = 1

А, ну в принципе, да, на выход внимания не обратил.

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

А в рефакторенном варианте ничего подобного нет.

cyclomatic complexity всей программы после рефакторинга = 9 + ?.

Важна сложность метода, который мы анализируем. Зачем считать сложность всей программы таким странным способом, мне непонятно. Тогда любая мало-мальски сложная система будет невоспринимаема человеком. Это какой-то странный подход.

Гениальный ход был.

Каждый участок в отдельности сильно проще - это и есть ключевой момент.

CC считается по control flow. Выхода control и if - 2. Сколько в один if условий не вставляй - это не отразится на control flow - все равно decision point 1 и выходов 2.

Как справедливо заметил www_linux_org_ru, это если нет побочного эффекта во втором выражении. Так что «почитай что такое CC в теории сначала» (с) :)

Потому что это else в if. decision point - 1.

Нет, else - это:

case _ => respond(UNAUTHORIZED, «Authentication failed»)

> Посчитал, мультиэкзитная программа, формула: π - s + 2 = 7 - 8 + 2 = 1

чем хороши флеймы на лоре — они толкают осваивать что-то новое :-)

у мультиэкзитной программы ЦС будет не меньше чем число выходов

хинт: число бетти — это максимальное число разрезов, после которых граф еще не распадется (+ константа вроде -1, 0, +1 — не помню)

Можно пример когда гварды не зло с учетом пунктов 1 и 2?

Общаясь с вами я убедился в правдивости пословицы «Дурака учить — только портить». Так что я лучше последую народной мудрости и устранюсь из данного обсуждения.

> Ты неправильно считаешь CC. Почитай что такое CC в теории сначала. CC считается по control flow. Выхода control и if - 2. Сколько в один if условий не вставляй - это не отразится на control flow - все равно decision point 1 и выходов 2.

бугага

я любой код без циклов, в т.ч. и твой, могу переписать вообще без иф-ов, с одними только ||

> Можно пример когда гварды не зло с учетом пунктов 1 и 2? В обоснование. А то мало ли я еще чего придумаваю.

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

> В воздухе запахло параметрическим полиморфизмом.

не верю

по твоему предыдущему показанию

З.Ы. а у тебя дешево и сердито решить проблему можно так: назвать не find, а find_login

Класс стораджа универсальный, хранит не только юзеров.

значит, если мы find-у даем на вход строку, то на выход получаем Some(User), и следовательно, для получания на выходе Some(SomethingOther) find-у надо дать на вход нечто, отличающееся от строки — вывод: кривой дизайн

а если find всегда выдает Some(User), то его можно назвать find_user или find_user_by

>Но этот аргумент рассыпается, стоит лишь одну строку добавить в конец.

Ну давайте еще предположим что нужно там изменить чтобы все ухудшить - goto там расставим парочку:)

Так что по факту метод сложный

То есть несмотря на то что формальная метрика предложенная говорит обратное - все равно я не прав?:))

(не добавленная же в конец строка создаст эту сложность, так ведь?).

Именно она. Почитай что такое вообще cyclomatic complexity. Например обрати внимание на такое хитрое слово _cyclo_matic.

А в рефакторенном варианте ничего подобного нет.

Важна сложность метода, который мы анализируем.

Да как раз. То что cyclomatic complexity меряется только для единственного метода - это с какого неба упало? Из этого можно сделать вывод что чтобы писать несложные программы надо чтобы они состоянли исключительно из односточников. Ну перепиши так библиотеку Qt - кто ей после этого будет пользоваться? Совершенно очевидно что это абсурд.

Ты заметил в формуле число P? Зачем оно было введено, если оно для одного метода всегда 1?

Говоря простым языком - мы ставим проблему выявить цикломатическую сложность процесса логина и сравнить его для двух програм. С чего ты приравнял цикломатическую сложность всего указанного процесса к цикломатической сложности не всех методов его реализующих - а только одного по твоему выбору? А остольное что - не считается? Это что - не код?

Каждый участок в отдельности сильно проще - это и есть ключевой момент.

То есть ты хочешь сравнивать cyclomatic complexity кода который делает разные вещи?

Обращаясь к своему любимому методу ad absurdum я отрефакторю свою программу так:

def newlogin = def oldlogin
def oldlogin(.....)

и что - цикломатическая сложность устранилась? Смотри какой простой метод newLogin - там вообще даже ifов нет.

case _ => respond(UNAUTHORIZED, «Authentication failed»)

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

Как справедливо заметил www_linux_org_ru, это если нет побочного эффекта во втором выражении.

Это вообще в другую тему.

Так что «почитай что такое CC в теории сначала» (с) :)

Cyclomatic complexity это метрика основанная на понятии цикломатического ранга направленного графа, и обозначает количество ребер которые надо убрать, чтобы в графе не было циклов.

Цикломатическое число реализации алгоритма можно просто уменьшить в одном случае - когда есть ребра, которые можно убрать не нарушив алгоритм. Если ребра можно просто убрать и алгоритм не будет нарушен - это значит что это были мертвые ветки - unreachable code.

Если две реализации одного и того же алгоритма имеют разное цикломатичеческое число - то можно говорить о том что реализация алгоритма с меньшей цикломатической сложностью - проще. Слово «проще» обощначает, что граф меньше, интерпретировать программу предствленную в виде control flow graph можно эффективнее, компилятор может его эффективнее оптимизировать, сгенерированный код будет меньше и работать будет быстрее - потому что он минимален, а не с точки зрения «восприятия человеком» анлесс будет доказано, что человек имеет фон-неймановскую архитектуру и механизм его восприятия эквивалентен реализации гццшного кодогенератора.

Большое значение цикломатического числа в разработке ПО _может_ служить индикацией о том, что данный метод будет тяжело протестировать вследствие большого количества путей прохождения алгоритма - то есть грубо говоря надо будет сделать большое количество/большую сложность unit testов. В этом случае _может_ иметь иметь место професс рефакторинга с целью создания абстракции, которая позволит упростить тестиорвание. Например при реализации решения квадратного уравнения, тесты на вычисление корней можно реализовать в виде полного тестирования на кучу значений a,b,c, а можно абстрагировать как функцию и учесть, что существует две ветви D<0 и D>=0, и надо написать всего два теста для этих случаев. То есть цикломатическое число служит формальным индикатором того, что это сложно тестировать - однако только _может_, а не обязательно это так - потому что надо учитывать массу метрик - например связность кода, которая может возрасти, или принципиальная невозможность абстракции (например CC в реализации синтаксического анализатора можееть быть громадной - однако ее разнесение на кучу методов нихрена не улучшит), или как например в данном случае - увеличение количества непроверенных инвариантов - то есть все эти методы с CC 1 нихрена не проверяют даже входных параметров, то есть подобный рефакторинг увеличил количество потенциальных багов, а не уменьшил.



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

>у мультиэкзитной программы ЦС будет не меньше чем число выходов

Нет. См мой ответ AlexKR.

>Общаясь с вами я убедился в правдивости пословицы «Дурака учить — только портить». Так что я лучше последую народной мудрости и устранюсь из данного обсуждения.

Предсказуемо. Слив защитан.

не верю

мамой клянусь!

trait JSONStorage[T <: AnyRef] {
        def find( id: String )( implicit m: Manifest[T] ): Option[T] 
}

для получания на выходе Some(SomethingOther) find-у надо дать на вход нечто, отличающееся от строки — вывод: кривой дизайн

Ты не гони лошадей. Для того чтобы получить что-то отличное от Some нужно инстанциировать что-то отличное от Storage . вывод - ты поспешил.

у мультиэкзитной программы ЦС будет не меньше чем число выходов

Нет. См мой ответ AlexKR.

включи мозги, а? ретурны это тоже дуги

if(p1()) return f1()
if(p2()) return f2()
if(p3()) return f3()
return g()

эквивалентно

if(p1()) result=f1()
else if(p3()) result=f2()
else if(p3()) result=f3()
else result=g()
return result

>То есть несмотря на то что формальная метрика предложенная говорит обратное - все равно я не прав?:))

Именно она. Почитай что такое вообще cyclomatic complexity. Например обрати внимание на такое хитрое слово _cyclo_matic.

Вот все же не могу я согласиться с этим. Не может добавление линейной строки увеличить сложность. Вот пишу я в жабе той же - «return false;» в середине метода. Потом добавляю строку в конец - ничего страшного не происходит. А в Скале все становится с ног на голову - резко много выходов превращаются в один - причем из-за добавления строки. Это ерунда какая-то. Я понимаю, это специфика языка - «все есть выражение» и т.п. Но, ИМХО, метод наподобие рассматриваемого нельзя считать многовыходным.

Да как раз. То что cyclomatic complexity меряется только для единственного метода - это с какого неба упало?

Ну, вообще померить можно что угодно. Тогда надо и библиотечный код измерять - почему это мы только пользовательским ограничиваемся? А там и до инструкций процессора недалеко. :) Но нафига - неясно. 100 мелких частей с суммарной сложностью в 1000 лучше, чем одна часть со сложностью 100.

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

Именно, именно. Библиотека Smalltalk на 90% состоит из микро-методов.

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

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

С чего ты приравнял цикломатическую сложность всего указанного процесса к цикломатической сложности не всех методов его реализующих - а только одного по твоему выбору?

Я не приравнял. Где это я приравнял?

А остольное что - не считается? Это что - не код?

Это код - с которым разбираться будем ОТДЕЛЬНО.

и что - цикломатическая сложность устранилась? Смотри какой простой метод newLogin - там вообще даже ifов нет.

Да, это максимально простой код. К чему и надо стремиться. Что у него внутри - смотрим отдельно.

> trait JSONStorage[T <: AnyRef]

ладно, тогда согласен с полиморфизмом

однако название find было выбрано неконсистентно со скаловскими коллекциями, поэтому должно быть заменено на хотя бы getBy

кстати, а никто не сделал на имплицитах удобного решения той проблеме, что в скале нельзя сделать статический метод, имеющий приватный доступ к объектам класса?

>включи мозги, а? ретурны это тоже дуги

Но не циклы. _Cyclo_matic complexity.

Разница огромная. Что проще - обойти с одним посещением вершин дерево или граф с циклами?

Вот все же не могу я согласиться с этим.

С чем - с официальным определением?

Не может добавление линейной строки увеличить сложность.

Может.

      0                                       0
     / \                                     / \
    0   0                                   0   0
     \ /
      0 <- вот твоя строка.

Сложность алгоритмов для обработки этих двух структур просто кардинально отличается.

Потом добавляю строку в конец - ничего страшного не происходит.

Кодогенератору, оптимизатору и прочем его друзьям это расскажи.

Тогда надо и библиотечный код измерять - почему это мы только пользовательским ограничиваемся?

потому что библиотечный одинаков и в данном случае мы предполагаем что он константа с которой мы делать ничего не можем и не будем:)

100 мелких частей с суммарной сложностью в 1000 лучше, чем одна часть со сложностью 100.

Кто тебе такое сказал? Приведи ссылки.

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

Тогда ты говоришь об усредненной цикломатической сложности методов. Ты не мог бы показать как _усредненная_ цикломатическая сложность влияет вообще хоть на что нибудь?

Я не приравнял. Где это я приравнял?

Ну ты же хочешь сравнивать цикломатическую сложность метода который реализует весь алгоритм с чем - с усредненной цикломатической сложностью кучи методов, каждый из которых не реализует алгоритм?

Ты не заметил что сравниваешь несравнимое?

Цикломатическая сложность вообще так как ты ее хочешь заюзать - не используется. Она используется грубо говоря как градусник с температурой - для индикации что что-то может быть не так. Но «не так» не в самом значении CC - а в неудобстве тестирования например. А если тестировать удобно - то значение цикломатической сложности - хоть миллион - это не имеет никакого значения.

и что - цикломатическая сложность устранилась? Смотри какой простой метод newLogin - там вообще даже ifов нет.

Да, это максимально простой код. К чему и надо стремиться. Что у него внутри - смотрим отдельно.

я победил?:))

> Разница огромная. Что проще - обойти с одним посещением вершин дерево или граф с циклами?

ыыы, какое упорство в очевидной вещи; в таких случаях в оффлайне я спорю на 100 баксов

кстати, а никто не сделал на имплицитах удобного решения той проблеме, что в скале нельзя сделать статический метод, имеющий приватный доступ к объектам класса?

В каком это смысле?

object T extends Application {

        new T().x
}

class T {
   private var x = 5;
}

>ыыы, какое упорство в очевидной вещи;

То есть ты считаешь что граф с циклами?!

>Может.

Ну увеличьте мне таким образом сложность в Java. Что, не выходит? :) Что-то в вашем подходе неправильно, но я пока не понял, что именно.

Кодогенератору, оптимизатору и прочем его друзьям это расскажи.

Это вообще к чему? Цикломатическая сложность не увеличивается. Что там нагенерируется - это совершенно другой вопрос, не имеющий отношения к теме.

Кто тебе такое сказал? Приведи ссылки.

Мне казалось, это очевидно. Есть 100 процедур со сложностью 10, каждую из которых в отдельности человек может понять. И есть одна бого-процедура со сложностью 100, понять которую человек не может. Какие ссылки вам нужны? Что белое - это белое, а черное - это черное? :)

Тогда ты говоришь об усредненной цикломатической сложности методов.

Нет.

Ну ты же хочешь сравнивать цикломатическую сложность метода который реализует весь алгоритм с чем - с усредненной цикломатической сложностью кучи методов, каждый из которых не реализует алгоритм?

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

Ты не заметил что сравниваешь несравнимое?

Я заметил, что вы меня не понимаете. :)

я победил?:))

Нет. :)

>Ну увеличьте мне таким образом сложность в Java. Что, не выходит?

Выходит. См пример www_linux_org_ru - он ее увеличил переведя структуру данных из дерева в граф с циклами.

Это вообще к чему?

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

Что там нагенерируется - это совершенно другой вопрос, не имеющий отношения к теме.

А что имеет отношение к теме? «Восприятие» чтоле? Ты мне кажется не совсем верно воспринимаешь значение слова «сложность». Оно в данном случае обозначает _колличество(цифру)_ независимых путей выполнения программы. А не «впечатление» произведенное исходным текстом на читателя.

Сама метрика вообще была разработана в рамках исследования стратегий тестирования. И имеет смысл только в ней. По причине того чтособственно значение CC = колличеству тесткейсов на код. Этот метод называется Basis Path Testing. Это собственно смысл существования метрики - она является матаппаратом для выявления количества тесткейсов. А никак не «сложностей перевода».

Мне казалось, это очевидно.

«Почему собственно меньше - значит проще? Вы скажете что для рождения ребенка двое людей обменялись жидкостями, я скажу что его принес один аист». (C) Др хаус.

Есть 100 процедур со сложностью 10, каждую из которых в отдельности человек может понять. И есть одна бого-процедура со сложностью 100, понять которую человек не может. Какие ссылки вам нужны?

Есть 100 процедур со сложностью 10, суперпозицию которых человек понять не может - то есть не может даже сказать, что делает эта программа в целом. И есть одна бого-процедура со сложностью 100 в которой совершенно ясно, что она делает. Я тоже могу такой неподкрепленный ничем вброс сделать:)

Ссылки на работы по психологии где исследуется влияние количества basis paths на перцепшен программы индивидом:)

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

Нет. :)

Как нет - я ж достиг того к ем надо стремиться - программа из одного слова:)

>Выходит. См пример www_linux_org_ru - он ее увеличил переведя структуру данных из дерева в граф с циклами.

Это где? Я не заметил.

А что имеет отношение к теме? «Восприятие» чтоле? Ты мне кажется не совсем верно воспринимаешь значение слова «сложность». Оно в данном случае обозначает _колличество(цифру)_ независимых путей выполнения программы. А не «впечатление» произведенное исходным текстом на читателя.

Да, восприятие. И пропорциональное количество дефектов в коде.

http://en.wikipedia.org/wiki/Cyclomatic_complexity#Applications

Там про это есть.

Есть 100 процедур со сложностью 10, суперпозицию которых человек понять не может - то есть не может даже сказать, что делает эта программа в целом.

Да, не может. Ни один человек в мире не может охватить «В ЦЕЛОМ» (с) более-менее сложную систему. Это нормально. :)

И есть одна бого-процедура со сложностью 100 в которой совершенно ясно, что она делает.

Нет, не ясно. С ней ситуация еще хуже - ни «в целом» не понятно, ни на части не разбить.

Я тоже могу такой неподкрепленный ничем вброс сделать:)

Про вброс да, согласен. :)

Ссылки на работы по психологии где исследуется влияние количества basis paths на перцепшен программы индивидом:)

Могу только дать ссылку на википедию (выше), где написано про корреляцию цикломатической сложности и количества дефектов. :)

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

Ничего я никуда не натягиваю. Большая сложность - плохо. Маленькая - хорошо. Сколько методов в системе - пофиг. :)

К стати на счет этого мегахендлера:

In computer programming, a poltergeist (or gypsy wagon) is a short-lived, typically stateless object used to perform initialization or to invoke methods in another, more permanent class. It is considered an anti-pattern.

A poltergeist can often be identified by its name; they are often called «manager_», «controller_», «start_process», etc.

Или в нашем случае handler.

:)))))

Scala version 2.7.7.final (Java HotSpot(TM) Client VM, Java 1.6.0_22) отказывается выполнять твой код, хотя и компилирует:

java.lang.NoSuchMethodException: T.main([Ljava.lang.String;)

попроще переписанный вариант страдает тем же:

object Hello {
    def main( args: Array[String] ) {
        println(new Hello().x)
    }
}

class Hello {
    private var x = 5;
}

java.lang.NoSuchMethodException: Hello.main([Ljava.lang.String;)