Re[5]: Предлагаю переехать в "Когда распечатка удобнее IDE?" - Компьютерные священные войны

Приветствую всех !

Постоянно вижу код, в котором фигурные скобки расставляются в таком стиле:

if (a == b) {
  ... }

Но это же чертовски неудобно, да еще когда повсюду разные "какашки", извините,
вроде doxygen-овских комментариев. По-моему, такое форматирование затрудняет восприятие кода.
Да что там "затрудняет" — вообще делает этот процесс кошмарным !
Почему-то встречаю такой код постоянно, в разработках самого разного уровня и объема.
Приведу реальный пример.

case EXTRA:
    if (state->flags & 0x0400) {
        copy = state->length;
        if (copy > have) copy = have;
        if (copy) {
            if (state->head != Z_NULL &&
                state->head->extra != Z_NULL) {
                len = state->head->extra_len - state->length;
                zmemcpy(state->head->extra + len, next,
                        len + copy > state->head->extra_max ?
                        state->head->extra_max - len : copy);
            }
            if (state->flags & 0x0200)
                state->check = crc32(state->check, next, copy);
            have -= copy;
            next += copy;
            state->length -= copy;
        }
        if (state->length) goto inf_leave;
    }
    state->length = 0;
    state->mode = NAME;

Ужасно ! Тут же черт ногу сломит ! При виде закрывающей фигурной скобки хочется сразу отыскать ее
"старшую сестру", чтобы мысленно обозначить выделенный ими кусок кода, а для этого приходится бегать
глазами и выискивать конструкции типа if и while. А была бы она на том же горизонтальном уровне —
все было бы гораздо проще. Если кому-то показалось, что я утрирую — что ж, может быть.
А вам когда-нибудь приходилось по долгу службы разбираться в такой вот каше ?
Лично у меня уже после 20-30К строк от постоянных метаний уже реально болят глаза.
Этот код при просмотре хочется выкинуть и переписать заново, на большом белом листе, с "кислородом",
где логические и вложенные блоки были бы явно обозначены. Хотя бы так:

case EXTRA:
    if (state->flags & 0x0400)
        {
        copy = state->length;
                
        if (copy > have)
            {
            copy = have;
            }
                    
        if (copy)
            {
            if (state->head != Z_NULL && state->head->extra != Z_NULL)
               {
               len = state->head->extra_len - state->length;
               zmemcpy(state->head->extra + len, next,
                   len + copy > state->head->extra_max ?
                   state->head->extra_max - len : copy);
               }
                        
            if (state->flags & 0x0200)
               {
               state->check = crc32(state->check, next, copy);
               }
                        
            have -= copy;
            next += copy;
            state->length -= copy;
            }
                    
        if (state->length) goto inf_leave;
        }
                
    state->length = 0;
    state->mode = NAME;

Ну неужели я не прав, и первый вариант читается лучше ?
Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

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

O>Ну неужели я не прав, и первый вариант читается лучше ?
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

Обычно пишут так, как решил главный в проекте. Мне не нравится вариант с отступами перед скобками, кому-то не нравятся скобки на отдельных строчках, а пишем все равно в команде, и тут одинаковый стиль помогает.
Если так интересно — можете откопать холивар на эту тему (а может и не один), в этом же разделе.

O>Постоянно вижу код, в котором фигурные скобки расставляются в таком стиле:

O>

O>if (a == b) {
O>  ... }
O>

вообще-то ты привел пример другого стиля:

if (a == b) {
  ...
}

O> или code convention, которому следуют, не задумываясь ?

еще K&R использовали такой стиль

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

O>Ну неужели я не прав, и первый вариант читается лучше ?

Не прав. И, что самое смешное, аргументы я приведу те же самые:

O>Ужасно ! Тут же черт ногу сломит ! При виде закрывающей фигурной скобки хочется сразу отыскать ее
O>"старшую сестру", чтобы мысленно обозначить выделенный ими кусок кода, а для этого приходится бегать
O>глазами и выискивать конструкции типа if и while. А была бы она на том же горизонтальном уровне -
O>все было бы гораздо проще. Если кому-то показалось, что я утрирую — что ж, может быть.
O>А вам когда-нибудь приходилось по долгу службы разбираться в такой вот каше ?
O>Лично у меня уже после 20-30К строк от постоянных метаний уже реально болят глаза.
O>Этот код при просмотре хочется выкинуть и переписать заново, на большом белом листе, с "кислородом",
O>где логические и вложенные блоки были бы явно обозначены. Хотя бы так:

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

Ты прав. Айда к нам. У нас вместо этих скобок пишут православные

Begin End

Есть за что глазу зацепиться

avalon 1.0rc3 rev 368, zlib 1.2.3

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

O>Приведу реальный пример.
Прогнал через автоформатирование и StyleCop.

На выходе

    case EXTRA:
      if (state->flags & 0x0400)
      {
        copy = state->length;
        if (copy > have)
        {
          copy = have;
        }
        if (copy)
        {
          if (state->head != Z_NULL
           && state->head->extra != Z_NULL)
          {
            len = state->head->extra_len - state->length;

            zmemcpy(
              state->head->extra + len,
              next,
              (len + copy) > state->head->extra_max ?
                state->head->extra_max - len :
                copy);
          }
          if (state->flags & 0x0200)
          {
            state->check = crc32(state->check, next, copy);
          }
          have -= copy;
          next += copy;
          state->length -= copy;
        }
        if (state->length)
        {
          goto inf_leave;
        }
      }
      state->length = 0;
      state->mode = NAME;

Холиварить тут не о чем, у каждой команды свой стиль, никого не переубедишь.
Я бы постарался избавиться от goto, растащить часть кода по мелким методам и не так активно изменять state. Но это совсем не значит, что я правее вас

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

O>Постоянно вижу код, в котором фигурные скобки расставляются в таком стиле:

O>

O>if (a == b) {
O>  ... }
O>

ага, за такое оформление я бы тоже руки отрывал

стиль K&R, кстати, рулит, хотя я сам раньше очень защищал стиль Олмана. ничего, переучился.

и даю слово, исходный код своего проекта с кучей Java/JS/CSS стало читать намного проще + действительно, экономия места + более компактный листинг

O>А была бы она на том же горизонтальном уровне -
O>все было бы гораздо проще.

а я теперь не так по скобках определяю это, а скорее — по содержанию и его же отступах

у меня всё

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

O>Приветствую всех !

O>Постоянно вижу код, в котором фигурные скобки расставляются в таком стиле:

O>

O>if (a == b) {
O>  ... }
O>

O>Ну неужели я не прав, и первый вариант читается лучше ?
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

Сколько людей, столько и мнений. Я привык к такому стилю. И так как он рекомендован Sun, то много кода на Java написано именно так. Но для C++ такой стиль меньше подходит из-за некоторых отличий в синтаксисе.

Лично я не люблю стиль вида

if (a == b)
{
  ...
}

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

Оба варианта страшные.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

T>Лично я не люблю стиль вида
T>Мне он кажется слишком разреженным. Получается принудительная пустая строка, а иногда это мешает.

А это зависит от стиля в целом. Я стараюсь разносить код по мелким методам — сильно помогает понять намерения писавшего код. В результате основной код выходит крайне лаконичным, но перенасыщенным

Так что отступы, наоборот, помогают.

Чтоб понятней было, что имею в виду:

Скрытый текст

    private static PathToken ParseToken(PathTokenInfo parsingToken)
    {
      PathToken result;

      if (IsCurrentDirectoryToken(parsingToken))
      {
        result = CurrentDirectoryToken.Instance;
      }
      else if (IsParentDirectoryToken(parsingToken))
      {
        result = ParentDirectoryToken.Instance;
      }
      else
      {
        string tokenName = GetNormalizedTokenName(parsingToken);

        if (parsingToken.SeparatorCount == 0)
        {
          result = new FileToken(tokenName);
        }
        else
        {
          result = new DirectoryToken(tokenName);
        }
      }

      return result;
    }

Я конечно могу сэкономить пару проверок, развернув код обратно в простыню на пару сотен строк, но как по мне — оно того не стоит.

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

O>Постоянно вижу код, в котором фигурные скобки расставляются в таком стиле:

O>

O>if (a == b) {
O>  ... }
O>

O>Но это же чертовски неудобно
Да, кошмарный стиль.
Но у меня есть один проект где такой стиль принят изначально (до того как наша команда туда подключилась) и приходится писать в таком вот говностиле.
Без ассиста с подсветкой парных скобок и сворачивалки в режиме outline statements жить просто нельзя.

Мне больше нравится так:
O>

O>case EXTRA:
O>    if (state->flags & 0x0400)
O>    {
O>        copy = state->length;
                
O>        if (copy > have)
O>            copy = have;
                    
O>        if (copy)
O>        {
O>            if (state->head != Z_NULL && state->head->extra != Z_NULL)
O>            {
O>               len = state->head->extra_len - state->length;
O>               zmemcpy(state->head->extra + len, next, (len + copy > state->head->extra_max) ? state->head->extra_max - len : copy);
O>            }
                        
O>            if (state->flags & 0x0200)
O>               state->check = crc32(state->check, next, copy);
                        
O>            have -= copy;
O>            next += copy;
O>            state->length -= copy;
O>        }
                    
O>        if (state->length) 
O>                        goto inf_leave;
O>    }
                
O>    state->length = 0;
O>    state->mode = NAME;
O>

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

H>Ты прав. Айда к нам. У нас вместо этих скобок пишут православные

Begin End

Есть за что глазу зацепиться

Ну, я к примеру паскаль освоил раньше чем С, и помню с каким облегчением избавился от опостылевших begin end.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

[нудным голосом] Отступы маленькие, некошерные; разбивка на строки слишком частая.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Ops>Обычно пишут так, как решил главный в проекте. Мне не нравится вариант с отступами перед скобками, кому-то не нравятся скобки на отдельных строчках, а пишем все равно в команде, и тут одинаковый стиль помогает.
Ops>Если так интересно — можете откопать холивар на эту тему (а может и не один), в этом же разделе.

Несмотря на то, что тема создана в разделе "КСВ", холивар я уж точно не собирался разводить.
Просто интересно — чем можно оправдать такую расстановку скобок, кроме того, что их
рекомендуют в Sun и ею пользуются разные авторитеты. Есть ли польза от нее, кроме компактности ?
Как по мне — так только вред.

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

А хотя бы одного довода в пользу Sun-овской рекомендации (я буду так ее называть) я не услышал.
Кроме экономии пространства. Ну и кому нужна такая экономия ? Компилятору ?

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

S>Холиварить тут не о чем, у каждой команды свой стиль, никого не переубедишь.
S>Я бы постарался избавиться от goto, растащить часть кода по мелким методам и не так активно изменять state. Но это совсем не значит, что я правее вас

Код не мой. Я бы вообще по-другому писал.

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

M>Оба варианта страшные.

А Вы напишите не страшно. Нет, серъезно, без шуток. Просто любопытно.

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

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

M>>Оба варианта страшные.

O>А Вы напишите не страшно. Нет, серъезно, без шуток. Просто любопытно.

Sinix дал выше оформление получше.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

O>К примеру, я могу обосновать почти каждый элемент своего стиля.
объясни сдвиг скобки:

    if (state->flags & 0x0400)
        {

PS. а раз мы всё же в КСВ, я бы за такой сдвиг расстреливал

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

CC>[нудным голосом] Отступы маленькие, некошерные; разбивка на строки слишком частая.

да пжалста

        private static PathToken ParseToken(PathTokenInfo parsingToken) {
            PathToken result;
            if (IsCurrentDirectoryToken(parsingToken))
                result = CurrentDirectoryToken.Instance;
            else if (IsParentDirectoryToken(parsingToken))
                result = ParentDirectoryToken.Instance;
            else {
                string tokenName = GetNormalizedTokenName(parsingToken);
                if (parsingToken.SeparatorCount == 0)
                    result = new FileToken(tokenName);
                else
                    result = new DirectoryToken(tokenName);
            }
            return result;
        }

И как, легче читается?

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

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

S>Чтоб понятней было, что имею в виду:
S>

Скрытый текст

S>    private static PathToken ParseToken(PathTokenInfo parsingToken)
S>    {
S>      PathToken result;

S>      if (IsCurrentDirectoryToken(parsingToken))
S>      {
S>        result = CurrentDirectoryToken.Instance;
S>      }
S>      else if (IsParentDirectoryToken(parsingToken))
S>      {
S>        result = ParentDirectoryToken.Instance;
S>      }
S>      else
S>      {
S>        string tokenName = GetNormalizedTokenName(parsingToken);

S>        if (parsingToken.SeparatorCount == 0)
S>        {
S>          result = new FileToken(tokenName);
S>        }
S>        else
S>        {
S>          result = new DirectoryToken(tokenName);
S>        }
S>      }

S>      return result;
S>    }
S>

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

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

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

O>>К примеру, я могу обосновать почти каждый элемент своего стиля.
A>объясни сдвиг скобки:
A>

A>    if (state->flags & 0x0400)
A>        {
A>

A>PS. а раз мы всё же в КСВ, я бы за такой сдвиг расстреливал

Сдвиг скобки сейчас объясню (по причине того, что мы в КСВ

).
Хотя ее положение непринципиально, можно ее и без отступа писать.
Скобка — это начало вложенного блока. То есть, она все же имеет большее
отношение к этому блоку, чем ко внешнему, поэтому и должна быть с ним на одном уровне.
Но абстрактно. Лично я и так и так писал, в разное время.

if (a == b)
    {
    ...
    ...
    ...
    }

else
    {
    ...
    ...
    ...
    }

Ну как, дико, да ?

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

S>Чтоб понятней было, что имею в виду:
S>

Скрытый текст

S>    private static PathToken ParseToken(PathTokenInfo parsingToken)
S>    {
S>      PathToken result;

S>      if (IsCurrentDirectoryToken(parsingToken))
S>      {
S>        result = CurrentDirectoryToken.Instance;
S>      }
S>      else if (IsParentDirectoryToken(parsingToken))
S>      {
S>        result = ParentDirectoryToken.Instance;
S>      }
S>      else
S>      {
S>        string tokenName = GetNormalizedTokenName(parsingToken);

S>        if (parsingToken.SeparatorCount == 0)
S>        {
S>          result = new FileToken(tokenName);
S>        }
S>        else
S>        {
S>          result = new DirectoryToken(tokenName);
S>        }
S>      }

S>      return result;
S>    }
S>

Хороший код. Вот я к такому и стремлюсь.

Здравствуйте, telek1024, Вы писали:
...
T>Лично я не люблю стиль вида
T>

T>if (a == b)
T>{
T>  ...
T>}
T>

T>Мне он кажется слишком разреженным. Получается принудительная пустая строка, а иногда это мешает.

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

Но ведь и мониторы то давно уже не 80 на 25 строчек

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

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

Мне редко приходится скроллить: методы небольшие, переход — ctrl-click. Кода много, куда важнее быстро понять что он делает (особенно, если долго с ним не работал).

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

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

O>... При виде закрывающей фигурной скобки хочется сразу отыскать ее
O>"старшую сестру", чтобы мысленно обозначить выделенный ими кусок кода, а для этого приходится бегать
O>глазами и выискивать конструкции типа if и while...

А я не ищу "старшую сестру". Да и на "младшую" обычно внимания не обращаю. Хватает отступов.

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

O>Сдвиг скобки сейчас объясню (по причине того, что мы в КСВ

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

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

A>в твоём случае границы блока в виде скобок сливаются с самим блоком, и границей блока зрительно кажутся части внешнего блока. и нафиг в таком случае тратить две строки на скобки, непонятно.

Если честно — я не понял про границы. Можно "на пальцах" ?

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

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

A>>в твоём случае границы блока в виде скобок сливаются с самим блоком, и границей блока зрительно кажутся части внешнего блока. и нафиг в таком случае тратить две строки на скобки, непонятно.

O>Если честно — я не понял про границы. Можно "на пальцах" ?

Если скобки с отступом, вот так:

if(условие)
    {
    какой-то код
    }

то скобки не выполняют ф-цию визульного выделения блока (или границ блока). Их можно убрать, как сделали в Питоне, например.

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

CC> Ну, я к примеру паскаль освоил раньше чем С, и помню с каким облегчением избавился от опостылевших begin end.

У меня все было ровно наоборот

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

avalon 1.0rc3 rev 368, zlib 1.2.3

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

O>

O>if (a == b) {
O>  ... }
O>

Это не правильно !

Правильно будет так

a == b && (printf(someting),update(someting),count++);

O>Ну неужели я не прав, и первый вариант читается лучше ?
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

Оба варианта одинаково плохи, форматированием проблему не решить.

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

O>Ужасно ! Тут же черт ногу сломит !

Это стандартный K&R-стиль. В таком стиле написаны тонны ~~говно~~кода. Нравится он вам или нет, но в таком стиле надо уметь читать. Хотя замечу, сам я предпочитаю фигурные скобки на отдельной строке, и чтобы тело if'а и цикла тоже было на отдельной строке, даже если оно тривиальное (в случае тривиального без отдельных скобок, впрочем).

O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

Всеобщий заговор.

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

sc>Если скобки с отступом, вот так:
sc>

sc>if(условие)
sc>    {
sc>    какой-то код
sc>    }
sc>

sc>то скобки не выполняют ф-цию визульного выделения блока (или границ блока). Их можно убрать, как сделали в Питоне, например.

Все равно непонятно. Как это не выполняют ? Так, что ли, лучше:

if (условие 1)    {
    какой-то код
        } else if (условие 2) { еще код
               } else
    { ну и еще немножко кода
}

[/ccode]

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

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

sc>>Если скобки с отступом, вот так:
sc>>

sc>>if(условие)
sc>>    {
sc>>    какой-то код
sc>>    }
sc>>

sc>>то скобки не выполняют ф-цию визульного выделения блока (или границ блока). Их можно убрать, как сделали в Питоне, например.

O>Все равно непонятно. Как это не выполняют ? Так, что ли, лучше:

O>

O>if (условие 1)    {
O>    какой-то код
O>        } else if (условие 2) { еще код
O>               } else
O>    { ну и еще немножко кода
O>}
O>

O>[/ccode]

теперь я уже ничего не понял

вот исходный код, немного "причесанный"

if (условие 1)    
{
    какой-то код
} 
else if (условие 2) 
{ 
    еще код
} 
else    
{ 
    ну и еще немножко кода
}

здесь каждая пара скобок {} выделяет отдельный блок. если скобки сделать так:

if (условие 1)    
    {
    какой-то код
    } 
else if (условие 2) 
    { 
    еще код
    } 
else    
    { 
    ну и еще немножко кода
    }

то блок выделятеся уже не скобками {}, а отступами. Следовательно визуальную ф-цию выделения блока скобки не выполняют. Следовательно скобки можно убрать. Такой подход применили в Питоне.

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

sc>Здравствуйте, telek1024, Вы писали:
sc>...
T>>Лично я не люблю стиль вида
T>>

T>>if (a == b)
T>>{
T>>  ...
T>>}
T>>

T>>Мне он кажется слишком разреженным. Получается принудительная пустая строка, а иногда это мешает.

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

sc>А еще комментарии "разрежают" код

Но ведь и мониторы то давно уже не 80 на 25 строчек

Сейчас популяризуются ноуты. Так что можно считать, что экраны "сузились".

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

O>Приветствую всех !

Господи, ну когда уже все освоят элементарную утилиту indent и перестанут спорить где какую скобку ставить????

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

D>еще K&R использовали такой стиль
когда они его использовали, размеры мониторов и разрешение были совсем другими, а стиль говенный, независимо от того, кто его использовал. Нужен он только там, где есть необходимость экономить пространство, на сегодняшний день это только книги.

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

выше уже упомянули ноуты.

Скажем, сегодняшний google code style использует этот стиль и накладывает 80-символьное ограничение.

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

D>Скажем, сегодняшний google code style использует этот стиль и накладывает 80-символьное ограничение.
Во-первых, при чем здесь 80-символьное ограничение, если оно по ширине, а не по высоте? Хотя и его считаю уже не актуальным. А во-вторых, сейчас полно ноутбуков с нормальными дисплеями и разрешением. У меня 15 дюймовый ноут, вполне нормально.

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

S>

На выходе

S>    case EXTRA:
S>      if (state->flags & 0x0400)
S>      {
S>        copy = state->length;
S>        if (copy > have)
S>        {
S>          copy = have;
S>        }
S>        if (copy)
S>        {
S>          if (state->head != Z_NULL
S>           && state->head->extra != Z_NULL)
S>          {
S>            len = state->head->extra_len - state->length;

S>            zmemcpy(
S>              state->head->extra + len,
S>              next,
S>              (len + copy) > state->head->extra_max ?
S>                state->head->extra_max - len :
S>                copy);
S>          }
S>          if (state->flags & 0x0200)
S>          {
S>            state->check = crc32(state->check, next, copy);
S>          }
S>          have -= copy;
S>          next += copy;
S>          state->length -= copy;
S>        }
S>        if (state->length)
S>        {
S>          goto inf_leave;
S>        }
S>      }
S>      state->length = 0;
S>      state->mode = NAME;
S>

CC>>[нудным голосом] Отступы маленькие, некошерные; разбивка на строки слишком частая.
S>

да пжалста

S>        private static PathToken ParseToken(PathTokenInfo parsingToken) {
S>            PathToken result;
S>            if (IsCurrentDirectoryToken(parsingToken))
S>                result = CurrentDirectoryToken.Instance;
S>            else if (IsParentDirectoryToken(parsingToken))
S>                result = ParentDirectoryToken.Instance;
S>            else {
S>                string tokenName = GetNormalizedTokenName(parsingToken);
S>                if (parsingToken.SeparatorCount == 0)
S>                    result = new FileToken(tokenName);
S>                else
S>                    result = new DirectoryToken(tokenName);
S>            }
S>            return result;
S>        }
S>

S>И как, легче читается?

Хуже. Потому что ты скобки сделал не так как в первом примере.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Игoрь, Вы писали:

D>>Скажем, сегодняшний google code style использует этот стиль и накладывает 80-символьное ограничение.
И>Во-первых, при чем здесь 80-символьное ограничение, если оно по ширине, а не по высоте? Хотя и его считаю уже не актуальным.

80-, или, точнее, 72-символьное ограничение актуально в случаях, когда патчи пересылаются через email в тексте сообщений (не в аттачах).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

sc>>А еще комментарии "разрежают" код

Но ведь и мониторы то давно уже не 80 на 25 строчек

T>Сейчас популяризуются ноуты. Так что можно считать, что экраны "сузились".
Сузились?
Вон народ про ноуты с 1920х1200 трёт.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

O>>Приветствую всех !

DOO>Господи, ну когда уже все освоят элементарную утилиту indent и перестанут спорить где какую скобку ставить????

элементарную утилиту indent такая элементарная...
Что от кода С++ с шаблонами камня на камне не оставляет.

CC>Вон народ про ноуты с 1920х1200 трёт.

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

Потом, у меня 3 личных и 3 корпоративных ноута, ни у одного нет больше 1366x768. мне их все выкинуть? или тебе подарить?

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

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

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

Можно.

Но во-первых, такое может быть запрещено code style. И у Sun это запрещено.
А во-вторых, отсутствие скобок делает код неоднородным. Где-то есть, где-то нет. А если нужно добавить выражения в код, где нет скобок?

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

T>Но во-первых, такое может быть запрещено code style. И у Sun это запрещено.
Ну это их тараканы и соотвественно их трудности.

T>А во-вторых, отсутствие скобок делает код неоднородным. Где-то есть, где-то нет.
И?

T>А если нужно добавить выражения в код, где нет скобок?
Добавляешь скобки. Делов то.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

1.

O>

O>case EXTRA:
O>    if (state->flags & 0x0400) {
O>        copy = state->length;
O>        if (copy > have) copy = have;
O>        if (copy) {
O>            if (state->head != Z_NULL &&
O>                state->head->extra != Z_NULL) {
O>                len = state->head->extra_len - state->length;
O>                zmemcpy(state->head->extra + len, next,
O>                        len + copy > state->head->extra_max ?
O>                        state->head->extra_max - len : copy);
O>            }
O>            if (state->flags & 0x0200)
O>                state->check = crc32(state->check, next, copy);
O>            have -= copy;
O>            next += copy;
O>            state->length -= copy;
O>        }
O>        if (state->length) goto inf_leave;
O>    }
O>    state->length = 0;
O>    state->mode = NAME;
O>

2.

O>

O>case EXTRA:
O>    if (state->flags & 0x0400)
O>        {
O>        copy = state->length;
                
O>        if (copy > have)
O>            {
O>            copy = have;
O>            }
                    
O>        if (copy)
O>            {
O>            if (state->head != Z_NULL && state->head->extra != Z_NULL)
O>               {
O>               len = state->head->extra_len - state->length;
O>               zmemcpy(state->head->extra + len, next,
O>                   len + copy > state->head->extra_max ?
O>                   state->head->extra_max - len : copy);
O>               }
                        
O>            if (state->flags & 0x0200)
O>               {
O>               state->check = crc32(state->check, next, copy);
O>               }
                        
O>            have -= copy;
O>            next += copy;
O>            state->length -= copy;
O>            }
                    
O>        if (state->length) goto inf_leave;
O>        }
                
O>    state->length = 0;
O>    state->mode = NAME;
O>

O>Ну неужели я не прав, и первый вариант читается лучше ?

Да, в этом случае первый вариант читается лучший, потому что второй добавляет тонны визального шума (скобки на уровне кода). Имхо, конечно.

Имхо, при правильно идентированном коде первый вариант ничем не плох

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

if(condition)
{
}

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

З.Ы.

Я лично программирую то в стиле

if(){
}

то в стиле

if()
{
}

зависит от фреймворков и IDE

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

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

T>>Но во-первых, такое может быть запрещено code style. И у Sun это запрещено.
CC>Ну это их тараканы и соотвественно их трудности.
Ты не понял. Не в внутри Sun, которой уже нет, а в рекомендации Sun всем Java-разработчикам.

T>>А во-вторых, отсутствие скобок делает код неоднородным. Где-то есть, где-то нет.
CC>И?
Такой код сложнее читать. Ведь каждый фрагмент получается отформатированным по-разному.

T>>А если нужно добавить выражения в код, где нет скобок?
CC>Добавляешь скобки. Делов то.
Долго. Проще сразу поставить.

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

O>Все равно непонятно. Как это не выполняют ? Так, что ли, лучше:

O>

O>if (условие 1)    {
O>    какой-то код
O>        } else if (условие 2) { еще код
O>               } else
O>    { ну и еще немножко кода
O>}
O>

Нет, конечно.

if (условие 1)    {
    какой-то код
} else if (условие 2) { 
    еще код
} else { 
    ну и еще немножко кода
}

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

Сишники...

В джаве этим занимается IDE. Настраивается чрезвычайно гибко.

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

O>

O>case EXTRA:
O>    if (state->flags & 0x0400) {
O>        copy = state->length;
O>        if (copy > have) copy = have;
O>        if (copy) {
O>            if (state->head != Z_NULL &&
O>                state->head->extra != Z_NULL) {
O>                len = state->head->extra_len - state->length;
O>                zmemcpy(state->head->extra + len, next,
O>                        len + copy > state->head->extra_max ?
O>                        state->head->extra_max - len : copy);
O>            }
O>            if (state->flags & 0x0200)
O>                state->check = crc32(state->check, next, copy);
O>            have -= copy;
O>            next += copy;
O>            state->length -= copy;
O>        }
O>        if (state->length) goto inf_leave;
O>    }
O>    state->length = 0;
O>    state->mode = NAME;
O>

Полностью и безоговорочно согласен. Физически не перевариваю такие скобки в конце строки, меня от них коробит и я ненавижу тех кто так пишет.
ЗЫ: Предлагаю внести законопроект, запрещающий такой стиль на федеральном уровне.

Здравствуйте, Eugeny__.

...

E__>

E__>if (условие 1)    {
E__>    какой-то код
E__>} else if (условие 2) { 
E__>    еще код
E__>} else { 
E__>    ну и еще немножко кода
E__>}
E__>

...

Глядя на такое оформление, готов взять некоторые свои слова назад !

Здравствуйте, Игoрь, Вы писали:

D>>еще K&R использовали такой стиль
И>когда они его использовали, размеры мониторов и разрешение были совсем другими, а стиль говенный, независимо от того, кто его использовал. Нужен он только там, где есть необходимость экономить пространство, на сегодняшний день это только книги.

Вам не приходилось работать с кодом, который на 24'' по ширине не лезет? Мне приходилось

Сдерживать себя надо, сдерживать. В т.ч. в ширину. Книги неспроста печатают ограниченной ширины: слишком широко сформатированный текст хуже усваивается.

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

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

T>>Лично я не люблю стиль вида
T>>Мне он кажется слишком разреженным. Получается принудительная пустая строка, а иногда это мешает.

S>А это зависит от стиля в целом. Я стараюсь разносить код по мелким методам — сильно помогает понять намерения писавшего код. В результате основной код выходит крайне лаконичным, но перенасыщенным

Так что отступы, наоборот, помогают.

S>Чтоб понятней было, что имею в виду:
S>

Скрытый текст

S>    private static PathToken ParseToken(PathTokenInfo parsingToken)
S>    {
S>      PathToken result;

S>      if (IsCurrentDirectoryToken(parsingToken))
S>      {
S>        result = CurrentDirectoryToken.Instance;
S>      }
S>      else if (IsParentDirectoryToken(parsingToken))
S>      {
S>        result = ParentDirectoryToken.Instance;
S>      }
S>      else
S>      {
S>        string tokenName = GetNormalizedTokenName(parsingToken);

S>        if (parsingToken.SeparatorCount == 0)
S>        {
S>          result = new FileToken(tokenName);
S>        }
S>        else
S>        {
S>          result = new DirectoryToken(tokenName);
S>        }
S>      }

S>      return result;
S>    }
S>

S>Я конечно могу сэкономить пару проверок, развернув код обратно в простыню на пару сотен строк, но как по мне — оно того не стоит.

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

P>Мне недавно пришлось разбирать как раз код в таком стиле, это ужасно, постоянные прыжки в функции и обратно чтоб понять что же там делается

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

А часто смотря чужой код видишь, что выделяется в отдельные сущности что-то невразумительное, ad hoc, чему даже название подобрать сложно.

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

А я обожаю:

if (condition) one_line_statement.
if (condition2) one_line_statement2. //still very easy to visually divide

if (condition3) {
   multi;
   line;
   statement;
}

// and!
function_call(with_a_single_or_short_parameter_list) {
  do_what_u_want;
}

function_call_2(
  param1_very_very_long_name_or_expression, 
  param2_one_more_super_super_super_super_super_long_expression, 
  param3
) {
  and_statement_here;
}

Короче рефлекс — если синенькое сверху — снизу либо фигурная скобочка, либо кругленкая и фигурная

. Глаза цепляются в момент и сразу видно, что внутри блока (максимум двух).

PS. Заговор имеет место быть!

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

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

H>Ты прав. Айда к нам. У нас вместо этих скобок пишут православные

Begin End

Есть за что глазу зацепиться

Эх были времена! Рассово верные весчи:

 type
   TMySet = Set of 1..3;
 var
   DemoSet :TMySet;
 begin 
   DemoSet := [1,2,3];
   //My comment
   {Сomment for с/c++/c#/java fans here: This is Turbo Pascal!!!}
   //...
     //Some code   
   //...    
 end;

Эх!

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

G>PS. Заговор имеет место быть!

PPS. И это отлично подходит для современных, инновационных немоноширинных шрифтов в кодинге. А моноширинные суть ретроградство и поклонение мерзким терминалам и режимам 80х25.

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

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

O>>

O>>            if (state->head != Z_NULL &&
O>>                state->head->extra != Z_NULL) {
O>>                len = state->head->extra_len - state->length;
O>>                zmemcpy(state->head->extra + len, next,
O>>                        len + copy > state->head->extra_max ?
O>>                        state->head->extra_max - len : copy);
O>>            }
O>>

Вот за такой мусор вообще надо четвертовать. Отступы относятся то ли к блоку внутри условия то ли к самому условию, все сливается в мутную кашу.
Лишняя строка для { существенно повышает читабельность.

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

TSP>Эх были времена! Рассово верные весчи:

TSP>

TSP> var
TSP>   DemoSet :TMySet;
TSP> begin 
TSP>   //...    
TSP>   //...    
TSP>   //...    
TSP>   //...    
TSP>   //...    
TSP>   //...    
TSP>   //...    
TSP>   //...    
...repear prev. line 30 times, pls. 
TSP>   //...    
TSP>   //...    
DemoSet.bebebe(xxx).
TSP>   //...    
TSP>   //...    
TSP> end;
TSP>

За локальную переменную, за которой нужно бегать в начало функции — убивать!!

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

H>Вот за такой мусор вообще надо четвертовать.

Тащемта, если бы программисты могли воплотить свои фантазии на программистах, код которых они поддерживают — мир стал бы чище... (должен остаться только один).

G>За локальную переменную, за которой нужно бегать в начало функции
IDE позволяет посмотреть на объявление по месту при наведении курсора.
А вообще за методы, которые оперируют кучей локальных переменных безотносительно к языку программирования — убивать!!!

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

G>>За локальную переменную, за которой нужно бегать в начало функции
TSP>IDE позволяет посмотреть на объявление по месту при наведении курсора.
То лишний двиг мышкой

.

TSP>А вообще за методы, которые оперируют кучей локальных переменных безотносительно к языку программирования — убивать!!!
Штуки 2-3 в методе допустимо, ИМХО. Но видеть я их хочу, подняв глаза на 5-6 строк максимум.

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

G> За локальную переменную, за которой нужно бегать в начало функции — убивать!!

Это за простыни нужно убивать, а декларирование в определенном месте оно воспитывает и стимулирует, дабы метаний избежать

avalon 1.0rc3 rev 368, zlib 1.2.3

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

TSP> Эх были времена! Рассово верные весчи:

TSP>

TSP>  type
TSP>    TMySet = Set of 1..3;
TSP>  var
TSP>    DemoSet :TMySet;
TSP>  begin
TSP>    DemoSet := [1,2,3];
TSP>    //My comment
TSP>    {Сomment for с/c++/c#/java fans here: This is Turbo Pascal!!!}
TSP>    //...
TSP>      //Some code
TSP>    //...
TSP>  end;
TSP>

TSP> Эх!

А мы все еще верны, рассово

avalon 1.0rc3 rev 368, zlib 1.2.3

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

P>Мне недавно пришлось разбирать как раз код в таком стиле, это ужасно, постоянные прыжки в функции и обратно чтоб понять что же там делается

Ужасно — это если не понятно, что делают методы из их названия. И, поверьте, в виде простыни этот код ещё непонятней

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

G>PPS. И это отлично подходит для современных, инновационных немоноширинных шрифтов в кодинге. А моноширинные суть ретроградство и поклонение мерзким терминалам и режимам 80х25.

Даёшь Comic Sans!

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

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

O>>Приведу реальный пример.
S>Прогнал через автоформатирование и StyleCop.

Автоформат не рулит ни в каком виде. Частенько встречаю код, в котором много похожих выражений выстроены столбцами.
В таком коде ровненькие стобцы выражений — единственный путь сразу увидеть ошибку.
Автоформат его ломает. За это не люблю Visual Studio.

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

Ф>Автоформат не рулит ни в каком виде. Частенько встречаю код, в котором много похожих выражений выстроены столбцами.
Ф>В таком коде ровненькие стобцы выражений — единственный путь сразу увидеть ошибку.

1. Не всегда спасёт.
2. Нефиг писать код так, что его невозможно прочесть добавив/убрав пробел.

Ф>Автоформат его ломает. За это не люблю Visual Studio.
Для C#: tools->options->text formatting->spacing->ignore spaces on binary operators.
Для остального — аналогично.

А пафоса-то

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

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

G>>PPS. И это отлично подходит для современных, инновационных немоноширинных шрифтов в кодинге. А моноширинные суть ретроградство и поклонение мерзким терминалам и режимам 80х25.

S>Даёшь Comic Sans!

Ой, а я страх как люблю Courier New !

Оффтопик: Хех, а тема-то живет !
Мог бы подкинуть еще пару "дровишек" типа надо ли ставить пробел между for и открывающей скобкой...

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

T>>>Но во-первых, такое может быть запрещено code style. И у Sun это запрещено.
CC>>Ну это их тараканы и соотвественно их трудности.
T>Ты не понял. Не в внутри Sun, которой уже нет, а в рекомендации Sun всем Java-разработчикам.
Рекомендации по кодстайлу ВСЕМ разработчикам это мягко говоря что то забавное.
Это типа "вот мы так пишем, и нам удобно. Теперь и вы так пишите, пофигу удобно вам или нет".
От того что этот кодстайл не соблюдать ничего не сломается, поэтому нет повода не использовать более удобный.
Кто слепо слушается и жрёт кактус — ССЗБ.
Единообразие конечно хорошо, но в разумных рамках.

T>>>А во-вторых, отсутствие скобок делает код неоднородным. Где-то есть, где-то нет.
CC>>И?
T>Такой код сложнее читать. Ведь каждый фрагмент получается отформатированным по-разному.
По опыту скажу: ничуть.
А вот K&R как раз читается тяжко.

T>>>А если нужно добавить выражения в код, где нет скобок?
CC>>Добавляешь скобки. Делов то.
T>Долго. Проще сразу поставить.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

O>Ой, а я страх как люблю Courier New !
Аналогично, consolas недостаточно олдскулен

O>Оффтопик: Хех, а тема-то живет !
O>Мог бы подкинуть еще пару "дровишек" типа надо ли ставить пробел между for и открывающей скобкой...

Тут предпочитаю следовать политике по умолчанию: ставить.

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

...

S>Тут предпочитаю следовать политике по умолчанию: ставить.

Понеслась !..

Ну не, вот использование немоноширинных шрифтов для кода — это точно еретичество.

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

TSP>А вообще за методы, которые оперируют кучей локальных переменных безотносительно к языку программирования — убивать!!!

Переменные-то чем помешали?

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

TSP>> Эх были времена! Рассово верные весчи:

TSP>>

TSP>>  type
TSP>>    TMySet = Set of 1..3;
TSP>>  var
TSP>>    DemoSet :TMySet;
TSP>>  begin
TSP>>    DemoSet := [1,2,3];
TSP>>    //My comment
TSP>>    {Сomment for с/c++/c#/java fans here: This is Turbo Pascal!!!}
TSP>>    //...
TSP>>      //Some code
TSP>>    //...
TSP>>  end;
TSP>>

TSP>> Эх!

H>А мы все еще верны, рассово

А меня всегда блевать тянуло от дурацкого паскалевского синтаксиса и ограничений(типа объявлений переменных только в определенных местах). И на первом курсе, когда я, программивший ранее только на qbasic и немного на асме, и потом, когда я уже перешел на сишный синтаксис(который сразу понравился).
И еще, скажите мне, какой дятел придумал нумеровать массивы с 1? Я из-за этой особенности, блин, недавно целый день потерял, пытаясь реализовать очередной доморощенный алгоритм CRC(у меня были исходники на делфи, а надо на джаве). Масло в огонь подливало то, что алгоритм писался клиническими идиотами — в 90% случаев результат для последовательности из N и N+1 байт(неважно каких) не различался(чудесный CRC, правда?), а вот в оставшихся 10% — очень даже. И для этих 10% я пытался понять, что же не так. Вобщем, пока не поставил делфю, и не запустил в отладке(сколько же мне нервов стоило даже просто создать запускаемый пример — этот долбанный шиворот-навыворот синтаксис меня мучал каждую секунду) — так и не понял.

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

E> И еще, скажите мне, какой дятел придумал нумеровать массивы с 1?

Массивы там можно нумеровать с любого индекса, хоть с 0, хоть с -5 в зависимости от того, как по задаче удобнее (более того, индексами могут быть даже булевы и перечислимые (enumeration) типы)

avalon 1.0rc3 rev 368, zlib 1.2.3

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

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

T>>>>Но во-первых, такое может быть запрещено code style. И у Sun это запрещено.
CC>>>Ну это их тараканы и соотвественно их трудности.
T>>Ты не понял. Не в внутри Sun, которой уже нет, а в рекомендации Sun всем Java-разработчикам.
CC>Рекомендации по кодстайлу ВСЕМ разработчикам это мягко говоря что то забавное.

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

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

Pzz>Вам не приходилось работать с кодом, который на 24'' по ширине не лезет? Мне приходилось

Так, чтобы сплошняком. нет, не приходилось. И с ограничениями в 80 символов уже давно не сталкивался.

Pzz>Сдерживать себя надо, сдерживать. В т.ч. в ширину.
Это уже не ко мне...

Pzz>Книги неспроста печатают ограниченной ширины: слишком широко сформатированный текст хуже усваивается.
Слишком узко сформатированный текст тоже фигово читается. Просто должен преобладать здравый смысл без фанатизма. Если где-то удобнее записать длинной строкой, то не вижу проблем, почему бы не записать. Особенно если речь идет о языках типа С#, где в любом случае будет предварительно три отступа — от деклараций неймспейса, класса, и метода.

O>Постоянно вижу код, в котором фигурные скобки расставляются в таком стиле:
[skipped]
впервые вижу

O>Ну неужели я не прав, и первый вариант читается лучше ?
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?
в разных конторах могут использовать разные conventions'ы, установленные еще прапрограммистами
если нет согласований по оформлению кода, используй любое расположение скобок. да хоть такое:

using System;

class Program
    static void Main(string[] args)
        int a = 0;
        do
            Console.WriteLine("{0} again? (y/Y/[Enter] - yes, otherwise - no)", a);
            a++;
        while ("yY".Contains(Console.ReadLine()));

скобки прячутся вне видимой области редактора

Ибо нефиг потому что!
Используйте готовые реализации алгоритмов, если они есть. Реализаций CRC выше крыше под все языки и платформы.

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

TSP>Ибо нефиг потому что!
TSP>Используйте готовые реализации алгоритмов, если они есть. Реализаций CRC выше крыше под все языки и платформы.

Как???

Смотри. Вот есть железяка. Нужно подружить наше ПО с ней. По протоколу, пакеты для общения с ней снабжены CRC. Самописной, и весьма корявой(и, кстати, неправильно описанной в доках, потому я в сорцы и полез) — но есть я этого алгоритма не реализую, то железяка мои пакеты будет отклонять.

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

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

M>

M>using System;

M>class Program
M>    static void Main(string[] args)
M>        int a = 0;
M>        do
M>            Console.WriteLine("{0} again? (y/Y/[Enter] - yes, otherwise - no)", a);
M>            a++;
M>        while ("yY".Contains(Console.ReadLine()));
M>

M>скобки прячутся вне видимой области редактора

Давайте еще и часть кода туда(за область видимости) засунем, а?

ИМХО это уже чистый саботаж и того, кто так форматирует надо тихо, не торопясь и со вкусом закапывать на заднем дворе.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

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

M>>

M>>using System;

M>>class Program
M>>    static void Main(string[] args)
M>>        int a = 0;
M>>        do
M>>            Console.WriteLine("{0} again? (y/Y/[Enter] - yes, otherwise - no)", a);
M>>            a++;
M>>        while ("yY".Contains(Console.ReadLine()));
M>>

M>>скобки прячутся вне видимой области редактора

YKU>Давайте еще и часть кода туда(за область видимости) засунем, а?

YKU>ИМХО это уже чистый саботаж и того, кто так форматирует надо тихо, не торопясь и со вкусом закапывать на заднем дворе.

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

ЗЫ кто-нибудь знает плагинчик под Эклипс, чтобы точно так же скрывать скобки? А то самому писать влом, а идея прекрасная.

E__>ЗЫ кто-нибудь знает плагинчик под Эклипс, чтобы точно так же скрывать скобки? А то самому писать влом, а идея прекрасная.
хинт: скобки можно так же рисовать цветом фона

E__>>ЗЫ кто-нибудь знает плагинчик под Эклипс, чтобы точно так же скрывать скобки? А то самому писать влом, а идея прекрасная.
M>хинт: скобки можно так же рисовать цветом фона

Какие грабли при этом можно огрести — просто сказка


if(some_condition)
    action1(); // закрывающая скобка тут?
    action2(); // или все же тут? ;)

В языках с significant whitespace (тот же питон) такой проблемы, естественно, не возникнет. А вот делать такое для других языков — это раскладывать вокруг грабли.

YKU>Давайте еще и часть кода туда(за область видимости) засунем, а?

YKU>ИМХО это уже чистый саботаж и того, кто так форматирует надо тихо, не торопясь и со вкусом закапывать на заднем дворе.

без паники! предложение внесено в порядке бреда и для поддержания срача.
но согласись, красиво получилось.

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

E__>>>ЗЫ кто-нибудь знает плагинчик под Эклипс, чтобы точно так же скрывать скобки? А то самому писать влом, а идея прекрасная.
M>>хинт: скобки можно так же рисовать цветом фона

M>Какие грабли при этом можно огрести — просто сказка


M>if(some_condition)
M>    action1(); // закрывающая скобка тут?
M>    action2(); // или все же тут? ;)

M>

Второй вариант. Форматтер не даст первому существовать долго(максимум до коммита, хотя я чаще запускаю — руками форматировать лень). А без автоформаттера да, грабли можно получить сказочные.

M>В языках с significant whitespace (тот же питон) такой проблемы, естественно, не возникнет. А вот делать такое для других языков — это раскладывать вокруг грабли.

В Питоне очень грамотно сделали, убрав эти скобки, или тем более кошмарные begin-end.

Здравствуйте, Игoрь, Вы писали:

Pzz>>Книги неспроста печатают ограниченной ширины: слишком широко сформатированный текст хуже усваивается.
И>Слишком узко сформатированный текст тоже фигово читается. Просто должен преобладать здравый смысл без фанатизма. Если где-то удобнее записать длинной строкой, то не вижу проблем, почему бы не записать. Особенно если речь идет о языках типа С#, где в любом случае будет предварительно три отступа — от деклараций неймспейса, класса, и метода.

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

P.S. Кстати, экраны-то широкие появились, но слишком широкий код на принтере нормально не напечатаешь, а это иногда бывает полезно, чтобы с ним карандашом поработать

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

Pzz>80 — это хорошая ширина. Не слишком большая, не слишком маленькая. Обычно если код не умещается в эту ширину, это свидетельствует о чрезмерном уровне вложенности. Разбиение такого кода на несколько функций помогает и ширину уменьшить, и логику кода сделать более внятной.

Pzz>P.S. Кстати, экраны-то широкие появились, но слишком широкий код на принтере нормально не напечатаешь, а это иногда бывает полезно, чтобы с ним карандашом поработать

От блин, теоретики-рассуждатели.

namespace BlahBlahaBlah
{
    class BlahBlah
    {
        public void DoBlah(FlowDocument original)
        {
            var sourceRange = new TextRange(original.ContentStart, original.ContentEnd); // <-- 88 символов
        }
    }
}

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

Pzz>80 — это хорошая ширина. Не слишком большая, не слишком маленькая. Обычно если код не умещается в эту ширину, это свидетельствует о чрезмерном уровне вложенности. Разбиение такого кода на несколько функций помогает и ширину уменьшить, и логику кода сделать более внятной.

+ 1

80 — отличная ширина для того, чтобы открыть на одном экране одновременно 2 окна редактора кода.

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

O>case EXTRA:
O>    if (state->flags & 0x0400)
O>        {
O>        copy = state->length;
                
O>        if (copy > have)
O>            {
O>            copy = have;
O>            }
                    
O>        if (copy)
...
O>

O>Ну неужели я не прав, и первый вариант читается лучше ?
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

на abap/4 и haskell таких проблем нет

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

O>Ну неужели я не прав, и первый вариант читается лучше ?
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

Блин — я даже знаю где примерно такой код используется — а в новой версии и <u>навязывается</u>
для скриптов своим пользователем. ОЧЕНЬ ХОЧЕТСЯ ЗА ЭТО ЗАДУШИТЬ!!!

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

Pzz>80 — это хорошая ширина. Не слишком большая, не слишком маленькая.
Это крохотная ширина. Слишком мало.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Игoрь, Вы писали:

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

Я часто читаю код с распечаток, например...

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

T>>А если нужно добавить выражения в код, где нет скобок?
CC>Добавляешь скобки. Делов то.

Выше вероятность конфликта в системе контроля версий...

CC>Это крохотная ширина. Слишком мало.

В chromium принято такое ограничение (80). Никто особо не жалуется, хотя кода много, иногда запутанного, часто длинные многоквалифицированные имена встречаются.

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

T>>>А если нужно добавить выражения в код, где нет скобок?
CC>>Добавляешь скобки. Делов то.

E>Выше вероятность конфликта в системе контроля версий...

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>>Это крохотная ширина. Слишком мало.
D>В chromium принято такое ограничение (80). Никто особо не жалуется, хотя кода много, иногда запутанного, часто длинные многоквалифицированные имена встречаются.
Ну и чем это хорошо?
То, что никто не жалуется — не показатель. Мыши порой молча продолжают жрать кактус.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Здравствуйте, Игoрь, Вы писали:

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

E>Я часто читаю код с распечаток, например...

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

Нафига оно надо? Если уж так охота читать с листочков, то может размер шрифта мельче делать? Ради распечаток корячиться с длиной строк в 80 символов? Увольте...

Здравствуйте, Игoрь, Вы писали:

И>Не читал код с распечаток лет пять как минимум. Оно же капец как неудобно — ни быстрой навигации и поиска, ни подсветки

Нафига оно надо? Если уж так охота читать с листочков, то может размер шрифта мельче делать? Ради распечаток корячиться с длиной строк в 80 символов?

Один из поводов читать код с распечаток -- очень ограниченный доступ к коду. Распечатку дают под роспись, скопировать её ты не можешь, сидишь, читаешь с карандашиком. Потом пишешь заключение. Тоже на бумажке. Бумажки тоже под роспись

И>Увольте...

Ну и уволил бы...

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

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

CC>Дык это ж не катастрофа а штатная ситуация.
CC>Тем более что я с трудом представляю как там может нарисоваться конфликт: какие бы изменения не делал второй участник, но он тоже добавит скобки. Конфликт может быть в содержимом, а это уже без разницы были там скобки до того или нет.

Было

if( cond )
    doCommon();

Стало 1

if( cond )
{
    doCommon();
    doAfter();
}

Стало 2

if( cond )
{
    doPre();
    doCommon();
}

автоматом это не сольётся, а жаль...

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

E>Один из поводов читать код с распечаток -- очень ограниченный доступ к коду. Распечатку дают под роспись, скопировать её ты не можешь, сидишь, читаешь с карандашиком. Потом пишешь заключение. Тоже на бумажке. Бумажки тоже под роспись

А код ты компилируешь тоже на бумажках? Мне кажется это какой-то крайне экстремальный случай. И есть у меня большие сомнения в реальной эффективности таких мер безопасности.

И>>Увольте...
E>Ну и уволил бы...

E>IMHO, программист, с которым надо обсуждать такую фигню, как постановка скобок и длина строк. И который не может работать, если она не какая-то такая, как ему нравится, такой программист, IMHO, должен платить сам, за то, что его к коду допускают

Заметь, ограничение на длину строк отстаиваешь ты, не я. Тебе видете ли с распечаток что-то там чиать неудобно. Так что примени все выше написанное сам к себе.

Здравствуйте, Игoрь, Вы писали:

И>А код ты компилируешь тоже на бумажках? Мне кажется это какой-то крайне экстремальный случай. И есть у меня большие сомнения в реальной эффективности таких мер безопасности.
Код компилируют непосредственно в изделие. Прогон осуществляют на полигоне. UB вполне может выглядеть как взрыв нескольких тонн взрывчатки

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

И>>>Увольте...
E>>Ну и уволил бы...

E>>IMHO, программист, с которым надо обсуждать такую фигню, как постановка скобок и длина строк. И который не может работать, если она не какая-то такая, как ему нравится, такой программист, IMHO, должен платить сам, за то, что его к коду допускают

И>Заметь, ограничение на длину строк отстаиваешь ты, не я. Тебе видете ли с распечаток что-то там чиать неудобно. Так что примени все выше написанное сам к себе.

Мне пофигу. Военным нет. Я могу с ними сотрудничать, а ты сам про себя думай

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

E>Код компилируют непосредственно в изделие. Прогон осуществляют на полигоне. UB вполне может выглядеть как взрыв нескольких тонн взрывчатки

E>Так что многократная вычитка спецами приветствуется, а возможность утечки кода очень не приветствуется при этом...

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

E>Мне пофигу. Военным нет. Я могу с ними сотрудничать, а ты сам про себя думай

А уж мне то как пофигу

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

E>автоматом это не сольётся, а жаль...

Разве?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>IMHO, программист, с которым надо обсуждать такую фигню, как постановка скобок и длина строк. И который не может работать, если она не какая-то такая, как ему нравится, такой программист, IMHO, должен платить сам, за то, что его к коду допускают

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>автоматом это не сольётся, а жаль...

CC>Разве?

Добавление скобок в обеих версиях вызывает конфликт. Если SVN доступен -- просто проверь...

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

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

Возможно, но из-за их личных качеств, а не из-за ограничения на длину строк. Мало ли где и какие производственные процессы происходят. Я не встречал пока кодестайла к которому нельзя бы было адаптироваться. И если кто-то не может, то ЛИЧНО ДЛЯ МЕНЯ, это говорит о низком уровне этого кого-то...

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

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

E>Возможно, но из-за их личных качеств, а не из-за ограничения на длину строк.
Неадекватность выдвигаемых требований зачастую означает общую неадекватность.

E> Мало ли где и какие производственные процессы происходят. Я не встречал пока кодестайла к которому нельзя бы было адаптироваться. И если кто-то не может, то ЛИЧНО ДЛЯ МЕНЯ, это говорит о низком уровне этого кого-то...

Знаешь, можно требования выдвинуть и в стиле "у всех мышки должны лежать от клавиатуры слева". И всех, кто к такому распорядку адаптироваться не может/не хочет обвинять в "низком уровне".
Если требование не обусловлено реальной необходимостью его следует нафиг отменить, а не парить всем мозг.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>Возможно, но из-за их личных качеств, а не из-за ограничения на длину строк.
CC>Неадекватность выдвигаемых требований зачастую означает общую неадекватность.
Осталось выяснить чью. Тебя или команды. Если команда успешная, то вопросе более, чем неоднозначный

CC>Знаешь, можно требования выдвинуть и в стиле "у всех мышки должны лежать от клавиатуры слева". И всех, кто к такому распорядку адаптироваться не может/не хочет обвинять в "низком уровне".
Ну я одно время тусил в месте с таким ровно требованием. И ещё очень жёсткие ограничения были на настройки окружения. А всё для того, чтобы топовый программер мог подойти к любому месту и спокойно помочь.

CC>Если требование не обусловлено реальной необходимостью его следует нафиг отменить, а не парить всем мозг.
Ну, как бы, в конторах, особенно больших, есть специально заточенные под это люди. Они и решают какая необходимость реальная, а какая нет. Тебе-то что? Какая разница есть у них какая-то причина или нет?

Многие вопросы, кстати, всё равно как решать. Главное принять КАКОЙ-ТО стандарт. Например, таким вопросом является ширина отступа...

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

E>>>Возможно, но из-за их личных качеств, а не из-за ограничения на длину строк.
CC>>Неадекватность выдвигаемых требований зачастую означает общую неадекватность.
E>Осталось выяснить чью. Тебя или команды. Если команда успешная, то вопросе более, чем неоднозначный

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

CC>>Знаешь, можно требования выдвинуть и в стиле "у всех мышки должны лежать от клавиатуры слева". И всех, кто к такому распорядку адаптироваться не может/не хочет обвинять в "низком уровне".
E>Ну я одно время тусил в месте с таким ровно требованием. И ещё очень жёсткие ограничения были на настройки окружения. А всё для того, чтобы топовый программер мог подойти к любому месту и спокойно помочь.
А в задницу его не надо было целовать по вторникам?
Ломать всем удобное рабочее окружение только для того, чтоб один единственный ~~хрен с бугра~~ чел мог когда нибудь подойти? И не факт что он подойдёт когда нибудь.
Да лучше пусть он вообще никогда не подходит, но работать мне будет удобно и комфортно.
Из таких мест ИМХО надо срочно валить. Там ЧСВ у лида зашкаливает.

CC>>Если требование не обусловлено реальной необходимостью его следует нафиг отменить, а не парить всем мозг.
E>Ну, как бы, в конторах, особенно больших, есть специально заточенные под это люди. Они и решают какая необходимость реальная, а какая нет. Тебе-то что? Какая разница есть у них какая-то причина или нет?

Введение идиотских требований — первый признак того, что в голове того, кто ведёт проект идёт воспалительный процесс. Наблюдалось подобное уже в клинической картине. Когда так увлеклись "шашечками" что к моменту когда собрались "ехать" ушло полкоманды.
Значит есть высокая вероятность что скоро начнётся маразм в полную силу. Лучше свалить пораньше, больше нервов останутся целыми, больше денег заработаются в том месте, где работать не мешают.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>И какой будет неоднозначный выбор? Пойдёшь туда, где есть требования, обусловленные производственной необходимостью или где требования обусловлены голосами из розетки, которые слышит лид?
Если честно, то туда, где интереснее соотношение уровня решаемых задач и оплаты. При этом то, как именно надо расставлять скобки или какие должны быть мышки -- это, IMHO, мелочи. То есть если абстрагироваться от уровня зряплаты, и рассмотреть два предложения. В одном быдлофомочки клепаем, но супер удобно всё, а в другом мышки не такие, ПО регламентировано, инструкция программиста драконовская, но решают интересные задачи. Ну, например, разрабатывают ПО к С-400, или переводчик или ещё что такое на переднем крае... Вот ты куда пойдёшь? На удобные мышки и быдлоформочки

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

CC>А в задницу его не надо было целовать по вторникам?
Нет не надо.

CC>Ломать всем удобное рабочее окружение только для того, чтоб один единственный ~~хрен с бугра~~ чел мог когда нибудь подойти? И не факт что он подойдёт когда нибудь.
Он не единственный. Топы договорились как ИМ удобно. И навязали остальным такую же среду. И что тут такого запредельно плохого? Я не вижу никакой проблемы.

CC>Из таких мест ИМХО надо срочно валить. Там ЧСВ у лида зашкаливает.
Ерунда. Надо не на СЧВ смотреть, а на реальные достижения.

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

S>Чтоб понятней было, что имею в виду:
S>

Скрытый текст

S>    private static PathToken ParseToken(PathTokenInfo parsingToken)
S>    {
S>      PathToken result;

S>      if (IsCurrentDirectoryToken(parsingToken))
S>      {
S>        result = CurrentDirectoryToken.Instance;
S>      }
S>      else if (IsParentDirectoryToken(parsingToken))
S>      {
S>        result = ParentDirectoryToken.Instance;
S>      }
S>      else
S>      {
S>        string tokenName = GetNormalizedTokenName(parsingToken);

S>        if (parsingToken.SeparatorCount == 0)
S>        {
S>          result = new FileToken(tokenName);
S>        }
S>        else
S>        {
S>          result = new DirectoryToken(tokenName);
S>        }
S>      }

S>      return result;
S>    }
S>

S>Я конечно могу сэкономить пару проверок, развернув код обратно в простыню на пару сотен строк, но как по мне — оно того не стоит.

Скобки-шмобки. Фигня это все. Во как надо писать:

private static PathToken ParseToken(PathTokenInfo parsingToken)
{
  return IsCurrentDirectoryToken(parsingToken) ? CurrentDirectoryToken.Instance :
    IsParentDirectoryToken(parsingToken) ? ParentDirectoryToken.Instance :
    parsingToken.SeparatorCount == 0 ? new FileToken(GetNormalizedTokenName(parsingToken)) :
    new DirectoryToken(GetNormalizedTokenName(parsingToken));
}

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

CC>>И какой будет неоднозначный выбор? Пойдёшь туда, где есть требования, обусловленные производственной необходимостью или где требования обусловлены голосами из розетки, которые слышит лид?
E>Если честно, то туда, где интереснее соотношение уровня решаемых задач и оплаты. При этом то, как именно надо расставлять скобки или какие должны быть мышки -- это, IMHO, мелочи.
Т.е. если платят несколько выше рынка, задачи интересные но писать надо в неотапливаемом помещении в которую протекает канализация из офиса сверху, за старым 14" ЭЛТ, с шариковой мышой от EC и начальством-самодуром — это нормально?
Этож как надо себя не уважать то?

E>То есть если абстрагироваться от уровня зряплаты, и рассмотреть два предложения. В одном быдлофомочки клепаем, но супер удобно всё, а в другом мышки не такие, ПО регламентировано, инструкция программиста драконовская, но решают интересные задачи. Ну, например, разрабатывают ПО к С-400, или переводчик или ещё что такое на переднем крае...
Жизнь она вообще то не двуцветная.
И как правило где проекты говно там и обстановка говно.

E>Вот ты куда пойдёшь? На удобные мышки и быдлоформочки

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

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

А если меня всё хорошо получается? Что тогда?

CC>>Ломать всем удобное рабочее окружение только для того, чтоб один единственный ~~хрен с бугра~~ чел мог когда нибудь подойти? И не факт что он подойдёт когда нибудь.
E>Он не единственный. Топы договорились как ИМ удобно. И навязали остальным такую же среду. И что тут такого запредельно плохого? Я не вижу никакой проблемы.

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

CC>>Из таких мест ИМХО надо срочно валить. Там ЧСВ у лида зашкаливает.
E>Ерунда. Надо не на СЧВ смотреть, а на реальные достижения.

Да плевать какие у него достижения, если он с коллегами не уживается.
Таких персонажей держать — только увеличивать текучесть кадров и напряжение в команде.
Был у меня на старой конторе похожий случай. Тогда персонажа, очень хорошего спеца но с воооооооот таким вот ЧСВ решили продвинуть на ПМ. Программерский стафф почти полным составом тогда резко стал искать куда свалить. Потому как и на позиции лида одного из отделов он всех достал по самое немогу.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>Если честно, то туда, где интереснее соотношение уровня решаемых задач и оплаты. При этом то, как именно надо расставлять скобки или какие должны быть мышки -- это, IMHO, мелочи.
CC>Т.е. если платят несколько выше рынка, задачи интересные но писать надо в неотапливаемом помещении в которую протекает канализация из офиса сверху, за старым 14" ЭЛТ, с шариковой мышой от EC и начальством-самодуром — это нормально?
Нет не нормально, но это лучше, чем неинтересные задачи за бесплатно, в хорошем офисе и с новыми мышками.
Кроме того, не надо передёргивать. Про канализацию и прочие ужасы ты придумал. Это намного выходит за рамки регламента, где должна быть мышка, например...
CC>Этож как надо себя не уважать то?
А по мне, так неуважение к себе проявляется, в первую очередь, в неинтересной работе...

CC>Жизнь она вообще то не двуцветная.
CC>И как правило где проекты говно там и обстановка говно.
Не знаю. Ты вот говоришь, что такого выбора быть не может, вместо того, чтобы сказать куда бы ты пошёл...
Примеры контор, где задачи интересные, а условия *своеобразные* у меня перед глазами. И там работают неплохие спецы. Правда их ерунда вроде стиля расстановок скобок вообще не парит. Их парят их РЕАЛЬНЫЕ задачи...

CC>А если меня всё хорошо получается? Что тогда?
Ну ты вот пришёл в успешную команду. Они, например, технологические лидеры в своей нише. Но у них безумный, с твоей точки зрения, технологический процесс. И что ты будешь делать?

CC>Если ты топ — да, у тебя никакой проблемы.
Я топ, но не там

У себя я иногда запрещаю подсинённым делать такие настройки среды, что мне СОВСЕМ НИКАК не получается ею пользоваться. Но это бывает надо редко. И, что самое удивительное, все люди, с кем были такие проблемы, в конце концов ушли именно потому, что не справлялись с уровнем требований. Видимо неспособность отделять главное от второстепенного жёстко коррелирует с профнепригодностью для разработки

CC>Если ты не топ и навязанная ими конфигурация тебе не удобна — у тебя есть проблема. Которая в общем то на пустом месте, но на работоспособности сказывается.
Я считаю, что если кто-то не может работать в нормальной удобной среде. Или не может ставит скобочки в соответствии с принятым в команде кодестайлом, то он хреновый программист, и уж тем более разработчик. Просто нормальных людей совсем другой уровень проблем волнует. Скажем не то, что в коде скобочки не так выравнены, а то, что архитектура неудачно выбрана...

CC>Можно утереться и сидеть, стараясь работать на том, что есть. А можно послать самодуров нахрен и найти компанию, где к людям относятся по людски. И которым нужен сам продукт а не процесс "вымучивания" продукта.
Можно. Это зависит от уровня команды. Если команда лучшая в мире по своему направлению, а направление тебе нравится,то выбирать не особо есть из чего

CC>Да плевать какие у него достижения, если он с коллегами не уживается.
CC>Таких персонажей держать — только увеличивать текучесть кадров и напряжение в команде.
Я вижу реально успешные команды. То, что ты оттуда ушёл бы, не обозначает текучести кадров

CC>Программерский стафф почти полным составом тогда резко стал искать куда свалить. Потому как и на позиции лида одного из отделов он всех достал по самое немогу.

Опять же, был, как я понял, межличностный конфликт? А мы вроде как говорим о ФОРМАЛЬНЫХ вещах, вроде правил расстановки скобочек по строкам и отступам

Почему ты простые формальные требования воспринимаешь, как личное оскорбление?

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

Довод против остонадоевшего египетского стиля

#if DEFINITION
    if(condition)
#endif
    {
        ...
    }

А вот так сфейлится

#if DEFINITION
    if(condition){
#endif
        ...
    }

нужно задирективить закрывающую скобку.

Необходимость условной компиляции, это тема для отдельного флейма

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

E>>>Если честно, то туда, где интереснее соотношение уровня решаемых задач и оплаты. При этом то, как именно надо расставлять скобки или какие должны быть мышки -- это, IMHO, мелочи.
CC>>Т.е. если платят несколько выше рынка, задачи интересные но писать надо в неотапливаемом помещении в которую протекает канализация из офиса сверху, за старым 14" ЭЛТ, с шариковой мышой от EC и начальством-самодуром — это нормально?
E>Нет не нормально, но это лучше, чем неинтересные задачи за бесплатно, в хорошем офисе и с новыми мышками.
E>Кроме того, не надо передёргивать. Про канализацию и прочие ужасы ты придумал. Это намного выходит за рамки регламента, где должна быть мышка, например...
Где должна быть мышка это точно такое же самодурство как и "и в неотапливаемом сарае тоже можно работать".

CC>>Этож как надо себя не уважать то?
E>А по мне, так неуважение к себе проявляется, в первую очередь, в неинтересной работе...

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

CC>>Жизнь она вообще то не двуцветная.
CC>>И как правило где проекты говно там и обстановка говно.
E>Не знаю. Ты вот говоришь, что такого выбора быть не может, вместо того, чтобы сказать куда бы ты пошёл...
Я говорю про то, что выбор как правило не ограничен описанными тобой случаями.
У меня попадаются как интересные так и не интересные таски. И делать их надо все, иначе не будет работать проект в целом.
И делать не интересный таск в условиях, когда ты можешь максимально удобно устроить свою работу будет легче, чем делать интересный таск но при этом когда тебе всячески мешают.

E>Примеры контор, где задачи интересные, а условия *своеобразные* у меня перед глазами. И там работают неплохие спецы.
А какая у них компенсация за эти "своеобразные" условия?

E>Правда их ерунда вроде стиля расстановок скобок вообще не парит. Их парят их РЕАЛЬНЫЕ задачи...

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

CC>>А если меня всё хорошо получается? Что тогда?
E>Ну ты вот пришёл в успешную команду. Они, например, технологические лидеры в своей нише. Но у них безумный, с твоей точки зрения, технологический процесс. И что ты будешь делать?

Начнём с того, что я постараюсь узнать побольше ДО того как к ним приду.
И если меня не устроит их процесс то это будет им существенный минус. Я хочу решать задачу а не преодолевать бурелом "процесса". Уже напреодолевался, больше не желаю.
В конце концов жизнь одна, живём один раз, и горбатить в некомфортных условиях нет никакого интересу. Пусть они хоть трижды лидеры, у меня свои интересы.

E>делать такие настройки среды, что мне СОВСЕМ НИКАК не получается ею пользоваться.
Это как?
Мне просто интересно что ж там можно накрутить чтоб один пользоваться мог, а другой — совсем никак.

CC>>Если ты не топ и навязанная ими конфигурация тебе не удобна — у тебя есть проблема. Которая в общем то на пустом месте, но на работоспособности сказывается.
E>Я считаю, что если кто-то не может работать в нормальной удобной среде.
Что считаем "нормальной удобной средой"? Кто критерий нормальности?

E> Или не может ставит скобочки в соответствии с принятым в команде кодестайлом, то он хреновый программист, и уж тем более разработчик.
Про скобочки мы давно проехали. Это соглашение для единообразия, с ним всё понятно для чего оно и зачем. Как правило команда решает какой кодстайл будет использоваться, или принимается тот кодстайл, что уже есть на проекте если команда подключается к уже существующему проекту.
Если же команде более привычен кодстайл А а лид в меньшинстве и без объективных доводов бараном упёрся ("я нОчальнег, я так хочу!") в кодстайл Б то лид дурак и его надо бы отстранить от общения с людьми.
Сцепились мы с тобой по поводу того, что необоснованные требования, типа длины строк, суть ересь кодопротивная и подлежит казни бескровной. Ну а автора таких требований потребно колесовать, пострадавшим на потеху и дабы другим неповадно было.

E> Просто нормальных людей совсем другой уровень проблем волнует. Скажем не то, что в коде скобочки не так выравнены, а то, что архитектура неудачно выбрана...

Эти проблемы тоже парят, но вот скажи, тебе удобно ходить в обуви, в которую упал мелкий камешек? Мелочь, но за день так натрёт.
Зачем работать в некомфортной обстановке если можно работать в комфортной.
Так вот я за то, чтоб дурацких требований, которые создают неудобства но при этом не создают преимуществ быть не должно.

CC>>Можно утереться и сидеть, стараясь работать на том, что есть. А можно послать самодуров нахрен и найти компанию, где к людям относятся по людски. И которым нужен сам продукт а не процесс "вымучивания" продукта.
E>Можно. Это зависит от уровня команды. Если команда лучшая в мире по своему направлению, а направление тебе нравится,то выбирать не особо есть из чего

Всегда есть. Хоть открывай стартап и занимайся любимым делом.

CC>>Да плевать какие у него достижения, если он с коллегами не уживается.
CC>>Таких персонажей держать — только увеличивать текучесть кадров и напряжение в команде.
E>Я вижу реально успешные команды. То, что ты оттуда ушёл бы, не обозначает текучести кадров

Успехов им и дальше.
Но я живу и работаю на благо для себя. И пока у меня будет выбор, я буду выбирать те команды, в которых мне будет лучше всего по совокупности интересующих меня факторов. Как денег так и напрягов.

CC>>>>Из таких мест ИМХО надо срочно валить. Там ЧСВ у лида зашкаливает.
E>>>Ерунда. Надо не на СЧВ смотреть, а на реальные достижения.
CC>>Программерский стафф почти полным составом тогда резко стал искать куда свалить. Потому как и на позиции лида одного из отделов он всех достал по самое немогу.
E>Опять же, был, как я понял, межличностный конфликт? А мы вроде как говорим о ФОРМАЛЬНЫХ вещах, вроде правил расстановки скобочек по строкам и отступам

Мы говорим о ЧСВ, если ты, наш любитель вырывать фразы из контекста, не заметил

E>Почему ты простые формальные требования воспринимаешь, как личное оскорбление?

Я воспринимаю как издевательство те требования, которые создают дискомфорт и при этом не обусловлены объективными причинами. Если объективные причины реально есть, то никаких возражений у меня к таким требованиям нет.
В том числе утаптывать код в нечитабельное месиво ради строк в 80 симоволов на 1920х1200 мониторе, только потому, что лид так привык.
Мне благо таких идиотов давно не попадалось.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>делать такие настройки среды, что мне СОВСЕМ НИКАК не получается ею пользоваться.
CC>Это как?
CC>Мне просто интересно что ж там можно накрутить чтоб один пользоваться мог, а другой — совсем никак.
Ну, например, китайская раскладка клавиатуры по умолчанию + такая же локализация всего ПО.
Некий хитрый шрифт, который позволяет втиснуть на экран очень много букв. Он хорош всем, кроме того, что я не умею его читать без раздумий, а что это за буква-то.
Всякие оригинальные цветовые схемы. Скажем розовые буквы на чёрном фоне я, например, не могу долго читать. Глазки бо-бо начинают...

CC>Что считаем "нормальной удобной средой"? Кто критерий нормальности?
Ну там было MSVC, какое-то. Но это всё не важно. Если в некой конторе несколько опытных программистов считают какую-то среду нормальной и удобной, то это обозначает, что она уже ДОВОЛЬНО удобная и нормальная...

CC>Про скобочки мы давно проехали. Это соглашение для единообразия, с ним всё понятно для чего оно и зачем. Как правило команда решает какой кодстайл будет использоваться, или принимается тот кодстайл, что уже есть на проекте если команда подключается к уже существующему проекту.
CC>Если же команде более привычен кодстайл А а лид в меньшинстве и без объективных доводов бараном упёрся ("я нОчальнег, я так хочу!") в кодстайл Б то лид дурак и его надо бы отстранить от общения с людьми.
Либо ему нужна другая команда...

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

CC>Сцепились мы с тобой по поводу того, что необоснованные требования, типа длины строк, суть ересь кодопротивная и подлежит казни бескровной. Ну а автора таких требований потребно колесовать, пострадавшим на потеху и дабы другим неповадно было.
Я так не считаю. И вообще, IMHO, это не важно.

CC>Эти проблемы тоже парят, но вот скажи, тебе удобно ходить в обуви, в которую упал мелкий камешек? Мелочь, но за день так натрёт.
CC>Зачем работать в некомфортной обстановке если можно работать в комфортной.
CC>Так вот я за то, чтоб дурацких требований, которые создают неудобства но при этом не создают преимуществ быть не должно.
Это очень субъективная вещь. Кому-то то нравится, кому-то это. Вот прикинь, например начальник код выборочно вычитывает, но делает это с какого-то гаджета. И ему удобно, чтобы размер строки был не более чем. Это достаточное обоснование?

А если приплюсовать, что в случае жопы-жопы-срочно-срочно автор бага продолжит проводить ежегодный отпуск где-то у моря, а лид будет спешно искать багу?

CC>Всегда есть. Хоть открывай стартап и занимайся любимым делом.
Стартапом ты ракету на Марс на запустишь, и истребитель пятого поколения не залудишь и т. д...
Ты всё время говоришь о каких-то мелких утилитах, коротких идеях, стартапах и т. п.
Там конечно же можно выбрать любые правила, а не понравилось, так разбежаться и сойтись в другом порядке.
А я говорю о зрелых успешных конторах с большим числом успешных проектов и т. д.
Ну типа гугол, например. Вот прикинь, делает гугол что-то масштабное и интересное. Но кодестайл у них тот ещё. И что? Забить на интересные задачи, прикольных коллег, большую зарплату, перспективы, только потому, что тебе длину строки ограничили? IMHO, это неадекватно...

CC>Но я живу и работаю на благо для себя. И пока у меня будет выбор, я буду выбирать те команды, в которых мне будет лучше всего по совокупности интересующих меня факторов. Как денег так и напрягов.
Так все так и делают. Я простую вещь ведь говорю. Для зрелых разработчиков, которые уж наигрались и с инструментами и с ЧСВ и со всем остальным, важны задачи, а инструменты -- это второстепенно. Кодестайл -- это просто инструмент коллективной работы. Один из. Часто для каждого конкретного чела неидеальный. Но вполне приемлемый при этом.

CC>Мы говорим о ЧСВ, если ты, наш любитель вырывать фразы из контекста, не заметил
Связь ограничения длины строки и чувство чего-то собственного величия мне не ясна...
Если лидер занят исключительно ЧСВ, то в топку его, и если он мегадемократичен и сверхкорректен, то тоже в топку. Мне от лидера не надо удобного кодестайла. Мне надо, чтобы он вёл меня и моих подчинённых туда, куда я без него не дойду...

CC>Я воспринимаю как издевательство те требования, которые создают дискомфорт и при этом не обусловлены объективными причинами. Если объективные причины реально есть, то никаких возражений у меня к таким требованиям нет.
CC>В том числе утаптывать код в нечитабельное месиво ради строк в 80 симоволов на 1920х1200 мониторе, только потому, что лид так привык.
CC>Мне благо таких идиотов давно не попадалось.

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

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

amber on black это нормальная схема, даже терминалы такие выпускали.

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

D>amber on black это нормальная схема, даже терминалы такие выпускали.
Ну всё возможно, но мне трудно такое читать. И я не понимаю, что мешает разработчику заюзать другую. Скажем зелёные буковки на чёрном. Это я уже выношу...

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

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

CC>>Что считаем "нормальной удобной средой"? Кто критерий нормальности?
E>Ну там было MSVC, какое-то. Но это всё не важно. Если в некой конторе несколько опытных программистов считают какую-то среду нормальной и удобной, то это обозначает, что она уже ДОВОЛЬНО удобная и нормальная...

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

CC>>Про скобочки мы давно проехали. Это соглашение для единообразия, с ним всё понятно для чего оно и зачем. Как правило команда решает какой кодстайл будет использоваться, или принимается тот кодстайл, что уже есть на проекте если команда подключается к уже существующему проекту.
CC>>Если же команде более привычен кодстайл А а лид в меньшинстве и без объективных доводов бараном упёрся ("я нОчальнег, я так хочу!") в кодстайл Б то лид дурак и его надо бы отстранить от общения с людьми.
E>Либо ему нужна другая команда...

Которая его заскоки примет безропотно?

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

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

E>Это очень субъективная вещь. Кому-то то нравится, кому-то это. Вот прикинь, например начальник код выборочно вычитывает, но делает это с какого-то гаджета. И ему удобно, чтобы размер строки был не более чем. Это достаточное обоснование?

Если это на самом деле так, то да, достаточное. Я об этом тебе пытаюсь в разной форме уже несколько сообщений донести.

E>Ты всё время говоришь о каких-то мелких утилитах, коротких идеях
Где? Ссылкой можно?

E>Ну типа гугол, например. Вот прикинь, делает гугол что-то масштабное и интересное. Но кодестайл у них тот ещё. И что? Забить на интересные задачи, прикольных коллег, большую зарплату, перспективы, только потому, что тебе длину строки ограничили? IMHO, это неадекватно...

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

CC>>Но я живу и работаю на благо для себя. И пока у меня будет выбор, я буду выбирать те команды, в которых мне будет лучше всего по совокупности интересующих меня факторов. Как денег так и напрягов.
E>Так все так и делают. Я простую вещь ведь говорю. Для зрелых разработчиков, которые уж наигрались и с инструментами и с ЧСВ и со всем остальным, важны задачи, а инструменты -- это второстепенно. Кодестайл -- это просто инструмент коллективной работы. Один из. Часто для каждого конкретного чела неидеальный. Но вполне приемлемый при этом.

Я уже тоже наигрался, и хочу спокойно решать задачу, а не чесать ЧСВ некоего лида, которому кажется прикольным дописать ещё пару правил, только потому, что он у кого то их увидел. И похрен что тут эти правила не имеют под собой никакой реальной основы, просто ему кажется что взять тот же гуглов кодстайл будет круто, потому как гугл же его использует, вот и пусть мы тоже будем корячиться, пусть все думают что мы тоже как гугл крутые.
Вот за такое я и предлагаю гнать метлой.

CC>>Мы говорим о ЧСВ, если ты, наш любитель вырывать фразы из контекста, не заметил
E>Связь ограничения длины строки и чувство чего-то собственного величия мне не ясна...
Выше объяснил.

E>Я вот не пойму. Ну вот выяснишь ты, что причина таки есть. Что поменяется? Какая разница, это потому, что лиду так удобно, или это потому, что он в голову раненый и мелкий шрифт не видит?

Ради комфорта одного человека создавать дискомфорт всем остальным — это не объективная причина.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>Ты не поверишь какое кол-во опытных программистов считают удобным довольно таки разные вещи.
Почему не поверю? Но адекватные люди, тем не менее, могут договориться обычно. Во всяком случае в том месте они договорились...

CC>Которая его заскоки примет безропотно?
Почему заскоки? Он же стал из-за чего-то лидером?

E>>Это очень субъективная вещь. Кому-то то нравится, кому-то это. Вот прикинь, например начальник код выборочно вычитывает, но делает это с какого-то гаджета. И ему удобно, чтобы размер строки был не более чем. Это достаточное обоснование?

CC>Если это на самом деле так, то да, достаточное. Я об этом тебе пытаюсь в разной форме уже несколько сообщений донести.
А какая ТЕБЕ разница, делает он так, или думает, что когда-нибудь будет делать?

CC>Если ограничение объективно обосновано, т.е. оно не потому, что кому то так захотелось а есть реальные причины тому то претензий к ограничению нет.
А где критерий между "захотелось" и "есть причины"? И какая ТЕБЕ разница, насколько важные причины были у тех, кто принял то решение...

CC>Я уже тоже наигрался, и хочу спокойно решать задачу, а не чесать ЧСВ некоего лида, которому кажется прикольным дописать ещё пару правил, только потому, что он у кого то их увидел. И похрен что тут эти правила не имеют под собой никакой реальной основы, просто ему кажется что взять тот же гуглов кодстайл будет круто, потому как гугл же его использует, вот и пусть мы тоже будем корячиться, пусть все думают что мы тоже как гугл крутые.
CC>Вот за такое я и предлагаю гнать метлой.
А чем плохо взять гуглический кодестайл? Они же действительно его используют, и сам лид может там работал, например...
Ну и вообще я не понимаю, как ты проводишь границу обоснованности. И главное, ТЕБЕ-то какая разница что довело лида до жизни такой?

CC>Ради комфорта одного человека создавать дискомфорт всем остальным — это не объективная причина.
Я не понимаю, как ты определяешь "объективную" причину. Вот если лид с гаджета читает, но мог бы и с ноута, но ноут ему таскать неудобно. И?

Здравствуйте, Игoрь, Вы писали:

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

D>>Скажем, сегодняшний google code style использует этот стиль и накладывает 80-символьное ограничение.
И>Во-первых, при чем здесь 80-символьное ограничение, если оно по ширине, а не по высоте? Хотя и его считаю уже не актуальным. А во-вторых, сейчас полно ноутбуков с нормальными дисплеями и разрешением. У меня 15 дюймовый ноут, вполне нормально.

Потому что 80 символов — это ограничение на уровень говнокодовости написаного. Если у тебя много контекстов вложенно один в другой (if-if-switch-if-if-if) — ты легко выйдешь за такое ограничение. Если у тебя переменные названы в стиле stringThisIsMyNewVariableRenamedNowToOldOneSoNobodyKnowsWhatTheHeckIsHiddenOrMeantWithSuch1 то ты за ограничение выйдешь также. Если ты не делаешь таких глупостей — 80-90 символов в зависимости от языка — достаточно.

Иногда имеет смысл расширить ограничение до 85-90 символов если пользуешься языком, где изначально есть несколько контекстов (пакет, класс итд), но дело вовсе не в ширине экрана.

Нафига оно надо? Если уж так охота читать с листочков, то может размер шрифта мельче делать? Ради распечаток корячиться с длиной строк в 80 символов? Увольте...

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

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

CC>>Которая его заскоки примет безропотно?
E>Почему заскоки? Он же стал из-за чего-то лидером?

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

E>>>Это очень субъективная вещь. Кому-то то нравится, кому-то это. Вот прикинь, например начальник код выборочно вычитывает, но делает это с какого-то гаджета. И ему удобно, чтобы размер строки был не более чем. Это достаточное обоснование?

CC>>Если это на самом деле так, то да, достаточное. Я об этом тебе пытаюсь в разной форме уже несколько сообщений донести.
E>А какая ТЕБЕ разница, делает он так, или думает, что когда-нибудь будет делать?
Т.е. позиция "я начальник, ты дурак".
Решение августейшей персоны объявляются совершенными и оспариванию не подлежат?
Я как то привык к диалогу по проблемным вещам. Все ошибаются, и лиды тоже люди.
До сих пор все острые моменты как то решались.
С тем единственным, кто тупо гнул свою линию, не сработались. Как впоследствии оказалось — очень хорошо что не сработались. Довольно неприятные вещи начал творить тот человек, ещё до того как я оттуда ушёл.

CC>>Если ограничение объективно обосновано, т.е. оно не потому, что кому то так захотелось а есть реальные причины тому то претензий к ограничению нет.
E>А где критерий между "захотелось" и "есть причины"? И какая ТЕБЕ разница, насколько важные причины были у тех, кто принял то решение...

Мне всегда будет разница пока эти решения затрагивают мою работоспособность.
Я не собираюсь напрягаться впустую исключительно по прихоти лида.
Для пользы дела — готов. Для удовлетворения чьих либо ЧСВ — нет.

CC>>Я уже тоже наигрался, и хочу спокойно решать задачу, а не чесать ЧСВ некоего лида, которому кажется прикольным дописать ещё пару правил, только потому, что он у кого то их увидел. И похрен что тут эти правила не имеют под собой никакой реальной основы, просто ему кажется что взять тот же гуглов кодстайл будет круто, потому как гугл же его использует, вот и пусть мы тоже будем корячиться, пусть все думают что мы тоже как гугл крутые.
CC>>Вот за такое я и предлагаю гнать метлой.
E>А чем плохо взять гуглический кодестайл? Они же действительно его используют, и сам лид может там работал, например...
Тем, что серебряной пули не существует. И то, что в одном случае обосновано, разумно и эффективно в другом случае пустая трата сил и искусственные барьеры.

E>Ну и вообще я не понимаю, как ты проводишь границу обоснованности. И главное, ТЕБЕ-то какая разница что довело лида до жизни такой?

Дык его тараканы в итоге затрагивают меня, доставляют мне неудобства, сказываются на эффективности.
Может конечно бывают железные люди, которые не устают, не испытывают дискомфорт и прочая и прочая. Но я сделан из мяса.

CC>>Ради комфорта одного человека создавать дискомфорт всем остальным — это не объективная причина.
E>Я не понимаю, как ты определяешь "объективную" причину. Вот если лид с гаджета читает, но мог бы и с ноута, но ноут ему таскать неудобно. И?
В данном случае варианта два:
1) Это явная придурь лида. Все работают нормально, он один выделывается и хочет подстроить всех под себя. Если у всех разработчиков сколь либо одинаковый environment а он один выделяется то ССЗБ и хай сам парится со своим гаджетом и читает на нём как хочет, но не парит бОльшему кол-ву людей мозг своими заморочками. Вон у меня вообще
2) Это вынужденная мера, к примеру он реально не может пользоваться нормальным ноутом в силу ряда обьективных причин. Тогда да, можно принять такой кодстайл ради эффективности работы команды.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>То есть если абстрагироваться от уровня зряплаты, и рассмотреть два предложения. В одном быдлофомочки клепаем, но супер удобно всё, а в другом мышки не такие, ПО регламентировано, инструкция программиста драконовская, но решают интересные задачи. Ну, например, разрабатывают ПО к С-400, или переводчик или ещё что такое на переднем крае...
CC>Жизнь она вообще то не двуцветная.
CC>И как правило где проекты говно там и обстановка говно.

Дети, дети...

Жизнь она вообще то не двухцветная. Более того, у разных людей разные предпочтения. А слово говно — это всего лишь твой ярлык.

Кому то нравится веб, комуто финансы, комуто драйвера, распознавание образов, интернет магазины, суппорт, майнтенанс или стартапы. Мне вот нравится UI-заниматься(как вариант), а для кого то это "формоклепательство", "быдлоформы".

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

CC>Поэтому я пойду туда, где мне интересно, достаточно платят и работать комфортно (в том числе не долбут мозг всякой ересью).

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

CC>А если меня всё хорошо получается? Что тогда?

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

CC>Если ты не топ и навязанная ими конфигурация тебе не удобна — у тебя есть проблема. Которая в общем то на пустом месте, но на работоспособности сказывается.
CC>Можно утереться и сидеть, стараясь работать на том, что есть. А можно послать самодуров нахрен и найти компанию, где к людям относятся по людски. И которым нужен сам продукт а не процесс "вымучивания" продукта.

Интересно у тебя получилось, или топ и нет проблем, или не топ и есть проблемы. Жизнь она многоцветная. А слова вроде "самодуры" показывают, что тебе есть чего расказать самому себе

Вобщем, ассоциции у тебя какие то стрёмные, двухцветные. А судя по фразам "лямбды не нужны", "укушеные Александреску" некоторые твои заявления выглядят очень сомнительными.

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

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

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

CC>Начнём с того, что я постараюсь узнать побольше ДО того как к ним приду.
CC>И если меня не устроит их процесс то это будет им существенный минус. Я хочу решать задачу а не преодолевать бурелом "процесса". Уже напреодолевался, больше не желаю.

"напреодолевался"

Ты не ту профессию выбрал. В программинге надо быть или менеджером и кода не видеть, или девелопером, и преодолевать и код и процессы.

CC>Зачем работать в некомфортной обстановке если можно работать в комфортной.

Можно некомфортную отрефакторить и она станет комфортной

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

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

CC>Я уже тоже наигрался, и хочу спокойно решать задачу, а не чесать ЧСВ некоего лида, которому кажется прикольным дописать ещё пару правил, только потому, что он у кого то их увидел. И похрен что тут эти правила не имеют под собой никакой реальной основы, просто ему кажется что взять тот же гуглов кодстайл будет круто, потому как гугл же его использует, вот и пусть мы тоже будем корячиться, пусть все думают что мы тоже как гугл крутые.

А ты сам девелопер или тимлид ?

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

И>>Не читал код с распечаток лет пять как минимум. Оно же капец как неудобно — ни быстрой навигации и поиска, ни подсветки

Нафига оно надо? Если уж так охота читать с листочков, то может размер шрифта мельче делать? Ради распечаток корячиться с длиной строк в 80 символов? Увольте...

VV>Бывает полезно отойти от монитора, и подумать в обстановке отличающейся от рабочего места. Пара распечаток сложного куска кода не помешают, а вот какой-нибудь лэптоп — легко все испортит.
и ради одного такого мыслителя все должны корячиться с лимитом в 80 символов?
Я последний раз смотрел на код в распечатке когда у меня дома не было компа. И было это капец как давно.
Да и тогда лимита на колво строк не было. При печати просто срабатывал перенос. Читалось без проблем.
Зато читать код, который утрамбован в максимум длины неприятно. Я обычно код переформатирую в удобный для "внутреннего анализатора" вид, и тогда он легко и быстро читается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VV>Бывает полезно отойти от монитора, и подумать в обстановке отличающейся от рабочего места. Пара распечаток сложного куска кода не помешают, а вот какой-нибудь лэптоп — легко все испортит.

Распечатки это отсутствие навигации, подсветки, рефакторинга, анализа, интеллисенса и тд.

Максимум — фетиш который помогает сменить обстановку и отдохнуть.

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

CC>>Я уже тоже наигрался, и хочу спокойно решать задачу, а не чесать ЧСВ некоего лида, которому кажется прикольным дописать ещё пару правил, только потому, что он у кого то их увидел. И похрен что тут эти правила не имеют под собой никакой реальной основы, просто ему кажется что взять тот же гуглов кодстайл будет круто, потому как гугл же его использует, вот и пусть мы тоже будем корячиться, пусть все думают что мы тоже как гугл крутые.

Приходилось быть и девелопером и пм.
На разных проектах разумеется.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>>Т.е. бОльшая часть населения земли себя не уважает?
CC>>Интересной работы на самом деле очень мало. Тогда как обеспечить человеческие условия труда куда проще.
I>На самом деле интересной работы мало только у тебя. У меня вот очень много интересной работы

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

CC>>Начнём с того, что я постараюсь узнать побольше ДО того как к ним приду.
CC>>И если меня не устроит их процесс то это будет им существенный минус. Я хочу решать задачу а не преодолевать бурелом "процесса". Уже напреодолевался, больше не желаю.
I>"напреодолевался"

Ты не ту профессию выбрал. В программинге надо быть или менеджером и кода не видеть, или девелопером, и преодолевать и код и процессы.

Значит мне в последнее время везёт. Я и код вижу и ничего реально геморного преодолевать не надо.

I>Сиплюсники склонны все проблемы решать переписыванием, потому что вижло рефакторить не умеет.
VAX умеет.

I> Ну и пожизни точно так же — проф. деформация личности

Уйди тролль, тут еды не будет.

CC>>Но я живу и работаю на благо для себя. И пока у меня будет выбор, я буду выбирать те команды, в которых мне будет лучше всего по совокупности интересующих меня факторов. Как денег так и напрягов.
I>Как то жиденько и банально — деньги/напряги

Да куда нам до тебя, витающего в облаках.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>>То есть если абстрагироваться от уровня зряплаты, и рассмотреть два предложения. В одном быдлофомочки клепаем, но супер удобно всё, а в другом мышки не такие, ПО регламентировано, инструкция программиста драконовская, но решают интересные задачи. Ну, например, разрабатывают ПО к С-400, или переводчик или ещё что такое на переднем крае...
CC>>Жизнь она вообще то не двуцветная.
CC>>И как правило где проекты говно там и обстановка говно.
I>Дети, дети...

Жизнь она вообще то не двухцветная.
Капитан Очевидность, сходите почитайте топик, а?

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

CC>>А если меня всё хорошо получается? Что тогда?
I>Одно из двух — или ты величайший программист или ты просто не имеешь широкого круга контактов. Т.е. попросту или господь бог или варишься в собсвенном соку и боишься признаться даже самому себе, что могут быть люди которые знают и умеют лучше тебя.
Ты тему вообще читал?

CC>>Если ты не топ и навязанная ими конфигурация тебе не удобна — у тебя есть проблема. Которая в общем то на пустом месте, но на работоспособности сказывается.
CC>>Можно утереться и сидеть, стараясь работать на том, что есть. А можно послать самодуров нахрен и найти компанию, где к людям относятся по людски. И которым нужен сам продукт а не процесс "вымучивания" продукта.
I>Интересно у тебя получилось, или топ и нет проблем, или не топ и есть проблемы.
Иди читай тему.

I> Жизнь она многоцветная. А слова вроде "самодуры" показывают, что тебе есть чего расказать самому себе

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

I>Вобщем, ассоциции у тебя какие то стрёмные, двухцветные. А судя по фразам "лямбды не нужны", "укушеные Александреску" некоторые твои заявления выглядят очень сомнительными.
Брысь я сказал.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, R.O. Prokopiev, Вы писали:

ROP>Довод против остонадоевшего египетского стиля
Дык даже:

//    if(condition)
    {
        ...
    }

А вот так сфейлится

//    if(condition){
        ...
    }

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>Лида назначают.
CC>Лидер пользуется заслуженным уважением команды. Причём не только за проф. навыки но и за человеческие организационные навыки.
CC>Как можно догадаться, "вы будете делать то, что захотелось моей левой пятке" к уважению не приводит.
CC>"Нам придётся сделать вот так, потому как это необходимо для ..." — вполне.
Ну назначили же его почему-то. Как-то он вырос. Бывает что зря вырос, а бывает что не зря. Но фигня, вроде того, какие именно правила кому удобны, к этим вещам отношения не имеют...

CC>Т.е. позиция "я начальник, ты дурак".
Можешь и так назвать. Суть в том, что обмен понтами всегда контрпродуктивен. Так что даже такая грубая парадигма, как "я начальник, ты дурак" всё равно лучше выяснения вопросов вроде того, оскорбительно ли для тебя ограничение на длину строк...

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

CC>Я как то привык к диалогу по проблемным вещам. Все ошибаются, и лиды тоже люди.
CC>До сих пор все острые моменты как то решались.
Ну я не понимаю, как ограничение на форматирование текстов может быть острым моментом...

CC>Мне всегда будет разница пока эти решения затрагивают мою работоспособность.
CC>Я не собираюсь напрягаться впустую исключительно по прихоти лида.
CC>Для пользы дела — готов. Для удовлетворения чьих либо ЧСВ — нет.
А как ты проводишь границу? Опять, значит ли это, что все должны бросить все свои дела и убеждать тебя в том, что они не ЧСВ тешат, а ради каких-то прагматических целей действуют?

CC>Тем, что серебряной пули не существует. И то, что в одном случае обосновано, разумно и эффективно в другом случае пустая трата сил и искусственные барьеры.
Ну это предметно надо обсуждать, вообще-то.
Если, например, нет желания тратить силы на конфликтное и бессмысленное обсуждение, можно взять какой-то кодестайл за основу. За гуглический стоит то, что с ним люди смогли многого добиться. Хотя мне он тоже не нравится.

CC>Может конечно бывают железные люди, которые не устают, не испытывают дискомфорт и прочая и прочая. Но я сделан из мяса.
Я так тебя понял, что тебе не сложно пододвинуться, если ТЕБЕ кажется, что это надо для дела, но трудно, если ТЕБЕ КАЖЕТСЯ, что это кто-то ЧСВ тешит. IMHO, это комплексы и непрофессионально. По идее если не трудно пододвинуться в первом случае, то не трудно и во втором

CC>Лид такой же член команды как и прочие. И то, что он координирует усилия команды не даёт ему право считать себя барином а остальных говном, которые должны прогнуться чтоб ему было хорошо.
IMHO, это всё ерунда. Ты всё время формальные вопросы сводишь к обмену понтами. Обычно раьота в команде и отношения выстраиваются не на уровне формальных требований к коду. Ну просто есть ещё куча взаимодействий, кроме стандартов кодирования.

Они обычно важнее.

CC>Ему бы больше париться чтоб у команды было поменьше лишних заморочек и работать ничего не мешало, чем придумывать лишние препоны.
Ну да. Я про тоже самое. Просто если команда не с нуля создаётся, а есть уже какая-то, и туда приходит новичок, который начинает качать права по типу, что вот у вас там система контроля версий не такая, и коде стайл не тот, и буст вы не так юзаете и IDE у вас не такая и т. д.
То, IMHO, пусть лучше этот новичок уходит...

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

VV>Бывает полезно отойти от монитора, и подумать в обстановке отличающейся от рабочего места. Пара распечаток сложного куска кода не помешают, а вот какой-нибудь лэптоп — легко все испортит.
Ну вот я взял ради интереса и распечатал пару страниц кода из студии... теперь я вообще не понимаю из-за чего весь сыр-бор. Студия помечает перенесенные строки стрелочками, перенесенных строк не так уж и много на странице. Принципиально это на читабельность не влияет. Кстати, в одну строку без переносов у меня с дефолтными настройками влазят строки до 100-106 символов в длину. Если уменьшить отступы от краев листа, влезет еще больше. В чем вообще проблема?

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

CC>>Т.е. позиция "я начальник, ты дурак".
E>Можешь и так назвать. Суть в том, что обмен понтами всегда контрпродуктивен. Так что даже такая грубая парадигма, как "я начальник, ты дурак" всё равно лучше выяснения вопросов вроде того, оскорбительно ли для тебя ограничение на длину строк...

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

E>А как ты проводишь границу? Опять, значит ли это, что все должны бросить все свои дела и убеждать тебя в том, что они не ЧСВ тешат, а ради каких-то прагматических целей действуют?

Достаточно при объявлении ограничения озвучить для чего это делается.

CC>>Может конечно бывают железные люди, которые не устают, не испытывают дискомфорт и прочая и прочая. Но я сделан из мяса.
E>Я так тебя понял, что тебе не сложно пододвинуться, если ТЕБЕ кажется, что это надо для дела, но трудно, если ТЕБЕ КАЖЕТСЯ, что это кто-то ЧСВ тешит.
Что значит кажется?

CC>>Лид такой же член команды как и прочие. И то, что он координирует усилия команды не даёт ему право считать себя барином а остальных говном, которые должны прогнуться чтоб ему было хорошо.
E>IMHO, это всё ерунда. Ты всё время формальные вопросы сводишь к обмену понтами. Обычно раьота в команде и отношения выстраиваются не на уровне формальных требований к коду. Ну просто есть ещё куча взаимодействий, кроме стандартов кодирования.

Они обычно важнее.
Твои примеры просто из категории "я так решил и точка".

CC>>Ему бы больше париться чтоб у команды было поменьше лишних заморочек и работать ничего не мешало, чем придумывать лишние препоны.
E>Ну да. Я про тоже самое. Просто если команда не с нуля создаётся, а есть уже какая-то, и туда приходит новичок, который начинает качать права по типу, что вот у вас там система контроля версий не такая, и коде стайл не тот, и буст вы не так юзаете и IDE у вас не такая и т. д.
E>То, IMHO, пусть лучше этот новичок уходит...

Я про появление новых ограничений в уже существующей команде.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Распечатки это отсутствие навигации, подсветки, рефакторинга, анализа, интеллисенса и тд.
Фишка в том, что для проникновения в суть реально сложных проблем это всё не надо. И даже, скорее мешает. Так как деревья заслоняют лес, однако...

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

Здравствуйте, Игoрь, Вы писали:

VV>>Бывает полезно отойти от монитора, и подумать в обстановке отличающейся от рабочего места. Пара распечаток сложного куска кода не помешают, а вот какой-нибудь лэптоп — легко все испортит.
И>Ну вот я взял ради интереса и распечатал пару страниц кода из студии... теперь я вообще не понимаю из-за чего весь сыр-бор. Студия помечает перенесенные строки стрелочками, перенесенных строк не так уж и много на странице. Принципиально это на читабельность не влияет. Кстати, в одну строку без переносов у меня с дефолтными настройками влазят строки до 100-106 символов в длину. Если уменьшить отступы от краев листа, влезет еще больше. В чем вообще проблема?

Проблема не только в распечатках. Проблема в том, что ОБЫЧНО нехватка ширины в 80-90 символов для С++ обозначает, что чел пишет в таком стиле, который мне, например, не нравится.

У нас, кстати, например, есть ограничение не только на длины строк, но и на вложенность конструкций (циклов, if'ов и т. д.)
Грубо говоря, ограниченно максимальная глубина отступа внутри функции. И ничего, кроме хорошо от этого нет

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

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

Распечатка кода, как аргумент для ограничения длины строк кода, это, конечно, маразм.

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

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

VV>Потому что 80 символов — это ограничение на уровень говнокодовости написаного. Если у тебя много контекстов вложенно один в другой (if-if-switch-if-if-if) — ты легко выйдешь за такое ограничение. Если у тебя переменные названы в стиле stringThisIsMyNewVariableRenamedNowToOldOneSoNobodyKnowsWhatTheHeckIsHiddenOrMeantWithSuch1 то ты за ограничение выйдешь также. Если ты не делаешь таких глупостей — 80-90 символов в зависимости от языка — достаточно.

VV>Иногда имеет смысл расширить ограничение до 85-90 символов если пользуешься языком, где изначально есть несколько контекстов (пакет, класс итд), но дело вовсе не в ширине экрана.
Зачастую гораздо удобнее иметь имя с чуть более длинным названием, но из которого ясна суть, чем плодить мелкие аббревиатуры, смысл которых становится загадкой через некоторое время даже для самого автора. 85-90 мало, без вариантов.

Здравствуйте, Игoрь, Вы писали:

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

PS
На мой взгляд, единственное место, где уместны серьезные сокращения — это формулы в сложных вычислениях.

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

E>Проблема не только в распечатках. Проблема в том, что ОБЫЧНО нехватка ширины в 80-90 символов для С++ обозначает, что чел пишет в таком стиле, который мне, например, не нравится.
Так мы сейчас не твой стиль обсуждаем, вроде. Кстати, извини если ошибаюсь, но это случайно не ты говорил, что тебе не нравится stl и boost, и у вас там что-то свое реализовано? Так вот, мне такой стиль тоже не нравится.

Если говорить о С++, там строки зачастую короче, чем в C#, но тем не менее, вот отфонарная строка на С++, 92 символа без единого условоно оператора:

public:
class MyClass
{
    MyClass()
    {
        thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadFunc, NULL, 0, NULL);
    }
}

Чем такая запись хуже, если бы я эту функцию записал столбиком?

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

U>Распечатка кода, как аргумент для ограничения длины строк кода, это, конечно, маразм.
Ну всёж хоть какое то обоснование кроме "мне так хочется".

U>Но ограничение в 80 символов имеет вполне рациональное объяснение — примерно столько составляет поле зрения человека, соответственно если код имеет ширину около 80 символов, то глаза двигаются только вверх-вниз, а если шире, то еще и влево-вправо, что очень неудобно. На коде, конечно, это не так заметно, т.к. там все равно скорость чтения низкая, а вот на обычном тексте это очень заметно, читать книгу развернутую по ширине на те же самые 80 символов экрана и на всю ширину экрана это две очень большие разницы.
Мы всё таки про код или про худлит?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Распечатки это отсутствие навигации, подсветки, рефакторинга, анализа, интеллисенса и тд.
E>Фишка в том, что для проникновения в суть реально сложных проблем это всё не надо. И даже, скорее мешает. Так как деревья заслоняют лес, однако...

Кому как.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Проблема не только в распечатках. Проблема в том, что ОБЫЧНО нехватка ширины в 80-90 символов для С++ обозначает, что чел пишет в таком стиле, который мне, например, не нравится.
Хе хе.
Похоже начинает вырисовываться реальная причина.

E>У нас, кстати, например, есть ограничение не только на длины строк, но и на вложенность конструкций (циклов, if'ов и т. д.)
А у нас нет. Дикой вложенности при этом не наблюдается.
О чём это говорит?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Игoрь, Вы писали:

И>Если говорить о С++, там строки зачастую короче, чем в C#, но тем не менее, вот отфонарная строка на С++, 92 символа без единого условоно оператора:

И>

И>public:
И>class MyClass
И>{
И>    MyClass()
И>    {
И>        thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadFunc, NULL, 0, NULL);
И>    }
И>}
И>

И>Чем такая запись хуже, если бы я эту функцию записал столбиком?
ИМХО она лучше чем столбиком. Читабельнее.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

CC>Достаточно при объявлении ограничения озвучить для чего это делается.
Ну обычно объявляют. И если тебе кажется, что причина не важная, то что дальше?

CC>Что значит кажется?
Ну ты так считаешь. У тебя сложилось такое мнение и т. д...

CC>Твои примеры просто из категории "я так решил и точка".
Ну и что? Лид же начальник? Или кто? Почему он может решать важные вопросы, но не может такую ерунду, как особенности форматирования кода?

CC>Я про появление новых ограничений в уже существующей команде.
Ну тоже не понятно, зачем вообще со всеми согласовывать. Можно и с несколькими достаточно сведущими обсудить и ввести. Если эти топовые люди адекватны, то и нет проблем, а если нет, т проблемы там не в колестайле будут, IMHO...

Здравствуйте, Игoрь, Вы писали:

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

И>public:
И>class MyClass
И>{
И>    MyClass()
И>    {
И>        thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadFunc, NULL, 0, NULL);
И>    }
И>}
И>

И>Чем такая запись хуже, если бы я эту функцию записал столбиком?
Конкретно эта запись мне не нравится тем, что код конструктора находится в определении класса. Без всякого повода, прямо скажем...

Здравствуйте, Игoрь, Вы писали:

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

И>Так мы сейчас не твой стиль обсуждаем, вроде. Кстати, извини если ошибаюсь, но это случайно не ты говорил, что тебе не нравится stl и boost, и у вас там что-то свое реализовано? Так вот, мне такой стиль тоже не нравится.

Ну и что? Ты хотел меня обидеть, или что-то ещё сказать? Такое решение принимал не я, но мне STL ТОЖЕ не нравится.

И>Если говорить о С++, там строки зачастую короче, чем в C#, но тем не менее, вот отфонарная строка на С++, 92 символа без единого условоно оператора:

И>Чем такая запись хуже, если бы я эту функцию записал столбиком?

Собственно поинт не в этом. Я не понимаю почему требование записать эту функцию столбиком -- это так уж ужасно?

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

I>>>Распечатки это отсутствие навигации, подсветки, рефакторинга, анализа, интеллисенса и тд.
E>>Фишка в том, что для проникновения в суть реально сложных проблем это всё не надо. И даже, скорее мешает. Так как деревья заслоняют лес, однако...

CC>Кому как.

Дык ещё раз говорю, что от задачи всё зависит...

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

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

CC>Похоже начинает вырисовываться реальная причина.
Это одна из причин. У нас, например, ограничение в 120 букв, вроде. Я точно не помню, потому, что мне хватает меньше.

E>>У нас, кстати, например, есть ограничение не только на длины строк, но и на вложенность конструкций (циклов, if'ов и т. д.)
CC>А у нас нет. Дикой вложенности при этом не наблюдается.
CC>О чём это говорит?

О том, что тебя, например, это ограничение не напрягало бы

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

E>>>У нас, кстати, например, есть ограничение не только на длины строк, но и на вложенность конструкций (циклов, if'ов и т. д.)
CC>>А у нас нет. Дикой вложенности при этом не наблюдается.
CC>>О чём это говорит?

E>О том, что тебя, например, это ограничение не напрягало бы

80 символов? Я б не вмещался периодически.
Особенно в декларациях. WinAPI в целом достаточно многословен.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Здравствуйте, Игoрь, Вы писали:

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

И>>Так мы сейчас не твой стиль обсуждаем, вроде. Кстати, извини если ошибаюсь, но это случайно не ты говорил, что тебе не нравится stl и boost, и у вас там что-то свое реализовано? Так вот, мне такой стиль тоже не нравится.

E>Ну и что? Ты хотел меня обидеть, или что-то ещё сказать? Такое решение принимал не я, но мне STL ТОЖЕ не нравится.
Обидеть не хотел, но слегка поддеть захотелось, извини.

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

E>Собственно поинт не в этом. Я не понимаю почему требование записать эту функцию столбиком -- это так уж ужасно?
Это не ужасно, просто неудобно следить постоянно за длиной. К примеру, есть строка, которая укладывается в ограничение. Затем понадобилось отрефакторить эту часть, взял что-то автоматом добавил переименовал, и опа, строка уже превышает лимит на несколько симоволов. Потом еще смотри, чтобы ничего не вылезло. Я не понимаю зачем это надо.

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

И>>Чем такая запись хуже, если бы я эту функцию записал столбиком?
E>Конкретно эта запись мне не нравится тем, что код конструктора находится в определении класса. Без всякого повода, прямо скажем...

ну в try-catch можно засунуть, длина та же без единого условного оператора, без разницы, поверь, примеров привести могу много. Кстати, вот еще контр-пример, был код, все влазило, затем бах, захотели его запихнуть в try блок, теперь некотрые строки не влазят и их нужно переносить.

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

CC>80 символов? Я б не вмещался периодически.
Нет, на максимальный отступ/глубину вложенности

CC>Особенно в декларациях. WinAPI в целом достаточно многословен.
Ну я не вижу проблем вместиться в 80. Но мне комфортнее почти всегда в 80, а иногда в 100 где-то.
Редкие длинные строки не сильно напрягают, если только не надо по ним бегать глазами и они не переносятся при печати.
Но я не вижу никакой серьёзной проблемы всегда помещаться в 80...

IMHO, это примерно пофигу. Если кому-то это надо, то почему бы и нет?

Здравствуйте, Игoрь, Вы писали:

И>Обидеть не хотел, но слегка поддеть захотелось, извини.

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

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

Фишка в том, что тут как-то нервно на такую невиннуб вещь народ реагирует. Хотя, IMHO, это полная ерунда

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

Да, так неудобно. Но можно же поручить контроль этого дела IDE...

Здравствуйте, Игoрь, Вы писали:

И>Кстати, вот еще контр-пример, был код, все влазило, затем бах, захотели его запихнуть в try блок, теперь некотрые строки не влазят и их нужно переносить.

IMHO, весьма подозрительная правка, однако...

Я не являюсь сторонником такого ограничения, но и ничего страшного в нём не вижу. Особенно, если не 80, а 100 символов, например

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

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

И>>

И>>class MyClass
И>>{
И>>public:
И>>    MyClass()
И>>    {
И>>        thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadFunc, NULL, 0, NULL);
И>>    }
И>>};
И>>

И>>Чем такая запись хуже, если бы я эту функцию записал столбиком?
CC>ИМХО она лучше чем столбиком. Читабельнее.

class MyClass
{
public:
    MyClass();
};
//---implementation---------------------------------------
//
inline MyClass::MyClass()
{
    thread = CreateThread(
        NULL, 
        0, 
        (LPTHREAD_START_ROUTINE)&ThreadFunc, 
        NULL, 
        0, 
        NULL
    );
}

IMHO, программист, который испытывает трудности с восприятием верхней или нижней версии кода профессионально непригоден.

Или в этом есть сомнения?

Именно на это я как бы и намекаю

Здравствуйте, Игoрь, Вы писали:

И>Обидеть не хотел, но слегка поддеть захотелось, извини.

Ну, так, даже поверхностный анализ нового стандарта С++ показывает, что то, что не нравилось в STL мне, не нравилось и коммитетчикам, например

Так что ты это, мимо пальнул...

E>но мне STL ТОЖЕ не нравится.

удивительное замечание, потому что на мой взгляд, STL в С++ это как жемчужина в куче навоза.

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

D>удивительное замечание, потому что на мой взгляд, STL в С++ это как жемчужина в куче навоза.
Куча слишком велика, просто.

Тут был большой флейм про недостатки STL. Присоединяйтесь, барон! (с)

Я там многое уже написал. Возможно тебя удивит, но в новом стандарте комитет по стандартизации С++ таки учёл мою критику. К чему бы это?

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

E>Именно на это я как бы и намекаю

Ты б лучше читал на что вообще отвечаешь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>Именно на это я как бы и намекаю

CC>Ты б лучше читал на что вообще отвечаешь.

Моя не только прочитал, но и процитировал то, на что отвечал:

CC>ИМХО она лучше чем столбиком. Читабельнее.

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

E>>>Именно на это я как бы и намекаю

CC>>Ты б лучше читал на что вообще отвечаешь.

E>Моя не только прочитал, но и процитировал то, на что отвечал:
E>

CC>ИМХО она лучше чем столбиком. Читабельнее.

И что по твоему означает "читабельнее"?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Покажи пример такой системы.

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

Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.

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

Это нормальная задача или нет ?

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

CC>И что по твоему означает "читабельнее"?
Что более читабельный вариант легче понять. Или что-то другое?
Но если какой-то из двух тебе понять легче, значит второй тебе понять СЛОЖНЕЕ, так же?
А вот это, IMHO, нехорошо. Нормальный С++ программист под винду не должен испытывать НИКАКИХ ТРУДНОСТЕЙ ни с одной из этих двух версий кода. Я доступно излагаю?

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

I>Покажи пример такой системы.
Любая из промышленных реализаций QSort, например...

I>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

I>Все что надо было сделать — исправить утечки памяти, интерфейсов, устранить проезды по памяти.
I>Это нормальная задача или нет ?

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

В частности борьба с утечками и проездами -- это задача не такого сорта, обычно.
А вот борьба со взрывами QSort на каких-то специфичных данных -- самое то...

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

CC>>>Т.е. бОльшая часть населения земли себя не уважает?
CC>>>Интересной работы на самом деле очень мало. Тогда как обеспечить человеческие условия труда куда проще.
I>>На самом деле интересной работы мало только у тебя. У меня вот очень много интересной работы

CC>Не придуривайся. Ты прекрасно понимаешь что я не про конкретного человека пишу а про всё множество IT задач бизнеса. Сколько по твоему там интересных задач?

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

I>>"напреодолевался"

Ты не ту профессию выбрал. В программинге надо быть или менеджером и кода не видеть, или девелопером, и преодолевать и код и процессы.
CC>

CC>Значит мне в последнее время везёт. Я и код вижу и ничего реально геморного преодолевать не надо.

Я помню, это не у тебя код проекта в одной команде писаный ?

I>>Сиплюсники склонны все проблемы решать переписыванием, потому что вижло рефакторить не умеет.
CC>VAX умеет.

Не умеет.

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

CC>>>Жизнь она вообще то не двуцветная.
CC>>>И как правило где проекты говно там и обстановка говно.
I>>Дети, дети...

Жизнь она вообще то не двухцветная.
CC>Капитан Очевидность, сходите почитайте топик, а?

Видишь, стоило употребить твою же фразу, как внезапно оказалось что фраза принадлежит известному К.О.

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

Конечно.

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

I>>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
E>И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

200кб кода на одну функцию говорит практически всё про качество кода

А алгоритмы были нетривиальными.

E>В частности борьба с утечками и проездами -- это задача не такого сорта, обычно.
E>А вот борьба со взрывами QSort на каких-то специфичных данных -- самое то...

А по моему ты избегаешь нормальных инструментов.

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

E>>А вот борьба со взрывами QSort на каких-то специфичных данных -- самое то...

I>А по моему ты избегаешь нормальных инструментов.

Каких, например?

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

E>>>А вот борьба со взрывами QSort на каких-то специфичных данных -- самое то...

I>>А по моему ты избегаешь нормальных инструментов.

E>Каких, например?

Были перечислены. Еще можно добавить логирование, профайлеры и тд.

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

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

I>Были перечислены. Еще можно добавить логирование, профайлеры и тд.
I>Та же диаграма последовательностей будет гораздо полезнее бумажки с кодом.

Я указал конкретную проблему. Взрыв QSort на каких-то специфичных данных. Чем там поможет подсветка и рефакторилка? Ну и вообще что именно поможет-то, кроме головы?

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

E>Здравствуйте, Игoрь, Вы писали:

И>>Кстати, вот еще контр-пример, был код, все влазило, затем бах, захотели его запихнуть в try блок, теперь некотрые строки не влазят и их нужно переносить.

E>IMHO, весьма подозрительная правка, однако...

E>Я не являюсь сторонником такого ограничения, но и ничего страшного в нём не вижу. Особенно, если не 80, а 100 символов, например

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

У тебя мания. Ничего особо подозрительного в том коде нет, ну кроме того, что вместо CreateThread можно было бы использовать beginthreadex. Я просто записал первую пришедшую на ум конструкцию с относительно длинным системным вызовом. На С++ я уже не программирую года два-три, поэтому никакого С++ кода под рукой нет.

Здравствуйте, Игoрь, Вы писали:

E>>Правда прикольно? Насколько я понимаю, такого рода ограничения часто вводят просто на основе статистики. Типа если длинные строки коррелируют с E>>проблемами, то надо бы длинные строки хотя бы вычитать...

А это уже из серии: чем дальше в лес, тем толще партизаны. Самому не смешно?

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

E>Ну, так, даже поверхностный анализ нового стандарта С++ показывает, что то, что не нравилось в STL мне, не нравилось и коммитетчикам, например

E>Так что ты это, мимо пальнул...

Неужели комитетчики выкинули STL, как эот сделали вы?

Здравствуйте, Игoрь, Вы писали:

И>У тебя мания. Ничего особо подозрительного в том коде нет, ну кроме того, что вместо CreateThread можно было бы использовать beginthreadex. Я просто записал первую пришедшую на ум конструкцию с относительно длинным системным вызовом. На С++ я уже не программирую года два-три, поэтому никакого С++ кода под рукой нет.

В каком именно? В том, который ты привёл? Странно то, что определение класса замусорили кодом конструктора. И вообще странно, что код этого конструктора в хедере, если честно.

Ещё ты упомянул операцию, когда блок кода засовывают в try{}catch... это тоже какая-то подозрительная крайне акция. Очень похоже не затычку какую-то...

Но я думаю это всё из-за умозрительности примеров. Наверняка можно найти некриминальный пример. Но это ничего не докажет

Здравствуйте, Игoрь, Вы писали:

И>Неужели комитетчики выкинули STL, как эот сделали вы?

Нет, они допилили std::vector до уровня наших коллекций

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

E>Фишка в том, что тут как-то нервно на такую невиннуб вещь народ реагирует. Хотя, IMHO, это полная ерунда

Ну ограничение в 80 символов реально неудобно. Вводить ограничение 100-120, можно наверное, если делать нечего.

E>Да, так неудобно. Но можно же поручить контроль этого дела IDE...

Чем дальше, тем круче. Смысл с этим всем возиться?

Здравствуйте, Игoрь, Вы писали:

E>>>Правда прикольно? Насколько я понимаю, такого рода ограничения часто вводят просто на основе статистики. Типа если длинные строки коррелируют с E>>проблемами, то надо бы длинные строки хотя бы вычитать...

И>А это уже из серии: чем дальше в лес, тем толще партизаны. Самому не смешно?

А что именно смешно? Если подход работает, то в чём проблемы-то? Статический анализ кода -- это дорого и сложно, а поиск длинных строк -- нет. Если вторая метода позволяет выявлять проблемы, то почему бы нет-то?

Здравствуйте, Игoрь, Вы писали:

E>>Фишка в том, что тут как-то нервно на такую невиннуб вещь народ реагирует. Хотя, IMHO, это полная ерунда

И>Ну ограничение в 80 символов реально неудобно. Вводить ограничение 100-120, можно наверное, если делать нечего.

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

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

E>Здравствуйте, Игoрь, Вы писали:

И>>У тебя мания. Ничего особо подозрительного в том коде нет, ну кроме того, что вместо CreateThread можно было бы использовать beginthreadex. Я просто записал первую пришедшую на ум конструкцию с относительно длинным системным вызовом. На С++ я уже не программирую года два-три, поэтому никакого С++ кода под рукой нет.

E>В каком именно? В том, который ты привёл? Странно то, что определение класса замусорили кодом конструктора. И вообще странно, что код этого конструктора в хедере, если честно.
Ну код может быть в хедере, если мы хотим его заинлайнить, другое дело, что создание потока инлайнить нет никакого смысла. С этим соглашусь.

E>Ещё ты упомянул операцию, когда блок кода засовывают в try{}catch... это тоже какая-то подозрительная крайне акция. Очень похоже не затычку какую-то...

А вот это мне непонятно, что для тебя подозрительно в блоке try-catch? Или ты еще и исключения не любишь?

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

E>А что именно смешно? Если подход работает, то в чём проблемы-то? Статический анализ кода -- это дорого и сложно, а поиск длинных строк -- нет. Если вторая метода позволяет выявлять проблемы, то почему бы нет-то?
Ну не знаю, в C# оно не так уж и сложно, статический анализ

Тулзов вроде хватает. Просто первый раз слышу теорию о связи между длиной строк и кол-вом ошибок (если мы говорим о вменяемых размерах, без фанатизма).

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

E>Почему? Это всего лишь обозначает, что длинные выражения надо писать "в столбик" и избегать мегавложенных конструкций. И что?
E>Неужели функции в столбик -- для кого-то проблема?

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

Здравствуйте, Игoрь, Вы писали:

И>>>У тебя мания. Ничего особо подозрительного в том коде нет, ну кроме того, что вместо CreateThread можно было бы использовать beginthreadex. Я просто записал первую пришедшую на ум конструкцию с относительно длинным системным вызовом. На С++ я уже не программирую года два-три, поэтому никакого С++ кода под рукой нет.
И>Ну код может быть в хедере, если мы хотим его заинлайнить, другое дело, что создание потока инлайнить нет никакого смысла. С этим соглашусь.

Возможно ты забыл уже немного С++ приколы.
Но у меня к тому коду ДВЕ претензии.
1) Мне не нравится, что определение конструктора находится в определении класса. Не нравится оно мне потому, что я исповедую такой подход, что объявление класса -- это в первую очередь для его пользователей, а не для разработчиков. Соответственно, на мой взгляд, даже если бы мы хотели это заинлайнить, то надо было всё равно писать определение ниже.
2) Инлайнить это никакого смысла тоже нет. Просто лишнияе зависимости вносим в код и всё. Но с этим ты вроде как согласен

E>>Ещё ты упомянул операцию, когда блок кода засовывают в try{}catch... это тоже какая-то подозрительная крайне акция. Очень похоже не затычку какую-то...

И>А вот это мне непонятно, что для тебя подозрительно в блоке try-catch? Или ты еще и исключения не любишь?

Почему не люблю? Я же не гугловод

Я недолюбливаю блоки try {} catch разбросанные где попало. Это да.
Но иы упомянул другой совсем сценарий. Типа был код, там всё было хорошо с отступами и длинами, а потом мы его решили затолкать в try {} catch. Вот это вот решение для меня подозрительно. Я бы обязательно проверил бы, зачем это могло бы понадобиться, и точно ли тут не в ошибке проектирования дело...

Здравствуйте, Игoрь, Вы писали:

И>Ну не знаю, в C# оно не так уж и сложно, статический анализ

Тулзов вроде хватает. Просто первый раз слышу теорию о связи между длиной строк и кол-вом ошибок (если мы говорим о вменяемых размерах, без фанатизма).

Я не утверждал конкретно про длину строк. Про длину я утверждал другое. Что ОБЫЧНО те, кому сильно не хватает 80-90 для С++ пишут так, что у меня к ним есть и другие претензии.
А второе моё утверждение состояло в том, что AFAIK, всякие метрические ограничения вводят на основании статистики просто. Ну типа если что-то коррелирует с ошибками, то на это что-то стоит обратить внимание, даже если мы не понимаем почему оно коррелирует...

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

I>>>"напреодолевался"

Ты не ту профессию выбрал. В программинге надо быть или менеджером и кода не видеть, или девелопером, и преодолевать и код и процессы.
CC>>

CC>>Значит мне в последнее время везёт. Я и код вижу и ничего реально геморного преодолевать не надо.
I>Я помню, это не у тебя код проекта в одной команде писаный ?

Видимо не у меня.

I>>>Сиплюсники склонны все проблемы решать переписыванием, потому что вижло рефакторить не умеет.
CC>>VAX умеет.
I>Не умеет.
Умеет умеет.
Все что надо для С++ он умеет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

CC>>>>Жизнь она вообще то не двуцветная.
CC>>>>И как правило где проекты говно там и обстановка говно.
I>>>Дети, дети...

Жизнь она вообще то не двухцветная.
CC>>Капитан Очевидность, сходите почитайте топик, а?

I>Видишь, стоило употребить твою же фразу, как внезапно оказалось что фраза принадлежит известному К.О.

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

I>>>Одно из двух — или ты величайший программист или ты просто не имеешь широкого круга контактов. Т.е. попросту или господь бог или варишься в собсвенном соку и боишься признаться даже самому себе, что могут быть люди которые знают и умеют лучше тебя.
CC>>Ты тему вообще читал?
I>Конечно.
Что то в глаза не бросается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>>И что по твоему означает "читабельнее"?
E>Что более читабельный вариант легче понять. Или что-то другое?
E>Но если какой-то из двух тебе понять легче, значит второй тебе понять СЛОЖНЕЕ, так же?
Вот у тебя есть две коробки. Ты без проблем можешь поднять любую из них, но одна из них заметно легче.
Понятно, нет?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Здравствуйте, Игoрь, Вы писали:

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

И>>public:
И>>class MyClass
И>>{
И>>    MyClass()
И>>    {
И>>        thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadFunc, NULL, 0, NULL);
И>>    }
И>>}
И>>

И>>Чем такая запись хуже, если бы я эту функцию записал столбиком?
E>Конкретно эта запись мне не нравится тем, что код конструктора находится в определении класса. Без всякого повода, прямо скажем...

Т.е. то, что это пример а не промышленный код тебя не смущает?
Надо доколупаться и искать "ашипки" в псевдокоде, приведённом для иллюстрации?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

E>В частности борьба с утечками и проездами -- это задача не такого сорта, обычно.
E>А вот борьба со взрывами QSort на каких-то специфичных данных -- самое то...

Для этого изобрели отладчики с пошаговой отладкой и дампы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Были перечислены. Еще можно добавить логирование, профайлеры и тд.
I>>Та же диаграма последовательностей будет гораздо полезнее бумажки с кодом.

E>Я указал конкретную проблему. Взрыв QSort на каких-то специфичных данных. Чем там поможет подсветка и рефакторилка? Ну и вообще что именно поможет-то, кроме головы?
Отладчик.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>>>Капитан Очевидность, сходите почитайте топик, а?

I>>Видишь, стоило употребить твою же фразу, как внезапно оказалось что фраза принадлежит известному К.О.

CC>Фраза принадлежит мне же в этом же контексте несколько выше по топику.

Об чем и речь.

CC>Иди и почитай.
CC>Потом перечитай то, на что ты её решил ввернуть.

Ты сам перечитай. "И как правило где проекты говно там и обстановка говно"

CC>Внимательно, а не как ты обычно читаешь.
CC>Обрати внимание на фразу "как правило"
CC>И подумай как тут можно углядеть двуцветный мир.

Фраза говорит сама за себя. А если ты попробуешь прочесть чуть дальше, то поймешь что к чему.

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

CC>и ради одного такого мыслителя все должны корячиться с лимитом в 80 символов?

Отличный вопрос! Давайте запомним его и поставим галочку, чтобы вернуться к нему позже!

А сейчас скажите пожалуйста, умеете ли Вы читать?

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

I>Распечатки это отсутствие навигации, подсветки, рефакторинга, анализа, интеллисенса и тд.
I>Максимум — фетиш который помогает сменить обстановку и отдохнуть.

Вполне возможно. А почему Вы вдруг заговорили о фетишах?

Здравствуйте, Игoрь, Вы писали:

И>Ну вот я взял ради интереса и распечатал пару страниц кода из студии... теперь я вообще не понимаю из-за чего весь сыр-бор. Студия помечает перенесенные строки стрелочками, перенесенных строк не так уж и много на странице. Принципиально это на читабельность не влияет. Кстати, в одну строку без переносов у меня с дефолтными настройками влазят строки до 100-106 символов в длину. Если уменьшить отступы от краев листа, влезет еще больше. В чем вообще проблема?

Я не знаю почему вы решили что распечатать код — проблема. В конце концов лист можно развернуть на 90. Вообще ограничение не для печати. А для того, чтобы писали читаемый код. Так же как размер функции на экран.

Здравствуйте, Игoрь, Вы писали:

VV>>Иногда имеет смысл расширить ограничение до 85-90 символов если пользуешься языком, где изначально есть несколько контекстов (пакет, класс итд), но дело вовсе не в ширине экрана.
И>Зачастую гораздо удобнее иметь имя с чуть более длинным названием, но из которого ясна суть, чем плодить мелкие аббревиатуры, смысл которых становится загадкой через некоторое время даже для самого автора. 85-90 мало, без вариантов.

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

Здравствуйте, Игoрь, Вы писали:

И>

И>        thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadFunc, NULL, 0, NULL);
И>

И>Чем такая запись хуже, если бы я эту функцию записал столбиком?

Плохо уже тем, что у вас функция принимает 6 параметров. Но претензия не к Вам — без вопросов.

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

I>>Распечатки это отсутствие навигации, подсветки, рефакторинга, анализа, интеллисенса и тд.
I>>Максимум — фетиш который помогает сменить обстановку и отдохнуть.

VV>Вполне возможно. А почему Вы вдруг заговорили о фетишах?

Фетиш — неодушевлённый предмет, наделённый сверхъестественными свойствами. Наиболее распространённые фетиши — амулеты, обереги, талисманы. В переносном смысле — то, что является предметом безусловного признания, слепого поклонения. У большинства людей в современном обществе это всевозможные вещи (сотовые, машины, одежда и пр.), где цена за имя фетиша растёт не сопоставимо росту качества этой техники, но эта вещь является предметом безусловного признания в кругу общения данного индивида.

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

Я решил, что пока дело всего лишь в необходимости отдыха. А почему тебя беспокоит что я спросил про фетиш ?

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

Вы научились пользоваться поиском — это безусловно позитивный процесс! А почему Вам кажется, что кто-то беспокоится?

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

VV>Вы научились пользоваться поиском — это безусловно позитивный процесс! А почему Вам кажется, что кто-то беспокоится?

Очевидно, что твой психиатор сливает приватную инфу. Подай на него в суд

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

VV>>Вы научились пользоваться поиском — это безусловно позитивный процесс! А почему Вам кажется, что кто-то беспокоится?
I>Очевидно, что твой психиатор сливает приватную инфу. Подай на него в суд

Как интересно. Что еще Вам кажется?

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

E>Я указал конкретную проблему. Взрыв QSort на каких-то специфичных данных. Чем там поможет подсветка и рефакторилка? Ну и вообще что именно поможет-то, кроме головы?

Сколько тебе лет ?

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

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

I>У меня были похожие задачи, получалось решать их используя инструменты.
I>Вместо того, что бы эмулировать головой control flow, нужно проводить эксперименты, менять вход, ввододть логирование, пользоваться отладкой и тд.

это все здорово, если ты можешь воспроизвести проблему..

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

I>Сколько тебе лет ?

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

I>У меня были похожие задачи, получалось решать их используя инструменты.

Поразительная логика. Вы феноменальны!

Прошу не принимать на свой счет. Просто вспомнилась прекрасная песня группы Несчастный Случай: "Я готов предугадывать мысли людей и собак, Но мышление устриц — это какой-то мрак..."

I>Вместо того, что бы эмулировать головой control flow, нужно проводить эксперименты, менять вход, ввододть логирование, пользоваться отладкой и тд.

Это называется "сила заднего ума".

I>>У меня были похожие задачи, получалось решать их используя инструменты.
I>>Вместо того, что бы эмулировать головой control flow, нужно проводить эксперименты, менять вход, ввододть логирование, пользоваться отладкой и тд.

D>это все здорово, если ты можешь воспроизвести проблему..

Не "можешь", а "умеешь".

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

U>>Но ограничение в 80 символов имеет вполне рациональное объяснение — примерно столько составляет поле зрения человека, соответственно если код имеет ширину около 80 символов, то глаза двигаются только вверх-вниз, а если шире, то еще и влево-вправо, что очень неудобно. На коде, конечно, это не так заметно, т.к. там все равно скорость чтения низкая, а вот на обычном тексте это очень заметно, читать книгу развернутую по ширине на те же самые 80 символов экрана и на всю ширину экрана это две очень большие разницы.
CC>Мы всё таки про код или про худлит?

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

Простите, господа, что вмешиваюсь в выяснения отношений...

(А тема-то не упала до сих пор — значит, данный вопрос людям не безразличен, и
не такие уж это и "просто скобочки" !).

Итак, недавно наткнулся в одном форуме на сообщение человека, который никак не
мог найти причину загадочного поведения главного цикла вот в таком коде (ничего не
приукрашено — все как в оригинале):

Скрытый текст

while(((((numColsArg/N)*K)+(numColsArg%N))>=resultNumArg) && (((numColsArg/N)*K)+(numColsArg%N))>N){
    circle=0; 
    Form1->ProgressBar1->Min=0;
    Form1->ProgressBar1->Max=numColsArg/N;
    Form1->ProgressBar1->Position=0;
    while(circle<numColsArg/N){
      Form1->ProgressBar1->StepBy(1);
      Application->ProcessMessages();
      rightOne=N-1;
      rightZero=N-1;
      nextOne=0;
      sigmaMin=100000000000000000000000;
      //Обнуляем массив сочетаний
      for(int i=0;i<N;i++)
        if(i<K){
          mass[i]=1;
          matrixGroup[i]=new long double[numRowsArg];
        } else mass[i]=0;
      for(unsigned long int iteration=0; iteration<C;iteration++){
        //Заполняем массив из N элементов
        int MatCount=0;//счётчик
        for(int i=0; i<N; i++)
          if(mass[i]){
            for(int r=0;r<numRowsArg;r++)
              matrixGroup[MatCount][r]=dataSource[i+N*circle][r];
            MatCount++;
          }
        sigma=0;
        for(int l=0; l<left;l++)
          sigma+=sigmaFunc(matrixGroup, funcVal, numRowsArg, numRowsInModel,l,K,false);   
        sigma/=left;
        if(sigma<sigmaMin){
          sigmaMin=sigma;
          for(int q=0; q<N; q++)
            if(mass[q]) massSigmaBest[q]=1;
            else massSigmaBest[q]=0;
        }
        rightZero=rightOne=N-1;
        //Если правый бит не единица, находим ближайшую единицу и сдвигаем вправо на 1
        while(!mass[rightOne]) rightOne--;
        if(rightOne!=N-1){
          mass[rightOne]=0;
          mass[rightOne+1]=1;
          continue;
        }
        //Если правый бит единица
        //Считаем количество единиц справа
        while(mass[rightZero]) rightZero--;
        //Исключаем единичные разряды справа из рассмотрения
        //находим ближайшую единицу и перемещаем на 1 вправо
        if(rightZero!=N-1){
          nextOne=rightZero;
          while(!mass[nextOne]) nextOne--;
          mass[nextOne]=0;
          mass[nextOne+1]=1;
          for(int i=rightZero+1; i<N; i++)
            mass[i]=0;
          for(int i=nextOne+2;i<nextOne+2+(N-1-rightZero);i++)
            mass[i]=1;
        }
      }
      //Сдвигаем значения вправо
      for(int j=0,k=0; j<N; j++)
      if(massSigmaBest[j]){
        for(int i=0; i<numRowsArg;i++)
          dataSource[k+circle*K][i]=dataSource[j+circle*N][i];
        titleHead[k+circle*K][0]=titleHead[j+circle*N][0];
        titleHead[k+circle*K][1]=titleHead[j+circle*N][1];
        k++;
      }
      circle++;
      Sh1.OlePropertyGet("Cells",(numRowsArg*left+10+step),(circle+1)).OlePropertySet("Value",((AnsiString)(double)sigmaMin).c_str());
    }
    for(int j=0;j<(numColsArg%N);j++){
      for(int i=0; i<numRowsArg;i++)
        dataSource[j+circle*K][i]=dataSource[j+circle*N][i];
      titleHead[j+circle*K][0]=titleHead[j+circle*N][0];
      titleHead[j+circle*K][1]=titleHead[j+circle*N][1];
    }
    step++;
    numColsArg=((numColsArg/N)*K)+(numColsArg%N);
  }

По словам "очевидцев", на некоторых входных данных программа так круто зацикливается, что не
хочет завершать цикл, несмотря на то, что одно из условий главного while равно false (смотрели
под отладчиком), и даже вручную вставленная инструкция break ничего не дает (!) —
программа продолжает выполняться со следующей строки.

Казалось бы — при чем тут скобки ?

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

I>>>У меня были похожие задачи, получалось решать их используя инструменты.
I>>>Вместо того, что бы эмулировать головой control flow, нужно проводить эксперименты, менять вход, ввододть логирование, пользоваться отладкой и тд.

D>>это все здорово, если ты можешь воспроизвести проблему..

I>Не "можешь", а "умеешь".

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

Опять же, логгирование или отладка вносят свой вклад. И при более усиленном логгировании ошибка банально не воспроизводится. А когда воспроизводится, то детализации логов недостаточно. В этом случае толку от твоих умений будет ноль

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>>>Значит мне в последнее время везёт. Я и код вижу и ничего реально геморного преодолевать не надо.
I>>Я помню, это не у тебя код проекта в одной команде писаный ?

CC>Видимо не у меня.

А моему у тебя.

I>>>>Сиплюсники склонны все проблемы решать переписыванием, потому что вижло рефакторить не умеет.
CC>>>VAX умеет.
I>>Не умеет.
CC>Умеет умеет.
CC>Все что надо для С++ он умеет.

Вот видишь, уже уточнять начал

Смотрим вместе, вычеркнул глупости всякие. Сам видишь — жиденько. И для классов, интерфейсов практически ничего нет.

•Rename
•Extract Method
~~•Encapsulate Field~~
•Change Signature
~~•Move Implementation to Source File~~
~~•Create from Usage~~
~~•Add Member~~
~~•Add Similar Member~~
~~•Document Method~~
•Create Declaration
•Create Implementation

То есть, VAX умеет рефакторить для C, но не для С++

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

I>>У меня были похожие задачи, получалось решать их используя инструменты.

VV>Поразительная логика. Вы феноменальны!

Я обычный, а ты и для фона не годишься.

I>>Вместо того, что бы эмулировать головой control flow, нужно проводить эксперименты, менять вход, ввододть логирование, пользоваться отладкой и тд.

VV>Это называется "сила заднего ума".

Это инженерия. А "задний ум" есть гадание по бумажке.

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

I>>Не "можешь", а "умеешь".

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

Да, необходимость подумать никто не отменял, ты прав

AV>Опять же, логгирование или отладка вносят свой вклад. И при более усиленном логгировании ошибка банально не воспроизводится. А когда воспроизводится, то детализации логов недостаточно. В этом случае толку от твоих умений будет ноль

Бывает и такое. Тебя ведь никто не ограничивает логами ?

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

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

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

O>

	Скрытый текст
	O> `O>while(((((numColsArg/N)K)+(numColsArg%N))>=resultNumArg) && (((numColsArg/N)K)+(numColsArg%N))>N){ ... O> } O>`

O>По словам "очевидцев", на некоторых входных данных программа так круто зацикливается, что не
O>хочет завершать цикл, несмотря на то, что одно из условий главного while равно false (смотрели
O>под отладчиком), и даже вручную вставленная инструкция break ничего не дает (!) -
O>программа продолжает выполняться со следующей строки.

O>Казалось бы — при чем тут скобки ?

Вот когда такого кода на 200-500кб, то начинается самое интересное

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

I>>>Не "можешь", а "умеешь".

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

I>Да, необходимость подумать никто не отменял, ты прав

Угу, вот только чтобы придумать этот набор входных данных надо не мало времени потратить на просмотр и анализ в голове кода. Так что от "умеешь" толку ноль.

AV>>Опять же, логгирование или отладка вносят свой вклад. И при более усиленном логгировании ошибка банально не воспроизводится. А когда воспроизводится, то детализации логов недостаточно. В этом случае толку от твоих умений будет ноль

I>Бывает и такое. Тебя ведь никто не ограничивает логами ?

I>Я вот не пойму, чем отсутствие инструментов может быть лучше их наличия.

Никто не говорит, что отсутствие инструментов лучше. Говорят, что они не всегда могут помочь. Разницу видишь?

I>Хотелось бы увидеть качественный пример, а не булшит про сортировку.

А сортировка тоже может неудачно выстрелить.

Могу еще один случай привести. Была у нас ситуация, когда на специально подобранном наборе данных сервак обламывался. Такой набор данных в реальной жизни если и встретиться, то хорошо, если раз в пару лет. А можешь и не столкнуться. Тем не менее, тестеры смогли смоделировать ситуацию. Из логов понятно приблизительное место где возникает проблема. Кода там не так уж и много. Сотни три строк. Но точнее узнать не получается. Поставили большую детализацию, все начало пахать идеально. Под отладчиком эта проблема вообще никогда не воспроизводилась. Искали как раз по распечаткам. По банальной причине. Удобнее. На бумаге удобнее делать пометки. Причина оказалась банальной. Две подсистемы должны были работать независимо. Но так уж сложилось, что на том наборе входных данных зависимость все таки присутствовала.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Да, необходимость подумать никто не отменял, ты прав

AV>Угу, вот только чтобы придумать этот набор входных данных надо не мало времени потратить на просмотр и анализ в голове кода. Так что от "умеешь" толку ноль.

Есть инструменты, которые облегчают просмотр и анализ кода.

I>>Я вот не пойму, чем отсутствие инструментов может быть лучше их наличия.

AV>Никто не говорит, что отсутствие инструментов лучше. Говорят, что они не всегда могут помочь. Разницу видишь?

Пример приведи.

I>>Хотелось бы увидеть качественный пример, а не булшит про сортировку.

AV>А сортировка тоже может неудачно выстрелить.

Может. Не возникало сложностей с алгоритмами сложнее сортировки, что бы найти проблему

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

Видишь, один инструмент ты уже сам назвал

>Из логов понятно приблизительное место где возникает проблема. Кода там не так уж и много. Сотни три строк.

Это уже второй инструмент.

>Но точнее узнать не получается. Поставили большую детализацию, все начало пахать идеально.

Что такое "детализация" ?

>Под отладчиком эта проблема вообще никогда не воспроизводилась. Искали как раз по распечаткам. По банальной причине. Удобнее. На бумаге удобнее делать пометки. Причина оказалась банальной.

Т.е. вы эмулировали бумагой анализатор, что можно поделать

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

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

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

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

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

CC>Вот у тебя есть две коробки. Ты без проблем можешь поднять любую из них, но одна из них заметно легче.
CC>Понятно, нет?

Нет не понятно. В случае с коробками ты ощущаешь усилие по их подъёму, просто оно тебе по силам. А в случае с обсуждаемыми фрагментами усилия, связанные с преодолением непривычного форматирования должны быть просто НЕЗАМЕТНО МАЛЫ для тебя.

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

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

CC>Т.е. то, что это пример а не промышленный код тебя не смущает?
CC>Надо доколупаться и искать "ашипки" в псевдокоде, приведённом для иллюстрации?

Да нет. Надо просто приводить РЕАЛЬНЫЙ код, в качестве примера.
Я ещё раз намекаю, что AFAIK, некоторые, кажущиеся бредовыми ограничения на форматирование в некоторых известных мне местах были введены чисто из соображений корреляции.
Типа из пяти последних тяжёлых ошибок за каждой из которых гонялись по неделе, в четверых фигурировали строки длиннее 90, хотя такие длинные строки редкость -- значит надо запретить такие длинные строки и вычитать весь код, их содержащий...

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

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

E>>А вот борьба со взрывами QSort на каких-то специфичных данных -- самое то...

CC>Для этого изобрели отладчики с пошаговой отладкой и дампы.

Обычно, если взрыв стал заметен, то значит "специфичные данные" -- это довольно большой объём. Например 10 000 элементов. Или больше.

Хотя отладку по логам я тоже приветствую, как и пошаговую. Просто всё удобно на СВОЁМ месте...

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

CC>Отладчик.

Предлагаешь оттрассировать пару мегаитераций внутреннего цикла?

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

I>>>Да, необходимость подумать никто не отменял, ты прав

AV>>Угу, вот только чтобы придумать этот набор входных данных надо не мало времени потратить на просмотр и анализ в голове кода. Так что от "умеешь" толку ноль.

I>Есть инструменты, которые облегчают просмотр и анализ кода.

Вот только не всегда от них есть польза

I>>>Я вот не пойму, чем отсутствие инструментов может быть лучше их наличия.

AV>>Никто не говорит, что отсутствие инструментов лучше. Говорят, что они не всегда могут помочь. Разницу видишь?

I>Пример приведи.

Уже привел в прошлом сообщении.

I>>>Хотелось бы увидеть качественный пример, а не булшит про сортировку.

AV>>А сортировка тоже может неудачно выстрелить.

I>Может. Не возникало сложностей с алгоритмами сложнее сортировки, что бы найти проблему

Если у тебя чего-то не возникало, то не значит, что этого не может быть.

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

I>Видишь, один инструмент ты уже сам назвал

Вах, вот только это помогло узнать что проблема есть. И ничего более.

>>Из логов понятно приблизительное место где возникает проблема. Кода там не так уж и много. Сотни три строк.

I>Это уже второй инструмент.

От которого толку ноль. Я и без логов мог с достаточной точностью определить где проблема. Да, чуть больший кусок пришлось бы просмотреть, строк 400-500. Не более.

>>Но точнее узнать не получается. Поставили большую детализацию, все начало пахать идеально.

I>Что такое "детализация" ?

Больше информации (деталей) в логах.

>>Под отладчиком эта проблема вообще никогда не воспроизводилась. Искали как раз по распечаткам. По банальной причине. Удобнее. На бумаге удобнее делать пометки. Причина оказалась банальной.

I>Т.е. вы эмулировали бумагой анализатор, что можно поделать

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

И что бы ты анализировал своим анализатором? Паша, ты в очередной раз занялся телепатией. Но как всегда телепалка твоя тебя же подвела.

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

I>Обычно первым делом проверяются все возможные зависимости и отрабатываются по одной. На 300 строк кода зависимостей просто не может быть очень много.

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Сколько тебе лет ?
Как это связано с темой разговора? Или это ты так к сливу своему постепенно привыкаешь?

I>У меня были похожие задачи, получалось решать их используя инструменты.

I>Вместо того, что бы эмулировать головой control flow, нужно проводить эксперименты, менять вход, ввододть логирование, пользоваться отладкой и тд.

Во-первых, выделенное -- глупость. Намного удобнее следить за control flow при помощи отладчика.
Головой можно же доказывать разные утверждения про код. При наличии достаточно заточенной под это головы, так быстрее и эффективнее искать некоторые сорта ошибок.
Если этот подход нов для тебя, в чём я не уверен, то советую начать с классической книжки Дейксры "Дисциплина программирования", или как-то так...

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

I>>Есть инструменты, которые облегчают просмотр и анализ кода.
AV>Вот только не всегда от них есть польза

Когда ты читаешь чего по бумажке, попробуй сформулировать, чем бы мог помочь инструмент а потом погугли

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

AV>Вах, вот только это помогло узнать что проблема есть. И ничего более.

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

Тестеры смоделировали — они что, по бумажке с кодом моделировали ?

I>>Это уже второй инструмент.

AV>От которого толку ноль. Я и без логов мог с достаточной точностью определить где проблема. Да, чуть больший кусок пришлось бы просмотреть, строк 400-500. Не более.

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

Зависимости имеют нелинейное влияние, ты в курсе ?

I>>Т.е. вы эмулировали бумагой анализатор, что можно поделать

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

AV>И что бы ты анализировал своим анализатором? Паша, ты в очередной раз занялся телепатией. Но как всегда телепалка твоя тебя же подвела.

Код разумеется.

I>>Обычно первым делом проверяются все возможные зависимости и отрабатываются по одной. На 300 строк кода зависимостей просто не может быть очень много.

AV>И обломился бы. Потому что проблема начиналась совсем в другом месте. И там ничего не изменить. А в проблемном месте две системы, из-за которых были проблемы, друг друга не трогают.

То есть те 300 строк что вы смотрели по бумаге, вам ничем не помогли ?

Попробуй сформулировать функции инструмента, который мог бы вам помочь и погугли

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

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

ну да, сократить окно с 500 до 300 строк — это бесполезно

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

E>Во-первых, выделенное -- глупость. Намного удобнее следить за control flow при помощи отладчика.

То есть, ты уже отказываешься от своих слов про бумажку ?

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

Пример приведи внятный.

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

E>>Во-первых, выделенное -- глупость. Намного удобнее следить за control flow при помощи отладчика.
I>То есть, ты уже отказываешься от своих слов про бумажку ?
Нет. Не отказался.

I>Пример приведи внятный.
Один я тебе привёл. Вот тебе другой. У тебя есть реализация формального какого-то алгоритма. Например он берёт RLE-изображение и замещает в нём каждый пиксель медианой квадрата 3Х3. И иногда он ошибается. Скажем данные, на которых ошибается, ты нашёл. Что делаешь дальше?

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

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

E>>>Во-первых, выделенное -- глупость. Намного удобнее следить за control flow при помощи отладчика.
I>>То есть, ты уже отказываешься от своих слов про бумажку ?
E>Нет. Не отказался.

I>>Пример приведи внятный.
E>Один я тебе привёл. Вот тебе другой. У тебя есть реализация формального какого-то алгоритма. Например он берёт RLE-изображение и замещает в нём каждый пиксель медианой квадрата 3Х3. И иногда он ошибается. Скажем данные, на которых ошибается, ты нашёл. Что делаешь дальше?

Дальше буду добавлять эти данные к юнит-тестам

Или RLE это нечто чего нельзя покрыть тестами ?

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

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

AV>>Вах, вот только это помогло узнать что проблема есть. И ничего более.

I>То есть тестеры моделировали наобум, просто от балды, или же сначала начл обламываться сервак а потом за это взялись тестеры ?

Нет, никто не обламывался.

I>Тестеры смоделировали — они что, по бумажке с кодом моделировали ?

Не в прямом смысле, но по бумажке.

I>>>Это уже второй инструмент.

AV>>От которого толку ноль. Я и без логов мог с достаточной точностью определить где проблема. Да, чуть больший кусок пришлось бы просмотреть, строк 400-500. Не более.

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

Нет, чуть больший. Потому что лишнее мы бы достаточно быстро отсекли бы. Потребовалось бы нам на это часа 5-6 человекочаса. По сравнению с остальным временем (под сотню человеко-часов) это не критично

I>>>Т.е. вы эмулировали бумагой анализатор, что можно поделать

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

AV>>И что бы ты анализировал своим анализатором? Паша, ты в очередной раз занялся телепатией. Но как всегда телепалка твоя тебя же подвела.

I>Код разумеется.

И что же ты получишь в результате этих анализов?

I>>>Обычно первым делом проверяются все возможные зависимости и отрабатываются по одной. На 300 строк кода зависимостей просто не может быть очень много.

AV>>И обломился бы. Потому что проблема начиналась совсем в другом месте. И там ничего не изменить. А в проблемном месте две системы, из-за которых были проблемы, друг друга не трогают.

I>То есть те 300 строк что вы смотрели по бумаге, вам ничем не помогли ?

Как раз смотрение строк и дало.

I>Попробуй сформулировать функции инструмента, который мог бы вам помочь и погугли

Давай, вперед, приводи инструменты. А я посмеюсь. Паша, ты переносишь свои случаи на всех остальных. И считаешь, что у других иначе и быть не может.

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

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

I>ну да, сократить окно с 500 до 300 строк — это бесполезно

Смотри выше.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Дальше буду добавлять эти данные к юнит-тестам

Чем это поможет? Есть у тебя компактная реализация алгоритма. Скорее всего конечного автомата. И что тебе дадут тесты?

I>Или RLE это нечто чего нельзя покрыть тестами ?
Польза-то в чём будет? Как ты найдёшь ошибку?

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

I>>Дальше буду добавлять эти данные к юнит-тестам

E>Чем это поможет? Есть у тебя компактная реализация алгоритма. Скорее всего конечного автомата. И что тебе дадут тесты?

Свалится конкретная функция.

I>>Или RLE это нечто чего нельзя покрыть тестами ?
E>Польза-то в чём будет? Как ты найдёшь ошибку?

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

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

I>Отваливается функция, если не плодить монстров по 200К кода, а ограничиваться десятком строк, то не надо ничего распечатывать и можно пользоваться дебуггером.

Описанное поведение кодируется небольшой одной единственной функцией...

Просто алгоритм, который она кодирует непрост.

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

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

AV>>>Вах, вот только это помогло узнать что проблема есть. И ничего более.
I>>То есть тестеры моделировали наобум, просто от балды, или же сначала начл обламываться сервак а потом за это взялись тестеры ?
AV>Нет, никто не обламывался.

Ты бы определился, умник. Сначала пишешь, что "на специально подобранном наборе данных сервак обламывался", а щас вот пишешь что сервер не обламывался

Короче, на ходу условие меняешь

I>>Тестеры смоделировали — они что, по бумажке с кодом моделировали ?
AV>Не в прямом смысле, но по бумажке.

работали ли они с распечаткой кода или нет ? Не пори чушь, только да или нет.

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

AV>Нет, чуть больший. Потому что лишнее мы бы достаточно быстро отсекли бы. Потребовалось бы нам на это часа 5-6 человекочаса. По сравнению с остальным временем (под сотню человеко-часов) это не критично

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

I>>>>Т.е. вы эмулировали бумагой анализатор, что можно поделать

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

I>>Код разумеется.

AV>И что же ты получишь в результате этих анализов?

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

I>>То есть те 300 строк что вы смотрели по бумаге, вам ничем не помогли ?

AV>Как раз смотрение строк и дало.

Что было в этих строчках ?

I>>Попробуй сформулировать функции инструмента, который мог бы вам помочь и погугли

AV>Давай, вперед, приводи инструменты. А я посмеюсь.

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

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

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

AV>>>>Вах, вот только это помогло узнать что проблема есть. И ничего более.
I>>>То есть тестеры моделировали наобум, просто от балды, или же сначала начл обламываться сервак а потом за это взялись тестеры ?
AV>>Нет, никто не обламывался.

I>Ты бы определился, умник. Сначала пишешь, что "на специально подобранном наборе данных сервак обламывался", а щас вот пишешь что сервер не обламывался

I>Короче, на ходу условие меняешь

Умник, ты бы читать научился, а не занимался придумыванием того чего нет. Там было написано:

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

Дальше не вижу смысла вести разговор. Ибо нет никакого желания вести как дон Кихот. Только вместо мельниц твои фантазии.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

O>Казалось бы — при чем тут скобки ?

Скобки действительно не при чем. За такой код — гнать сцаными тряпками.

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

I>Я обычный, а ты и для фона не годишься.

А что об этом думают Ваши наблюдатели?

VV>>Это называется "сила заднего ума".
I>Это инженерия. А "задний ум" есть гадание по бумажке.

Насколько квалифицированым разработчиком Вы себя считаете?

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

I>>Отваливается функция, если не плодить монстров по 200К кода, а ограничиваться десятком строк, то не надо ничего распечатывать и можно пользоваться дебуггером.

E>Описанное поведение кодируется небольшой одной единственной функцией...

E>Просто алгоритм, который она кодирует непрост.

Небольшая функция в сколько строчек кода ?

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

AV>Умник, ты бы читать научился, а не занимался придумыванием того чего нет. Там было написано:

Читай сам

ambel-vlad пишет:
Была у нас ситуация, когда на специально подобранном наборе данных сервак обламывался.

ambel-vlad пишет:
Нет, никто не обламывался.

AV>Дальше не вижу смысла вести разговор. Ибо нет никакого желания вести как дон Кихот. Только вместо мельниц твои фантазии.

Не пори чушь и прекращай истерику. Мне лично непонятно, как сервак мог обламывался и не обламывался

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

I>>Я обычный, а ты и для фона не годишься.

VV>А что об этом думают Ваши наблюдатели?

Ты видишь кого то, кого считаешь моим наблюдателем ?

VV>>>Это называется "сила заднего ума".
I>>Это инженерия. А "задний ум" есть гадание по бумажке.

VV>Насколько квалифицированым разработчиком Вы себя считаете?

Смотря в какой области. В той области, где сейчас работаю, примерно джуниор

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

VV>>А что об этом думают Ваши наблюдатели?
I>Ты видишь кого то, кого считаешь моим наблюдателем ?

Вы рассказывали, о ваших таинственных наблюдателях. Правда это было давно. Еще до того как Вас отправили в баню. Помните?

VV>>Насколько квалифицированым разработчиком Вы себя считаете?
I>Смотря в какой области. В той области, где сейчас работаю, примерно джуниор

Какая интрига! А почему бы Вам не рассказать поподробнее?

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

I>Небольшая функция в сколько строчек кода ?

Ну либо одна строчек в 50, либо 4 суммарной длиной под 100.

Здравствуйте, Игoрь, Вы писали:

И>namespace BlahBlahaBlah
И>{
И>    class BlahBlah
И>    {
И>        public void DoBlah(FlowDocument original)
И>        {
И>            var sourceRange = new TextRange(original.ContentStart, original.ContentEnd); // <-- 88 символов
И>        }
И>    }
И>}

namespace BlahBlahaBlah
{
    class BlahBlah
    {
        public void DoBlah(
            FlowDocument original)
        {
            var sourceRange =
                new TextRange(
                    original.ContentStart,
                    original.ContentEnd);
        }
    }
}

Читается как стихи Маяковского. Даже на мобильном телефоне.

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

VV>Вы рассказывали, о ваших таинственных наблюдателях. Правда это было давно. Еще до того как Вас отправили в баню. Помните?

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

VV>>>Насколько квалифицированым разработчиком Вы себя считаете?
I>>Смотря в какой области. В той области, где сейчас работаю, примерно джуниор

VV>Какая интрига! А почему бы Вам не рассказать поподробнее?

Уже давно рассказал

А почему тебе интриги и наблюдатели мерещатся ?

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

I>>Небольшая функция в сколько строчек кода ?

E>Ну либо одна строчек в 50, либо 4 суммарной длиной под 100.

И конечно же на части это никак нельзя побить ?

Покажи эту мега-функцию.

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

I>И конечно же на части это никак нельзя побить ?

Зачем?

I>Покажи эту мега-функцию.
Нет под рукой, кроме того код приватный, на самом деле.

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

Возможно секрет в том, что я учился на математика, правда в физическом вузе. И МНЕ так удобнее думать. Но МНЕ так удобнее. И таких же, как я довольно много...

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

I>>И конечно же на части это никак нельзя побить ?

E>Зачем?

Что бы протестировать по отдельности.

I>>Покажи эту мега-функцию.
E>Нет под рукой, кроме того код приватный, на самом деле.

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

E>Возможно секрет в том, что я учился на математика, правда в физическом вузе. И МНЕ так удобнее думать. Но МНЕ так удобнее. И таких же, как я довольно много...

Нахрена тратить время, если юниттест может показать место ошибки ?

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

AV>>Умник, ты бы читать научился, а не занимался придумыванием того чего нет. Там было написано:

I>Читай сам

I>ambel-vlad пишет:
I>Была у нас ситуация, когда на специально подобранном наборе данных сервак обламывался.

I>ambel-vlad пишет:
I>Нет, никто не обламывался.

Паша, сходи в нучальную школу. Чтобы тебя научили читать. И чтобы еще научили понимать прочитанное. Больше ничего тебе посоветовать не могу.

AV>>Дальше не вижу смысла вести разговор. Ибо нет никакого желания вести как дон Кихот. Только вместо мельниц твои фантазии.

I>Не пори чушь и прекращай истерику. Мне лично непонятно, как сервак мог обламывался и не обламывался

Перечитай еще раз. Специально ради интереса дал перечитать фразу из прошлого сообщения семерым. Итого, из общей выборки в восемь человек не понял написанного только один. Ты.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Нахрена тратить время, если юниттест может показать место ошибки ?

А кто покажет ошибку в тесте?
Мне кажется, что мы не понимаем друг друга.

Вот смотри. Рассмотрим упрощённую модельную задачу.
Пусть у меня есть структура

struct ImageStroke {
    enum { Sentinel = (WORD)-1 };
    
    WORD WhiteLength;
    WORD BlackLength;

    operator DWORD() const     //    для быстрых операций.
        { return ( DWORD( BlackLength ) << (sizeof(WhiteLength) * CHAR_BIT) ) | WhiteLength; }
    void IsSentenel() const;

    //    Возвращает {WhiteLength, BlackLength}, проверив корректность
    static ImageStroke Get( WORD WhiteLength, WORD BlackLength );

    //    Возвращает {Sentinel, Sentinel}
    static ImageStroke GetSentinel();    
};

Типа бинарное изображение. Каждый пиксель или чёрен или бел.
Строка такого изображения -- это последовательность ImageStroke последний из которых IsSentinel.
А картинка -- это размер по горизонтали и вертикали + указатель на массив штрихов, где сроки разделены штрихами, которые IsSentinel.

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

void HrzCompressTwiceKeepBlackStrokes( ImageStroke& dst, const ImageStroke &src, int linesCount = 1)

Так же для белых.
Это простые весьма функции.
Потом пишем функции посложнее. Типа

void VrtCompressTwiceKeepBlackStrokes( ImageStroke& dst, const ImageStroke &src, int linesCount = 1)

Эта функция посложнее потому, что ей надо бежать сразу по двум строкам исходника, и писать один выходной поток.
Ещё можно написать OR или AND двух строк, например.

Ну это вот всё хорошо покроется модульными тестами. Да.
А теперь пишем то, что покроется хуже: Пишем такую же функцию, которая сжимает по двум осям сразу. То есть каждый квадратик 2х2 заменяют на 1х1, и окрашивают в тот цвет, кого больше. А при равенстве в заданный. Например в чёрный. Или выбирают цвет так, чтобы в результате было меньше штрихов, или так, чтобы было меньше поверхностного шума и т. д. по твоему вкусу.
И вот на каком-то изображении получаем, что некоторые пикселы результата не того цвета. И что мы делаем дальше?

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

I>>ambel-vlad пишет:
I>>Нет, никто не обламывался.

AV>Паша, сходи в нучальную школу. Чтобы тебя научили читать. И чтобы еще научили понимать прочитанное. Больше ничего тебе посоветовать не могу.

Да, старая песня — стоит тебя попросить прояснить тобой же сказаное, как сразу жди взрыва бочки с говном

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

Следовательно, ты просто трепло, потому что вопрос был про то, где инструменты не помогают.

I>>Не пори чушь и прекращай истерику. Мне лично непонятно, как сервак мог обламывался и не обламывался

AV>Перечитай еще раз. Специально ради интереса дал перечитать фразу из прошлого сообщения семерым. Итого, из общей выборки в восемь человек не понял написанного только один. Ты.

Какая патетика

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

I>Мне кажется тут одно из двух, или ты гонишь, или тебе чего то мерещится

Хорошо, Вы уже приняли то, что Вам это кажется! Может быть у Вас за сегодня есть еще какие-нибудь успехи?

VV>>Какая интрига! А почему бы Вам не рассказать поподробнее?
I>Уже давно рассказал

А почему тебе интриги и наблюдатели мерещатся ?

Почему бы Вам не повторить?

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

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

I>>Мне кажется тут одно из двух, или ты гонишь, или тебе чего то мерещится

VV>Хорошо, Вы уже приняли то, что Вам это кажется!

Я просто все еще надеюсь, что медицина может помочь тебе, потому чуток сомневаюсь.

VV>>>Какая интрига! А почему бы Вам не рассказать поподробнее?
I>>Уже давно рассказал

А почему тебе интриги и наблюдатели мерещатся ?

VV>Почему бы Вам не повторить?

А ты что, уже научился читать ?

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

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

Дело в том, что корректная работа в частных случаях не гарантирует корректности алгоритма. Потому анализ алгоритма — единственный способ гарантированно добиться его корректной реализации в императивных языках. В махровой функциональщине, говорят можно автоматически проверить истинность программы, но мы про другие скобочки здесь — так?

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

VV>Дело в том, что корректная работа в частных случаях не гарантирует корректности алгоритма. Потому анализ алгоритма — единственный способ гарантированно добиться его корректной реализации в императивных языках. В махровой функциональщине, говорят можно автоматически проверить истинность программы, но мы про другие скобочки здесь — так?

Ну можно и так сформулировать. Я подозреваю, что коллега, когда говорил о покрытии модульными тестами имел в виду, что можно сделать такую систему тестов, что их прохождение гарантирует верность алгоритма. Но мы тогда получим рекурсивную задачу проверки правильности системы тестов. IMHO, она будет сложнее.

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

Так что если сам по себе код уже достаточно сложен для анализа и гарантий, то автоматическая проверка гарантий ещё сложнее будет.

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

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

Предлагаю отделить ветку и переехать в "философию" с темой вроде того: "[Бывают ли у программиста задачи, ]когда распечатка удобнее IDE?"

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

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

Ну с этим и спорить глупо. Как и с тем что инструментарий типа подсветок, подсказок и отладчиков позволяет многие из таких ошибок ловить практически не заморачиваясь. Я так понимаю, что разночтение в том является ли автоматическое тестирование панацеей или нет?

Умному ответ и так ясен

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

I>>Нахрена тратить время, если юниттест может показать место ошибки ?

E>А кто покажет ошибку в тесте?

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

E>И вот на каком-то изображении получаем, что некоторые пикселы результата не того цвета. И что мы делаем дальше?

Очевидно, юнит-тесты написаны коряво. Нужно фиксить юнит-тесты, они должны основываться на реальных данных.

Из деклараций функций мне например ничего не ясно.

Должен быть набор паттернов, на которых будут отрабатываться алгоритмы. Кроме того, нужен тул который будет подготавливать эти паттерны.

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

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

Предлагаю отделить ветку в "Всеобщий заговор в длины строк..."

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

I>>>ambel-vlad пишет:
I>>>Нет, никто не обламывался.

AV>>Паша, сходи в нучальную школу. Чтобы тебя научили читать. И чтобы еще научили понимать прочитанное. Больше ничего тебе посоветовать не могу.

I>Да, старая песня — стоит тебя попросить прояснить тобой же сказаное, как сразу жди взрыва бочки с говном

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

I>Следовательно, ты просто трепло, потому что вопрос был про то, где инструменты не помогают.

Как тебе заблагорассудится. Мне на это плевать.

I>>>Не пори чушь и прекращай истерику. Мне лично непонятно, как сервак мог обламывался и не обламывался

AV>>Перечитай еще раз. Специально ради интереса дал перечитать фразу из прошлого сообщения семерым. Итого, из общей выборки в восемь человек не понял написанного только один. Ты.

I>Какая патетика

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Предлагаю отделить ветку и переехать в "философию" с темой вроде того: "[Бывают ли у программиста задачи, ]когда распечатка удобнее IDE?"

Хорошая мысль

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

I>Не "можешь", а "умеешь".

Иногда "умеешь" слишком дорого стоит.
Пример 1. Оправляем два аппарата на Марс. Один, очень может быть, по сбою ПО теряет ориентацию и связь. Мы про него забываем. Но хотим побороться за второй. Наши действия?

Пример 2. Тестовый прогон -- это пуск ракеты, например. Или автоматическая посадка "Бурана"...

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

Пример 3. Мы разрабатываем ПО для вундер-вафли для доктора Зло. Зоктор Зло щедр, но если наше ПО подведёт его в боевой лихой час, он нас накормит своими яйцами, и внутренностями, и мы вообще очень даже обрадуемся когда наконец умрём. Вот в таких условиях лично ты ограничишься модульными тестами и рефакторилкой, или таки постараешься организовать вычитку кода с подробным анализом?

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

I>Следовательно, ты просто трепло, потому что вопрос был про то, где инструменты не помогают.

Ваш доктор не одобрил бы того, что Вы хамите людям посредством интернет. Вы уже приняли ваше лекарство?

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

E>Ну можно и так сформулировать. Я подозреваю, что коллега, когда говорил о покрытии модульными тестами имел в виду, что можно сделать такую систему тестов, что их прохождение гарантирует верность алгоритма. Но мы тогда получим рекурсивную задачу проверки правильности системы тестов. IMHO, она будет сложнее.

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

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

И заметь — про это уже было сказано.

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

I>Есть инструменты, которые облегчают просмотр и анализ кода.

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

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

I>Когда ты читаешь чего по бумажке, попробуй сформулировать, чем бы мог помочь инструмент а потом погугли

Нужно построить формальное и верифицируемое доказательство корректности кода. Погугли, пожалуйста, сам?

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

I>Максимум — фетиш который помогает сменить обстановку и отдохнуть.

Кстати, лично мне, иногда бывает полезно во время раздумий над проблемами курить. А на рабочем месте сейчас в РФ это а-та-та, например...

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

Это я не про поиск багов, а вообще про разное. Ну вот положим стоит у тебя в плане фича "улучшить качество распознавания тайского языка на 25%"...
Задачи такого рода свистелками вроде VAX и подсветка не решаются

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

I>>Да, старая песня — стоит тебя попросить прояснить тобой же сказаное, как сразу жди взрыва бочки с говном

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

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

Ты же раз за разом демонстрируешь одно и то же — стоит указать на нестыковку в твоих слова, как начинаешь заламывать руки, стенать и срать кирпичами.

Вобщем ты таки попробуй взять себя в руки и объяснить, как это сервер обламывался-необламывался и какое отношение имели к этому тестеры.

Ты, VV и Егор утверждаете что случаев хватает но так и не привели внятный пример. Даже описать не можете, чего же с кодом то делаете, что бы проблему найти. Какая то мутная полуинтуитивная отсебятина.

У меня, кстати говоря, были случаи когда нужно было сидеть над простынями с кодом — когда инструментов вообще не было. Даже компьютера

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

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

VV>Я так понимаю, что разночтение в том является ли автоматическое тестирование панацеей или нет?
Дык, блин, давно же известно, что нет никакой серебряной ложки, в смысле пули!

VV>Умному ответ и так ясен

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

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

E>Иногда "умеешь" слишком дорого стоит.
E>Пример 1. Оправляем два аппарата на Марс. Один, очень может быть, по сбою ПО теряет ориентацию и связь. Мы про него забываем. Но хотим побороться за второй. Наши действия?

Начинать анализ системы

Для анализа кода лучше брать не бумагу, а Code Collaborator например, ибо известно — две головы лучше одной.

E>Пример 2. Тестовый прогон -- это пуск ракеты, например. Или автоматическая посадка "Бурана"...

E>Соответственно, ваши действия по предотвращению сбоя ПО на боевом прогоне? Запуск пары сотен тестовых устройств? Или таки подробный анализ когда стоит включить?

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

E>Пример 3. Мы разрабатываем ПО для вундер-вафли для доктора Зло. Зоктор Зло щедр, но если наше ПО подведёт его в боевой лихой час, он нас накормит своими яйцами, и внутренностями, и мы вообще очень даже обрадуемся когда наконец умрём. Вот в таких условиях лично ты ограничишься модульными тестами и рефакторилкой, или таки постараешься организовать вычитку кода с подробным анализом?

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

При этом бумажка с кодом для анализа лучше только отсутствия инструментов.

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

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

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

Ты до сих пор не дал нормального примера

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

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

I>>Следовательно, ты просто трепло, потому что вопрос был про то, где инструменты не помогают.

VV>Ваш доктор не одобрил бы того, что Вы хамите людям посредством интернет. Вы уже приняли ваше лекарство?

Это ты по себе судишь ? Если доктор нужен тебе, не значит что и другим он нужен.

Кстати, на счет бумаги. Ты в курсе, что это один из симптомов ! Расскажи подробно, что ты с этой бумагой делаешь ?

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

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

И часто ты гуляешь месяцами что бы решить задачу ?

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

Я и говорю — каменный век

E>Это я не про поиск багов, а вообще про разное. Ну вот положим стоит у тебя в плане фича "улучшить качество распознавания тайского языка на 25%"...
E>Задачи такого рода свистелками вроде VAX и подсветка не решаются

Конечно не решаются. При этом от бумаги с кодом толку еще меньше будет, потому что для таких дел есть специальные инструменты.

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

VV>>Умному ответ и так ясен

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

Очень сомневаюсь, что он может выдать что-то сакральное. Если бы такое знание было — он бы его выдал уже давно. Хотя я буду рад ошибиться.

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

А как у Вас с соблюдением режима? Вы сегодня зарядку делали?

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

I>>>Нахрена тратить время, если юниттест может показать место ошибки ?

E>>А кто покажет ошибку в тесте?
I>Тесты если уметь ими пользоваться, получаются очень простыми.

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

E>>И вот на каком-то изображении получаем, что некоторые пикселы результата не того цвета. И что мы делаем дальше?
I>Очевидно, юнит-тесты написаны коряво. Нужно фиксить юнит-тесты, они должны основываться на реальных данных.
Это я не понял. Что такое "реальные данные" для библиотеки обработки изображений?

I>Из деклараций функций мне например ничего не ясно.
Упс, я ошибся. Правильно, конечно же так:

void HrzCompressTwiceKeepBlackStrokes( ImageStroke*& dst, ImageStroke const* &src, int linesCount = 1)

Мы берём в src ссылку на указатель на строки. Вычитываем оттуда linesCount строк, и помещаем в параметр указатель за эти строки.
А в dst записывае результат, и сам dst передвигаем за результат.

I>Должен быть набор паттернов, на которых будут отрабатываться алгоритмы. Кроме того, нужен тул который будет подготавливать эти паттерны.
Ну пусть всё это есть. Тем более это не сложно устроить. Просто файлы с BMP, например. Правда ещё код конверсии BMP в RLE придётся написать.

I>Поначалу работы много, зато позже ты сможешь модифицировать, оптимизировать и тд, без страха застрять на недели в дебаге.
I>А если ты просто взял и нахерачил функцию на 100 строчек, кто ж тебе доктор ?

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

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

Попробуй объяснить на примере этой задачи твою методу?

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

VV>А как у Вас с соблюдением режима? Вы сегодня зарядку делали?

Думаешь это как то коррелирует с твоими мыслями ?

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

VV>>А как у Вас с соблюдением режима? Вы сегодня зарядку делали?
I>Думаешь это как то коррелирует с твоими мыслями ?

Вам кажется, что Вы можете читать мои мысли?

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

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

I>И заметь — про это уже было сказано.

А мне вот бумажка с распечаткой помогает как раз. Возможно именно потому, что это ФОРМАЛЬНОЕ представление алгоритма, и я УМЕЮ с ним работать на бумажке. Тоже формально. Если мне надо что-то проверить потом с компом, по результатам раздумий с бумажкой, то нет проблем. Комп-то не выброшен...
Один и простых примеров такого сценария -- это мы курим бумажку и понимаем какие инварианты каких циклов хорошо бы проверить. И если они ещё не проверяются в коде, то расставляем asserts и делаем прогон...

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

E>>Пример 1. Оправляем два аппарата на Марс. Один, очень может быть, по сбою ПО теряет ориентацию и связь. Мы про него забываем. Но хотим побороться за второй. Наши действия?

I>Начинать анализ системы
IMHO, в таких условиях НАЧИНАТЬ анализ как-то поздновато. Я, например, в аналогичных обстоятельствах обычно знаю несколько мест, которые надо срочно пристально курить.

I>

Для анализа кода лучше брать не бумагу, а Code Collaborator например, ибо известно — две головы лучше одной.
Кому как. Это всего лишь вопрос, как организовать коллективную работу. Почему ты считаешь что именно Code Collaborator лучше всего? Я бы, например, быстренько бы обсудил с теми, кто в теме, что надо проанализировать, а потом раздал бы куски для анализа по людям...

E>>Пример 2. Тестовый прогон -- это пуск ракеты, например. Или автоматическая посадка "Бурана"...

E>>Соответственно, ваши действия по предотвращению сбоя ПО на боевом прогоне? Запуск пары сотен тестовых устройств? Или таки подробный анализ когда стоит включить?

I>Не валяй дурку. От тебя требуется обосновать необходимость необходимость бумажки с кодом для анализа оных алгоритмов.
Дык я вот и обосновываю. Как ты предлагаешь снизить число неудачных прогонов? Я знаю проверенный десятилетиями способ -- анализ кода на бумажке. Вернее модернизированную версию. Сначала полуавтоматические инструменты позволяют выделить критические куски, а потом анализ этих кусков на бумажке. На бумажке потому, что удобно писать на полях

I>Я привел гораздо больше инструментов, нежели тесты и рефакторинг, например логи, профайлер, отладчик, анализатор кода и тд и тд.
И как же всё это поможет нам в одном из трёх приведённых случаев?

I>Но я сильно уверен, что ты через сообщение снова будешь рассказывать мне, что я де тесты назвал панацеей. Это один из твоих любимых приемов.
Разве это я про панацею написал?

Ссылочку привести не затруднит?

Но я предлагаю не распыляться, и показать мастер-класс на модельной задаче

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

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

I>Ты до сих пор не дал нормального примера

Уже два дал.
1) Взрыв QSort
2) Сжатие по двум осям RLE картинки

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

I>И часто ты гуляешь месяцами что бы решить задачу ?
Ради сложный и годами бывает гуляю. Именно потому разработки моей группы опережают мировой уровень...

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

I>Я и говорю — каменный век

Ну а ты расскажи, как будет, если некаменный?

I>Конечно не решаются. При этом от бумаги с кодом толку еще меньше будет,
Почему это, обязательно с кодом? С материалами по задаче. Если задача про код, то с кодом, а если про что-то другое, с этим самым другим...

I>потому что для таких дел есть специальные инструменты.
Какие? Не поделишься?

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

I>>И заметь — про это уже было сказано.

E>А мне вот бумажка с распечаткой помогает как раз. Возможно именно потому, что это ФОРМАЛЬНОЕ представление алгоритма, и я УМЕЮ с ним работать на бумажке. Тоже формально.

Есть такие люди, которые без бумаги жить не могут

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

VV>Очень сомневаюсь, что он может выдать что-то сакральное. Если бы такое знание было — он бы его выдал уже давно. Хотя я буду рад ошибиться.

Я сторонник корректного конструктивного обсуждения проблем.

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

I>Есть такие люди, которые без бумаги жить не могут

Я верно понял, что конструктива не последует?

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

E>Я сторонник корректного конструктивного обсуждения проблем.

Имхо вы давно сошли на обсуждение личных предпочтений. А на вкус и цвет...

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

I>>Начинать анализ системы
E>IMHO, в таких условиях НАЧИНАТЬ анализ как-то поздновато. Я, например, в аналогичных обстоятельствах обычно знаю несколько мест, которые надо срочно пристально курить.

А это по твоему не анализ, да ?

I>>

Для анализа кода лучше брать не бумагу, а Code Collaborator например, ибо известно — две головы лучше одной.
E>Кому как. Это всего лишь вопрос, как организовать коллективную работу. Почему ты считаешь что именно Code Collaborator лучше всего? Я бы, например, быстренько бы обсудил с теми, кто в теме, что надо проанализировать, а потом раздал бы куски для анализа по людям...

По бумажке каждому, да ?

Code Collaborator нужен если две части тимы в разных странах сидят например.

I>>Не валяй дурку. От тебя требуется обосновать необходимость необходимость бумажки с кодом для анализа оных алгоритмов.
E>Дык я вот и обосновываю. Как ты предлагаешь снизить число неудачных прогонов? Я знаю проверенный десятилетиями способ -- анализ кода на бумажке. Вернее модернизированную версию. Сначала полуавтоматические инструменты позволяют выделить критические куски, а потом анализ этих кусков на бумажке. На бумажке потому, что удобно писать на полях

Опаньки, оказывается, как и у AV, нужны какие то полуавтоматические инструменты, что бы бумажка начала помогать

Т.е. бумажка уже не является необходимым условием

Ты сам то понял, что сказал ?

Прямо как в анекдоте — газетку подстели, что бы выше быть. Вобщем? предлагаю завершить ?

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

VV>Имхо вы давно сошли на обсуждение личных предпочтений. А на вкус и цвет...

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

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

VV>>>А как у Вас с соблюдением режима? Вы сегодня зарядку делали?
I>>Думаешь это как то коррелирует с твоими мыслями ?

VV>Вам кажется, что Вы можете читать мои мысли?

А про чтение ничего и не было

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

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

I>>Тесты если уметь ими пользоваться, получаются очень простыми.
E>Ну покажи на модельной задаче, как надо делать. AFAIK, тесты получаются простыми, только в задачах с простой спецификацией.

Я пока еще задачу то не видел. Или ты хочешь, что бы я написал и алгоритм, и тесты и конвертеры ?

E>>>И вот на каком-то изображении получаем, что некоторые пикселы результата не того цвета. И что мы делаем дальше?
I>>Очевидно, юнит-тесты написаны коряво. Нужно фиксить юнит-тесты, они должны основываться на реальных данных.
E>Это я не понял. Что такое "реальные данные" для библиотеки обработки изображений?

Изображения из тех которые надо обрабатывать.

I>>Из деклараций функций мне например ничего не ясно.
E>Упс, я ошибся. Правильно, конечно же так:

void HrzCompressTwiceKeepBlackStrokes( ImageStroke*& dst, ImageStroke const* &src, int linesCount = 1)

Мы берём в src ссылку на указатель на строки. Вычитываем оттуда linesCount строк, и помещаем в параметр указатель за эти строки.
E>А в dst записывае результат, и сам dst передвигаем за результат.

Думаешь это перестало быть декларацией ?

I>>Поначалу работы много, зато позже ты сможешь модифицировать, оптимизировать и тд, без страха застрять на недели в дебаге.
I>>А если ты просто взял и нахерачил функцию на 100 строчек, кто ж тебе доктор ?

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

Что значит сложные, в алгоритме ? Так здесь вообще код не помощник. Юнит-тесты строятся когда алгоритм известен.

E>Вот ты написал, что надо разбить сложную функцию на простые и всё починится.

Не починится. Нужно что бы каждая функция тестировалась.

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

E>Попробуй объяснить на примере этой задачи твою методу?

Какой этой задачи ? Я пока что не видел задачи, только кусочки деклараций.

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

E>Уже два дал.
E>1) Взрыв QSort
E>2) Сжатие по двум осям RLE картинки

В одном тебе пояснил CreatorCray, в другом ты сам признался что необходимы полуавтоматические средства для того, что бы бумажка заработала.

Был ще пример у AV, он тоже дошел до логирования и привлечения тестеров

Вот тебе простой пример — около 100кб кода на ассемблере, эмулятора нет, комп один на троих-четверых, разрабатываемая станция одна на несколько секторов, отладчика нет, вывода в консоль, дампов, логов — ничего нет. Все что есть — светодиоды на задней панели станции, схема тестируемого блока.

Вот это тот случай, где нужна распечатка, что бы не курить бамбук, пока нет ни компа ни станции.

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

I>>Есть такие люди, которые без бумаги жить не могут

E>Я верно понял, что конструктива не последует?

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

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

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

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

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

I>>И часто ты гуляешь месяцами что бы решить задачу ?
E>Ради сложный и годами бывает гуляю. Именно потому разработки моей группы опережают мировой уровень...

Может конкурентов не шибко много ? Я ж не в курсе деталей.

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

I>>Я и говорю — каменный век

E>Ну а ты расскажи, как будет, если некаменный?

Некаменный это компьютер. Я ж говорил — бумага это только симптом, когда нужен повод отдохнуть

I>>Конечно не решаются. При этом от бумаги с кодом толку еще меньше будет,
E>Почему это, обязательно с кодом? С материалами по задаче. Если задача про код, то с кодом, а если про что-то другое, с этим самым другим...

Потому что изначально речь шла про бумажку с кодом.

I>>потому что для таких дел есть специальные инструменты.
E>Какие? Не поделишься?

Средтсва моделирования, вычисления, визуализации и тд

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

I>>>Думаешь это как то коррелирует с твоими мыслями ?
VV>>Вам кажется, что Вы можете читать мои мысли?
I>А про чтение ничего и не было

То есть Вы признаете, что не можете их читать?

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

E>>IMHO, в таких условиях НАЧИНАТЬ анализ как-то поздновато. Я, например, в аналогичных обстоятельствах обычно знаю несколько мест, которые надо срочно пристально курить.
I>А это по твоему не анализ, да ?
По моему это не соответсвует термину "НАЧИНАТЬ"...

I>По бумажке каждому, да ?

Code Collaborator нужен если две части тимы в разных странах сидят например.
По вопросу/куску кода каждому. Способ коммуникации -- это один вопрос, а инструмент для анализа -- другой.

I>Опаньки, оказывается, как и у AV, нужны какие то полуавтоматические инструменты, что бы бумажка начала помогать

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

I>Т.е. бумажка уже не является необходимым условием

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

I>Прямо как в анекдоте — газетку подстели, что бы выше быть. Вобщем? предлагаю завершить ?
Ну если тебе больше нечего по существу сказать, то да, наверное.

А так я всё ещё жду мастер-класса..
Можно в отдельной ветке, например. И в другом форуме.
Только тут ссылку дай, пожалуйста.

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

I>Я пока еще задачу то не видел. Или ты хочешь, что бы я написал и алгоритм, и тесты и конвертеры ?

Ну это же модельная задача? Довольно простая.
Я так тебя понял что можно распилить одну сложную функцию на много простых и тогда тесты смогут ГАРАНТИРОВАТЬ правильность кода.
Вот и покажи как распилить. Если тебе трудно написать функцию, которую надо пилить, то я сам могу её написать. Просто я не думаю, что это сложно как-то очень, и, насколько я тебя понял, код самой монолитной функции не нужен, так как ты всё равно предлагаешь её переписать.

E>>Это я не понял. Что такое "реальные данные" для библиотеки обработки изображений?
I>Изображения из тех которые надо обрабатывать.
Ну ты понимаешь, что такое "библиотека"? Нужно уметь обрабатывать ЛЮБЫЕ картинки. Ну я бы, например, выбрал несколько штриховок и случайных заполнений, картинки какие-нибудь, буквы из растризованных шрифтов, тексты, ну скриншоты можно попробовать...

I>Думаешь это перестало быть декларацией ?

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

I>Что значит сложные, в алгоритме ? Так здесь вообще код не помощник. Юнит-тесты строятся когда алгоритм известен.
Ну в общем случае ты не знаешь где у тебя ошибка в алгоритме или в реализации. Надо гарантировать работоспособность ПО, то есть выявить ошибки и там и там.

I>Не починится. Нужно что бы каждая функция тестировалась.
Ну это понятно. Но проблема не в этом.

I>Какой этой задачи ? Я пока что не видел задачи, только кусочки деклараций.

Ну что тебе не понятно? Представление картинки понятно? Если нет, то задавай вопросы.

Если представление понятно, то задача сформулирована формально. Пишем функцию, которой на вход даём картинку 2N x 2M, а на выходе хотим картинку N x M. При этом исходную картинку разбиваем на клетки 2х2 пиксела и вместо каждой клетки в результат пишем тот цвет, которых в клетки больше.
Если в клетке чёрных и белых по 2, то можешь сам выбрать, что делаем в этом случае.
Варианты:
1) Пишем чёрное
2) Выбираем такой цвет, чтобы в результате было как можно меньше смен чёрного белым
3) Выбираем такой цвет, чтобы в результате былоо как можно меньше поверхностного шума
4) Выбираем цвет в соответствии с каким-то паттерном заполнения. Например так, чтобы из "шахматной доски" в результате тоже получилась "шахматная доска"

В этой постановке задачи что-то не понятно?

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

I>В одном тебе пояснил CreatorCray,
Чего?
Что-то он мне ничего не пояснил.

I>в другом ты сам признался что необходимы полуавтоматические средства для того, что бы бумажка заработала.
Зачем? Я вроде как формально описал постановку задачи без автоматических и полуавтоматических средств. IMHO и для её решения они не нужны. Во всяком случае МНЕ...
Но я так понял, что ты владеешь каким-то методами, которыми я не владею. Ну так покажи же наконец всю мощь своего кунг-фу?

I>Вот тебе простой пример — около 100кб кода на ассемблере, эмулятора нет, комп один на троих-четверых, разрабатываемая станция одна на несколько секторов, отладчика нет, вывода в консоль, дампов, логов — ничего нет. Все что есть — светодиоды на задней панели станции, схема тестируемого блока.

I>Вот это тот случай, где нужна распечатка, что бы не курить бамбук, пока нет ни компа ни станции.

Ну и этот случай тоже. И что?

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

I>Ты сам все сделал, когда рассказал про необходимость полуавтоматических инструментов

Это РАЗНЫЕ этапы. Предварительная локализация баги -- полуавтоматические инструменты, логи и т. д.
Поиск и исправление сложного бага в предварительно локализованном куске -- бумажка...

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

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

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

Те, кому интересно, могут пойти работать в какую-нибыдь подходящую организацию. Например в "Алмаз-Антей", или как оно там зовётся?
Но интересны и более открытые варианты...

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

I>Может конкурентов не шибко много ? Я ж не в курсе деталей.
Ну у лидера всегда немного конкурентов. Один-два, обычно. Остальные глубоко позади.
Вот сравни, например, с ситуацией у MS на рынке OS...

Или с космической программой СССР и США

I>Некаменный это компьютер. Я ж говорил — бумага это только симптом, когда нужен повод отдохнуть

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

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

I>Средтсва моделирования, вычисления, визуализации и тд
Поконркетнее не расскажешь? Вот, например, у нас стоит задача, поднять качество распознавания тайского языка. Какие инструменты будем юзать?

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

I>Ты, VV и Егор утверждаете что случаев хватает но так и не привели внятный пример. Даже описать не можете, чего же с кодом то делаете, что бы проблему найти. Какая то мутная полуинтуитивная отсебятина.

Я в сложных случаях начинаю строить формальное доказательство кода.

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

E>Это РАЗНЫЕ этапы. Предварительная локализация баги -- полуавтоматические инструменты, логи и т. д.
E>Поиск и исправление сложного бага в предварительно локализованном куске -- бумажка...

Если кусок локализован, то не ясно, для чего бумажка

E>Никто не анализирует на бумажке полный код системы на несколько миллионов строк. А вот какие-то критические участки, со сложными алгоритмами -- очень даже

Какое преимущество у бумажки перед редактором кода тем же ?

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

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

E>Слушай, а как ты ищешь ошибки в алгоритмах? Какое формальное представление алгоритма используешь и какими инструментами пользуешься?

Рисую алгоритм на бумаге

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

I>>Некаменный это компьютер. Я ж говорил — бумага это только симптом, когда нужен повод отдохнуть

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

Ты не увиливай — бумага это одно, а распечатка кода — совсем другое.

I>>Средтсва моделирования, вычисления, визуализации и тд
E>Поконркетнее не расскажешь? Вот, например, у нас стоит задача, поднять качество распознавания тайского языка. Какие инструменты будем юзать?

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

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

I>Если кусок локализован, то не ясно, для чего бумажка

Ну, например, локализован точностью до стони строк. Скажем, что такой-то алгоритм, вернее такая-то его реализация работает не так, как ожидалось.
Что делаем дальше?

I>Какое преимущество у бумажки перед редактором кода тем же ?
Возможность легко писать, чиркать, рисовать...

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

E>>Слушай, а как ты ищешь ошибки в алгоритмах? Какое формальное представление алгоритма используешь и какими инструментами пользуешься?
I>Рисую алгоритм на бумаге

Что значит "рисую алгоритм"? Блок-схему? Пример привести можешь?
IMHO, запись на ЯП намного лучше блок-схемы.

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

I>Ты не увиливай — бумага это одно, а распечатка кода — совсем другое.
Важное свойство распечатки то, что на ней легко рисовать и писать.

I>Я на распознавании не специализируюсь. Но сильно сомневаюсь, что качество распознавания можно поднять распечатывая код на бумагу.
Распечатывать код надо не для этого. А для нетривиального анализа кода.

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

I>>В одном тебе пояснил CreatorCray,
E>Чего?
E>Что-то он мне ничего не пояснил.

Вероятно ты просто не понял его объяснения

I>>в другом ты сам признался что необходимы полуавтоматические средства для того, что бы бумажка заработала.
E>Зачем? Я вроде как формально описал постановку задачи без автоматических и полуавтоматических средств. IMHO и для её решения они не нужны. Во всяком случае МНЕ...

Естественно, для решения задачи нужна голова, а инструменты нужны для того, что бы голова была занята исключительно решением

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

E>Но я так понял, что ты владеешь каким-то методами, которыми я не владею. Ну так покажи же наконец всю мощь своего кунг-фу?

Нет никакой панацеи.

Юниттестами обнаруживаются ошибки в реализации алгоритма. Ошибки в алгоритме юниттестами могут обнаруживаться, но как правило это слишком дорогой способ, работает когда у тебя есть всякие эталоны.

А вот если эталонов нет или получение их дело достаточно дорогое, то вообще код тебе ну никак не поможет.

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

I>>Вот тебе простой пример — около 100кб кода на ассемблере, эмулятора нет, комп один на троих-четверых, разрабатываемая станция одна на несколько секторов, отладчика нет, вывода в консоль, дампов, логов — ничего нет. Все что есть — светодиоды на задней панели станции, схема тестируемого блока.

I>>Вот это тот случай, где нужна распечатка, что бы не курить бамбук, пока нет ни компа ни станции.

E>Ну и этот случай тоже. И что?

Вот тебе "и что" — бумажка с распечаткой не заменяет инструмент, а заменяет отсутствие инструмента. Но если у тебя есть комп и анализировать код вдруг необходимо на бумаге — это мягко говоря чтото странное. Я уже говорил, что это максимум фетиш.

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

E>А мне вот бумажка с распечаткой помогает как раз. Возможно именно потому, что это ФОРМАЛЬНОЕ представление алгоритма, и я УМЕЮ с ним работать на бумажке. Тоже формально. Если мне надо что-то проверить потом с компом, по результатам раздумий с бумажкой, то нет проблем. Комп-то не выброшен...
E>Один и простых примеров такого сценария -- это мы курим бумажку и понимаем какие инварианты каких циклов хорошо бы проверить. И если они ещё не проверяются в коде, то расставляем asserts и делаем прогон...

Я бы перед тем, как писать такой текст, сначала спросил бы Ikemefula, знает ли он, что такое инварианты циклов

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

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

I>Вот тебе простой пример — около 100кб кода на ассемблере, эмулятора нет, комп один на троих-четверых, разрабатываемая станция одна на несколько секторов, отладчика нет, вывода в консоль, дампов, логов — ничего нет. Все что есть — светодиоды на задней панели станции, схема тестируемого блока.

I>Вот это тот случай, где нужна распечатка, что бы не курить бамбук, пока нет ни компа ни станции.

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

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

I>>>>Думаешь это как то коррелирует с твоими мыслями ?
VV>>>Вам кажется, что Вы можете читать мои мысли?
I>>А про чтение ничего и не было

VV>То есть Вы признаете, что не можете их читать?

Тебе всё еще кажется что я говорил про чтение ?

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

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

Pzz>Интересно, если автоматические инструменты есть для всего, зачем человек-то при них нужен?

Ну как же, а кто будет нажимать кнопку мыши чтобы автоматические инструменты начали работать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Вероятно ты просто не понял его объяснения

Вероятно оно было не понятно сформулировано. Я от него ничего лучше, чем "заюзай дебагер" не услышал.
IMHO, конкретно для отладки взрыва QSort это плохая идея...

Но ты можешь пояснить его идеи, если ты их понимаешь...

I>Если ты ждешь, что я покажу тебе инструмент, который решает дифуры и уравнения новье-стокса то стоит несколько умерить ожидания.
Я придумал тебе модельную задачу. Если она тебе не подходит -- предложи свою.
Так что, просим, мастер! Просим!

E>>Но я так понял, что ты владеешь каким-то методами, которыми я не владею. Ну так покажи же наконец всю мощь своего кунг-фу?

I>Нет никакой панацеи.
Разве речь о панацеи? Я предложил задачку, в которой, по моему мнению, будут полезны распечатки. Ты, можешь показать, как сделать лучше и без бумажек...

I>Юниттестами обнаруживаются ошибки в реализации алгоритма. Ошибки в алгоритме юниттестами могут обнаруживаться, но как правило это слишком дорогой способ, работает когда у тебя есть всякие эталоны.
Не вопрос, ф топку юнит-тесты.

Речь тут не о них!!!

I>А вот если эталонов нет или получение их дело достаточно дорогое, то вообще код тебе ну никак не поможет.
Странно, а мне вот помогает.

I>Хоть ты целый грузовик бумаги распечатай, толку не будет.
А у меня вот есть. Наверное я знаю что печатать, и что потом сделать с распечатками.
Хинт: методика Вуду со сжиганием и вымарыванием багов не работает

E>>Ну и этот случай тоже. И что?

I>Вот тебе "и что" — бумажка с распечаткой не заменяет инструмент, а заменяет отсутствие инструмента.
Странно. А у меня вот не заменяет, а дополняет... Работа с распечаткой проблемного кода -- это тоже инструмент...

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

I>Я уже говорил, что это максимум
Это хорошо бы ещё и доказать как-то. Особенно то, что "максимум"...

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

Pzz>>Интересно, если автоматические инструменты есть для всего, зачем человек-то при них нужен?

AV>Ну как же, а кто будет нажимать кнопку мыши чтобы автоматические инструменты начали работать?

Автоматический нажиматель на кнопку мыши?

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

Pzz>Я бы перед тем, как писать такой текст, сначала спросил бы Ikemefula, знает ли он, что такое инварианты циклов

Специалиста учить -- только портить!

Лучше пусть мастер-класс даст. А то вдруг он Дейкстру таки почитает и утратит своё кунг-фу. А я его так и не посмотрю...

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

Pzz>Интересно, если автоматические инструменты есть для всего, зачем человек-то при них нужен?

Как зачем? Применять нужный инструмент нужным способом...

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

I>Если ты ждешь, что я покажу тебе инструмент, который решает дифуры и уравнения новье-стокса то стоит несколько умерить ожидания.

Это, кстати, как раз не проблема...

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

I>>Если кусок локализован, то не ясно, для чего бумажка

E>Ну, например, локализован точностью до стони строк. Скажем, что такой-то алгоритм, вернее такая-то его реализация работает не так, как ожидалось.
E>Что делаем дальше?

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

I>>Какое преимущество у бумажки перед редактором кода тем же ?
E>Возможность легко писать, чиркать, рисовать...

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

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

Код это всегда и везде зависимости, которые нужно отрабатывать.

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

Если же зависимостей не будет или количество будет некритичным, то задача сводится к функции и решается через тестирование.

И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.

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

E>>>Слушай, а как ты ищешь ошибки в алгоритмах? Какое формальное представление алгоритма используешь и какими инструментами пользуешься?
I>>Рисую алгоритм на бумаге

E>Что значит "рисую алгоритм"? Блок-схему? Пример привести можешь?
E>IMHO, запись на ЯП намного лучше блок-схемы.

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

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

I>>Ты не увиливай — бумага это одно, а распечатка кода — совсем другое.
E>Важное свойство распечатки то, что на ней легко рисовать и писать.

А без распечатки нельзя что ли рисовать и писать ? У меня вот получается

I>>Я на распознавании не специализируюсь. Но сильно сомневаюсь, что качество распознавания можно поднять распечатывая код на бумагу.
E>Распечатывать код надо не для этого. А для нетривиального анализа кода.

Не надо для этого печатать код

код это всегда зависимости, которые можно и нужно отрабатывать.

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

В софте даже спящие процессы вроде while(true) Sleep(1000); влияют друг на друга

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

E>>Ну, например, локализован точностью до стони строк. Скажем, что такой-то алгоритм, вернее такая-то его реализация работает не так, как ожидалось.
E>>Что делаем дальше?

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

Но давай вернёмся к нашим примерам.
1) Взрыв QSort'а.
Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
Данные -- массив чисел типа double.
Что делаем дальше?

2) Сжатие RLE картинки. Опять же замкнутый в себе алгоритм. Чё за зависимости нам надо выявить?

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

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

I>Код это всегда и везде зависимости, которые нужно отрабатывать.
Ну покажи это на моих примерах. Я же давно у тебя мастер-класс прошу...

I>А это значит, что даже если у тебя есть 300 проблемных строк, то у них гарантировано будут зависимости от других модулей.
Нифига это не так. Это только в задачах типа "GUI-клей между разными моторами" так всегда. А если у тебя какой-то нетривильный алгоритм реализован, то пофигу зависимости обычно.

I>Если же зависимостей не будет или количество будет некритичным, то задача сводится к функции и решается через тестирование.
Ну покажи как оно решается-то?

I>И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.
Никак. Она нужна для другого. Для статического анализа алгоритма, представленного в виде распечатанного кода. Например, для доказательства его правильности, либо выявления условий, при которых правильность таки можно гарантировать...

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

I>Рисуешь как тебе удобно. Я бы из блокнота отсканировал, но нет у меня сканера под рукой. Иногда удобно вместо рисования таблички заполнть. Иногда даже псевдокод писать.

Что за таблички?
В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?

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

E>Лучше пусть мастер-класс даст. А то вдруг он Дейкстру таки почитает и утратит своё кунг-фу. А я его так и не посмотрю...

А вот интересно. Нам, с практической точки зрения, не обязательно иметь строгое доказательство работы того или иного алгоритма (да и невозможно его получить, поскольку доказательство само может содержать ошибки). Нам достаточно знать, что алгоритм верен с определенной вероятностью. Скажем, если вероятность ошибки меньше, чем 2^-128, то с практической точки зрения это то же самое, что 100%-верный алгоритм; вероятность сбоя аппаратуры значительно выше (причем даже принебрегая ошибками в аппаратуре — просто вероятность сбоя от того, что битик в регистре переключится сам собой из-за теплового шума).

В связи с этим возникает забавный философический вопрос: можно ли так покрыть программу тестами, чтобы уменьшить вероятность ошибок до заданного уровня (естественно, имея ввиду вероятность ошибок в полном комплекте, программа+тесты). Или, более частный вопрос, можно ли быть уверенным, что от добавления очередного теста совокупная вероятность ошибок уменьшается? Насколько быстро она уменьшается? Можно ли проектировать тесты не от фонаря, а чтобы вероятность ошибок уменьшалась быстро? Будет ли это более или менее трудоемко, чем строгое доказательство? Если нанять миллион индусов, что будет быстрее, строго доказать программу, или снизить вероятность ошибок в ней до практически приемлимого уровня?

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

I>Не надо для этого печатать код

код это всегда зависимости, которые можно и нужно отрабатывать.
Это утверждение требует доказательств. Проведи его на примере функции для сжатия RLE-изображений, например.

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

Это, всего лишь, обозначает одно из двух. Либо ты неверно выделил критический участок, либо ты совсем не ориентируешься в коде и тебе надо смотреть вообще всё

I>В софте даже спящие процессы вроде while(true) Sleep(1000); влияют друг на друга

Тоже интересно бы узнать, как такой процесс влияет на цвета пикселей, полученных в результате ошибки алгоритма сжатия. Или на взрыв QSort'а...

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

E>Но давай вернёмся к нашим примерам.
E>1) Взрыв QSort'а.
E>Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
E>Данные -- массив чисел типа double.
E>Что делаем дальше?

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

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

Pzz>В связи с этим возникает забавный философический вопрос: можно ли так покрыть программу тестами, чтобы уменьшить вероятность ошибок до заданного уровня (естественно, имея ввиду вероятность ошибок в полном комплекте, программа+тесты). Или, более частный вопрос, можно ли быть уверенным, что от добавления очередного теста совокупная вероятность ошибок уменьшается? Насколько быстро она уменьшается? Можно ли проектировать тесты не от фонаря, а чтобы вероятность ошибок уменьшалась быстро? Будет ли это более или менее трудоемко, чем строгое доказательство? Если нанять миллион индусов, что будет быстрее, строго доказать программу, или снизить вероятность ошибок в ней до практически приемлимого уровня?

Я же говорю, что подветку давно пора в "философию" отделять. Она намного интереснее оригинального флейма про скобки

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

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

Так тоже, к сожалению бывает. Во всяком случае меня и нанимали и комадировали

Правда пара-тройка недель -- это как-то долго.

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

Pzz>>В связи с этим возникает забавный философический вопрос: можно ли так покрыть программу тестами, чтобы уменьшить вероятность ошибок до заданного уровня (естественно, имея ввиду вероятность ошибок в полном комплекте, программа+тесты). Или, более частный вопрос, можно ли быть уверенным, что от добавления очередного теста совокупная вероятность ошибок уменьшается? Насколько быстро она уменьшается? Можно ли проектировать тесты не от фонаря, а чтобы вероятность ошибок уменьшалась быстро? Будет ли это более или менее трудоемко, чем строгое доказательство? Если нанять миллион индусов, что будет быстрее, строго доказать программу, или снизить вероятность ошибок в ней до практически приемлимого уровня?

E>Я же говорю, что подветку давно пора в "философию" отделять. Она намного интереснее оригинального флейма про скобки

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

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

E>Вероятно оно было не понятно сформулировано. Я от него ничего лучше, чем "заюзай дебагер" не услышал.
E>IMHO, конкретно для отладки взрыва QSort это плохая идея...

E>Но ты можешь пояснить его идеи, если ты их понимаешь...

Он сказал про дампы и дебуггер. взрыв qsorta и подобной дряни очень легко детектится например через GetThreadTimes, т.к. можно подсчитать ожидаемое значение.

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

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

Мне не надо было дампить ничего, просто нужно было знать, кто каким пришел по счету и что с этим делать. Потому я нумеровал элементы, а потом восстанавливал последовательность. Детектил чз GetThreadTimes + rdtsc + QueryPerformanceСounter.

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

Сильно думаю, CreatorCray имел сказать этот или похожий способ.

I>>Если ты ждешь, что я покажу тебе инструмент, который решает дифуры и уравнения новье-стокса то стоит несколько умерить ожидания.
E>Я придумал тебе модельную задачу. Если она тебе не подходит -- предложи свою.
E>Так что, просим, мастер! Просим!

Не, ближайшие две недели у меня мозг занят другими делами.

E>>>Но я так понял, что ты владеешь каким-то методами, которыми я не владею. Ну так покажи же наконец всю мощь своего кунг-фу?

I>>Нет никакой панацеи.
E>Разве речь о панацеи? Я предложил задачку, в которой, по моему мнению, будут полезны распечатки. Ты, можешь показать, как сделать лучше и без бумажек...

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

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

I>>Вот тебе простой пример — около 100кб кода на ассемблере, эмулятора нет, комп один на троих-четверых, разрабатываемая станция одна на несколько секторов, отладчика нет, вывода в консоль, дампов, логов — ничего нет. Все что есть — светодиоды на задней панели станции, схема тестируемого блока.

I>>Вот это тот случай, где нужна распечатка, что бы не курить бамбук, пока нет ни компа ни станции.

Pzz>Нет, это как раз тот случай, когда надо написать эмулятор.

И на чем его писать, на листочке бумаги и выполнять на рулоне бумаги ?

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

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

Pzz>>Нет, это как раз тот случай, когда надо написать эмулятор.

I>И на чем его писать, на листочке бумаги и выполнять на рулоне бумаги ?

Как на чем? На Си

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

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

I>В случае со взрывом qsort нужно перед прогоном пронумеровать элементы а потом тупо сделать дамп если будет задетекчен взрыв. Анализ дампа и тестовый прогон qsort на этих же данных даст возможность понять, что к чему.

I>Сильно думаю, CreatorCray имел сказать этот или похожий способ.

Наверное я как-то непонятно пишу, или мы разной терминологией пользуемся. Я уж не знаю.
Попробую объяснить очень подробно.
Вот смотри, всё, что ты написал выше -- это просто предварительный этап. Он ОЧЕНЬ ПРОСТОЙ. Но вот мы поняли на какой последовательности происходит взрыв.
Теперь нам надо ответить на два вопроса.
1) Насколько это вообще закономерно? То есть нам нереально фатально не повезло, или наши данные обладают какой-то особенностью, которая делает вероятность взрыва данной конкретной реализации QSort не такой уж и невероятной?
2) Что и как надо поправить, что бы сделать такое стечение обстоятельств невероятным?

Для простоты, давай считать, что реализация QSotr наша, её код доступен и для анализа и для модификации...

Итак, мы знаем, что эти 10 000 double, которые мы получаем из такого-то источника приводят нашу реализацию QSort к взрыву.
И вот тут на сцену выходит необходимость нетривильного анализа алгоритма. Что бы делаем дальше?

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

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

Это никакое не сильное, это скучная банальность.

E>Но давай вернёмся к нашим примерам.
E>1) Взрыв QSort'а.
E>Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
E>Данные -- массив чисел типа double.
E>Что делаем дальше?

дальше можно попробовать сортировать структуры double+int, мерять время, дампить и анализировать данные.

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

E>Ну на распечатке можно писать камменты к коду, а не просто камменты к бумажке...

I>>Код это всегда и везде зависимости, которые нужно отрабатывать.
E>Ну покажи это на моих примерах. Я же давно у тебя мастер-класс прошу...

Ближайшие две недели у меня очень много работы.

I>>А это значит, что даже если у тебя есть 300 проблемных строк, то у них гарантировано будут зависимости от других модулей.
E>Нифига это не так. Это только в задачах типа "GUI-клей между разными моторами" так всегда. А если у тебя какой-то нетривильный алгоритм реализован, то пофигу зависимости обычно.

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

I>>Если же зависимостей не будет или количество будет некритичным, то задача сводится к функции и решается через тестирование.
E>Ну покажи как оно решается-то?

Примерно так — assert(f(x) == 5);

I>>И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.
E>Никак. Она нужна для другого. Для статического анализа алгоритма, представленного в виде распечатанного кода. Например, для доказательства его правильности, либо выявления условий, при которых правильность таки можно гарантировать...

Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?

Для доказательства правильности нужна запись алгоритма в виде всяких форумул.

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

I>>Рисуешь как тебе удобно. Я бы из блокнота отсканировал, но нет у меня сканера под рукой. Иногда удобно вместо рисования таблички заполнть. Иногда даже псевдокод писать.

E>Что за таблички?

поток или последовательность данных

E>В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?

Код при наличии тестов вещь очень эфемерная. БОлее того, его может и вообще не быть, что не мешает его анализировать

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

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

E>>Разве речь о панацеи? Я предложил задачку, в которой, по моему мнению, будут полезны распечатки. Ты, можешь показать, как сделать лучше и без бумажек...

I>Ты предложил задачу которая решается чз функциональщину, со всеми потрохами без сайдэффектов

Во-первых, проблема тут не в сайд-эффектах, а в сложности эффективного алгоритма. Эффективный -- это такой, который работает на уровне штрихов, не переходя на уровень пикселей.

Во-вторых, не верю. IMHO, в функциональной и в императивной записи этого кода будут общие проблемы. Не все, но многие.
В-третьих, дабы не растекаться мыслью по древу, давай останемся в рамках императивщины

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

I>>И на чем его писать, на листочке бумаги и выполнять на рулоне бумаги ?

Pzz>Как на чем? На Си

Pzz>Никто ж не утверждает, что бумажка и ручка — единственный полезный инструмент.

За отсутствием компьютера надо писать эмулятор на Си ? Правильно я тебя понял ?

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

Pzz>>Никто ж не утверждает, что бумажка и ручка — единственный полезный инструмент.

I>За отсутствием компьютера надо писать эмулятор на Си ? Правильно я тебя понял ?

Не понял, а компьютер куда делся? Вы там на бухгалтерских счетах, что ли, программировали?

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

E>>Это очень сильное утверждение, его не плохо бы доказать...

I>Это никакое не сильное, это скучная банальность.
Значит, наверное, доказать это утверждение тебе будет не трудно.
Итак, где док-во?

I>дальше можно попробовать сортировать структуры double+int, мерять время, дампить и анализировать данные.
Зачем всё это?
1) Лучше измерять не время, а число вызовов функции сравнения.
2) Положим мы уже знаем последовательность чисел, которая приводит к взрыву.
ЧТО ДЕЛАЕМ ДАЛЬШЕ?

E>>Ну покажи это на моих примерах. Я же давно у тебя мастер-класс прошу...

I>Ближайшие две недели у меня очень много работы.
Ну про зависимости в случае QSort показать, наверное, не трудно будет-то?

E>>А если у тебя какой-то нетривильный алгоритм реализован, то пофигу зависимости обычно.

I>Такого практически не бывает.
В смысле? Ты не веришь что в ПО есть куча нетривильных алгоритмов?

Вообще-то у кого как

I>Примерно так — assert(f(x) == 5);

I>

А если провалился, потому, что (f(x) == 6, то что делаем дальше?

I>>>И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.
E>>Никак. Она нужна для другого. Для статического анализа алгоритма, представленного в виде распечатанного кода. Например, для доказательства его правильности, либо выявления условий, при которых правильность таки можно гарантировать...

I>Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?

I>Для доказательства правильности нужна запись алгоритма в виде всяких форумул.

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

E>Для простоты, давай считать, что реализация QSotr наша, её код доступен и для анализа и для модификации...

E>Итак, мы знаем, что эти 10 000 double, которые мы получаем из такого-то источника приводят нашу реализацию QSort к взрыву.
E>И вот тут на сцену выходит необходимость нетривильного анализа алгоритма. Что бы делаем дальше?

Для Qsort не нужен анализ алгоритма, берешь гуглишь очередную реализацию и выясняешь, где проблема, с данными или твоей мега-фичей.

Если же под qsort ты имел ввиду не qsort, а другой алгоритм, то нужно знать детали. У каждого алгоритма свои особенности.

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

E>>Что за таблички?
I>поток или последовательность данных
Не проще ли их распечатать?

E>>В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?
I>Код при наличии тестов вещь очень эфемерная. БОлее того, его может и вообще не быть, что не мешает его анализировать

Не понимаю. Вот у тебя ошибка в коде, или где?

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

I>Для Qsort не нужен анализ алгоритма, берешь гуглишь очередную реализацию и выясняешь, где проблема, с данными или твоей мега-фичей.
Не понял, что гуглишь? Вот у тебя есть массив из 10 000 чисел и какая-то реализация QSort, как ты понимаешь, QSort, это на самом деле целое семейство алгоритмов. И что же нам погуглить, чтобы гарантировать пользователя от зависания нашего ПО?

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

I>Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?

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

I>Для доказательства правильности нужна запись алгоритма в виде всяких форумул.
Этого я совсем не понимаю. Запиши, пожалуйста, "в виде всяких форумул" алгоритм сортировки пузырьком, например.

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

I>Ближайшие две недели у меня очень много работы.

О! Аврал в конце года? Видимо управление разработкой не на высоте?

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

Pzz>>>Интересно, если автоматические инструменты есть для всего, зачем человек-то при них нужен?

AV>>Ну как же, а кто будет нажимать кнопку мыши чтобы автоматические инструменты начали работать?

Pzz>Автоматический нажиматель на кнопку мыши?

А кто нажмет на кнопку мыши для запуска автоматического нажимателя?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Ближайшие две недели у меня очень много работы.

E>О! Аврал в конце года? Видимо управление разработкой не на высоте?

Авраала нет, просто у меня задания по той области с которой я вообще не работал до этого.

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

E>>>Что за таблички?
I>>поток или последовательность данных
E>Не проще ли их распечатать?

Если есть чего печатать и это не пачка бумаги, то можно распечатать.

E>>>В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?
I>>Код при наличии тестов вещь очень эфемерная. БОлее того, его может и вообще не быть, что не мешает его анализировать

E>Не понимаю. Вот у тебя ошибка в коде, или где?

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

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

I>>Для Qsort не нужен анализ алгоритма, берешь гуглишь очередную реализацию и выясняешь, где проблема, с данными или твоей мега-фичей.
E>Не понял, что гуглишь? Вот у тебя есть массив из 10 000 чисел и какая-то реализация QSort, как ты понимаешь, QSort, это на самом деле целое семейство алгоритмов.

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

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

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

На это уйдет от силы час.

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

То есть, проанализировать код и найти ошибку.

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

E>>>Это очень сильное утверждение, его не плохо бы доказать...

I>>Это никакое не сильное, это скучная банальность.
E>Значит, наверное, доказать это утверждение тебе будет не трудно.
E>Итак, где док-во?

доказательство находится в определении понятия зависимость.

I>>дальше можно попробовать сортировать структуры double+int, мерять время, дампить и анализировать данные.
E>Зачем всё это?

Потому что это очень просто и эффективно

E>1) Лучше измерять не время, а число вызовов функции сравнения.
E>2) Положим мы уже знаем последовательность чисел, которая приводит к взрыву.

Опаньки, снова изменение условия задачи.

E>ЧТО ДЕЛАЕМ ДАЛЬШЕ?

Дальше см. другое сообщение. Но ты понмаешь, что изменил условие по ходу задачи ?

I>>Ближайшие две недели у меня очень много работы.
E>Ну про зависимости в случае QSort показать, наверное, не трудно будет-то?

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

I>>Такого практически не бывает.
E>В смысле? Ты не веришь что в ПО есть куча нетривильных алгоритмов?

И что с того ?

E>А если провалился, потому, что (f(x) == 6, то что делаем дальше?

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

Естественно, тесты не должны вносить доп. сложность.

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

I>>Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?

E>Ну потому, что это формальное представление алгоритма, с которым можно формально работать. Формально -- это значит путём формальных выкладок. Например, его можно преобразовать в какую-то более удобную форму, если надо. Или снабдить каким-нибудь предикатами, вычислить какие-нибудь пред и пост условия на что-нибудь в тех или иных точках и т. д...

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

Предикаты, пред и пост условия отлично вставляются в редакторе кода.

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

I>>За отсутствием компьютера надо писать эмулятор на Си ? Правильно я тебя понял ?

Pzz>Не понял, а компьютер куда делся? Вы там на бухгалтерских счетах, что ли, программировали?

Я ж сказал — компьютер один на троих-четверых.

Эмулятор писать дело достаточно трудоёмкое. Многие крупные конторы до сих пор не могут родить толковый эмулятор для своих разработок.

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

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

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

E>Я же говорю, что подветку давно пора в "философию" отделять. Она намного интереснее
оригинального флейма про скобки

Да нет здесь ничего особенного что бы отправлять в философию

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

E>>Один и простых примеров такого сценария -- это мы курим бумажку и понимаем какие инварианты каких циклов хорошо бы проверить. И если они ещё не проверяются в коде, то расставляем asserts и делаем прогон...

Pzz>Я бы перед тем, как писать такой текст, сначала спросил бы Ikemefula, знает ли он, что такое инварианты циклов

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

Доказать он это не может, пример привести — тоже не может.

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

Скажи честно, для чего по твоему используется юнит-тестирование ?

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

Pzz>Если кто-то, начитавшись нашего флейма, создаст общую теорию тестирования, со стороны этого человека было бы свинством в своей Тьюринговской лекции не упомянуть этот форум и меня, подкинувшего ему идею

Некий Glenford Myers уже давно сделал свое черное дело, так что ты опоздал.

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

Pzz>>Не понял, а компьютер куда делся? Вы там на бухгалтерских счетах, что ли, программировали?

I>Я ж сказал — компьютер один на троих-четверых.

Я так понял по твоему изначальному рассказу, что там target один на троих-четверых, а не host.

У вас что, писюков в достаточном количестве не было? Круто.

I>Эмулятор писать дело достаточно трудоёмкое. Многие крупные конторы до сих пор не могут родить толковый эмулятор для своих разработок.

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

I>Одно дело — эмулятор процессора, и совсем другое — эмулятор для компонента который по сложности как компьютер, при компонент этот в стадии разработки.

I>На то время, это было более 10 лет назад, подобные эмуляторы были только как внутренний софт у контор вроде Intel.

Я работал в чиподельческой конторе (значительно более мелкой, чем Интел), в которой был эмулятор ихнего железа. Собственно, сначала был написан эмулятор чипа, потом софтварий, потом уже и чип появился. Я даже embedded linux на этом эмуляторе запустил, было прикольно

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

I>У Егора задача простая — доказать, что для вычисления инвариантов цикла обязательно нужна бумажка с распечатаным на ней кодом.

Я согласен с Егором. Вообще, на бумажке думать можно, на компьютере — нет. Его электромагнитное излучение парализует мозги

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

I>Скажи честно, для чего по твоему используется юнит-тестирование ?

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

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

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

E>>>Ну, например, локализован точностью до стони строк. Скажем, что такой-то алгоритм, вернее такая-то его реализация работает не так, как ожидалось.
E>>>Что делаем дальше?

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

E>Но давай вернёмся к нашим примерам.
E>1) Взрыв QSort'а.
E>Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
E>Данные -- массив чисел типа double.
E>Что делаем дальше?

E>2) Сжатие RLE картинки. Опять же замкнутый в себе алгоритм. Чё за зависимости нам надо выявить?

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

E>Ну на распечатке можно писать камменты к коду, а не просто камменты к бумажке...

...

Сорри что влезаю но меня подобные вопросы вполне интересуют

я просто не заметил что народ от скобочек перешел к чему-то полезному.
Для начала я не вижу никакой пользы в распечатке кода. Совсем. Пробовал — не помогает. Много рисунков на бумажке с конфигурациями и как они влияют на части алгоримов — да. Я даже искренне жалею что в код нельзя вставить картинку. Щас работа связана с 2Д геометрией и 2Д картинка поясняющая случай, который в данном месте обрабатывается видеть было бы очень неплохо. Юнит-тест используется как маленький int main() чтобы быстро зайти отладчиком внутрь алгоритма и посмотреть как оно там. Если сложность склепать тест превышает некоторую или есть более легкий способ загнать нужный кейс в отладчик то юниттест идет лесом.
Чего вы там с распечаткой делаете ?
Видел реальный случай — чел ползал по простыне кода 3 месяца. Расрисовал ascii псевдографикой и комментариями весь файл и ... ничего. То есть совсем.

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

VV>Потому что 80 символов — это ограничение на уровень говнокодовости написаного.
На С++ с шаблонами и тамошними template, typename очень сложно бывает въехать в 80 символов.

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

I>>Я ж сказал — компьютер один на троих-четверых.

Pzz>Я так понял по твоему изначальному рассказу, что там target один на троих-четверых, а не host.

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

Pzz>У вас что, писюков в достаточном количестве не было? Круто.

Не было и это ни разу не общага.

Pzz>Написать эмулятор под конкретную задачу заметно проще, чем универсальный эмулятор.
I>>На то время, это было более 10 лет назад, подобные эмуляторы были только как внутренний софт у контор вроде Intel.
Pzz>Я работал в чиподельческой конторе (значительно более мелкой, чем Интел), в которой был эмулятор ихнего железа. Собственно, сначала был написан эмулятор чипа, потом софтварий, потом уже и чип появился. Я даже embedded linux на этом эмуляторе запустил, было прикольно

Сколько бы тебе времени пришлось писать эмулятор, на котором можно будет отлаживать биос и софт для диагностики целого семейства многопроцессорных систем ?

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

I>>У Егора задача простая — доказать, что для вычисления инвариантов цикла обязательно нужна бумажка с распечатаным на ней кодом.

Pzz>Я согласен с Егором. Вообще, на бумажке думать можно, на компьютере — нет. Его электромагнитное излучение парализует мозги

Я уже заметил, что у тебя мозг парализован.

Думать можно только головой, а не на бумажке.

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

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

I>Егор ни мало ни много, утверждает, что распечатка кода есть необходимое условие решения задачи

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

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

I>Сколько бы тебе времени пришлось писать эмулятор, на котором можно будет отлаживать биос и софт для диагностики целого семейства многопроцессорных систем ?

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

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

I>>Скажи честно, для чего по твоему используется юнит-тестирование ?

Pzz>Для того, чтобы размазать ответственность за провал проекта по неопределенному кругу лиц.

Вот пример — http://weblogs.asp.net/cazzu/archive/2009/02/02/funq.aspx

Покажи, какую ответственность этот чел размазывает и обозначь круг лиц.

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

"размазывание ответсвенности" у тебя в голове. Удивляюсь, из какого махрового заповедника ты вылез ?

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

I>>Егор ни мало ни много, утверждает, что распечатка кода есть необходимое условие решения задачи

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

Это твои домыслы.

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

I>>Сколько бы тебе времени пришлось писать эмулятор, на котором можно будет отлаживать биос и софт для диагностики целого семейства многопроцессорных систем ?

Pzz>От трех дней до нескольких лет. Это очень зависит от того, сколь сложна архитектура системы и сколько всего полезного должен уметь делать эмулятор помимо возможности просто запускать на нем софтварий

Нужна эмуляция процессора, портов, памяти + все устройства, вроде ЦАП, АЦП и тд. Кроме того, нужна эмуляция сбоев на каждом из устройств. Еще нужно учитывать примерно десяток различных конфигураций на разные модули системы, всего модулей не более десятка. Каждый модуль это однопроцессорная система. Модулей в системе может быть до ста штук примерно.

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

I>Нужна эмуляция процессора, портов, памяти + все устройства, вроде ЦАП, АЦП и тд. Кроме того, нужна эмуляция сбоев на каждом из устройств. Еще нужно учитывать примерно десяток различных конфигураций на разные модули системы, всего модулей не более десятка. Каждый модуль это однопроцессорная система. Модулей в системе может быть до ста штук примерно.

Процессоры разные бывают, ровно как и ЦАП, АЦП и т.д.

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

E>>Не понял, что гуглишь? Вот у тебя есть массив из 10 000 чисел и какая-то реализация QSort, как ты понимаешь, QSort, это на самом деле целое семейство алгоритмов.

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

Ну ты же всегда имеешь дело с конкретной реализацией?
I>Гуглишь сначала по своей модификации, ищешь реализацию. Нет своей — ищешь подходящую. Проверяешь, сравниваешь результаты.
I>Не можешь гуглить — поищи код, например в crtl, главное что бы этот код был оттестирован и мог являться эталоном.
Ну я же тебе сказал, что для простоты считаем, что у нас код реализации QSort полностью доступен. Зачем что-то гуглить-то
I>На это уйдет от силы час.

Ха, за час можно уже всё отладить...

I>Дальше тебе нужно взять отладчик, раскрыть дамп в каком редакторе и проверить, что не так.
А вот с этого места начинается интересное. Что именно ты планируешь делать с дампом и что именно в редакторе?

I>То есть, проанализировать код и найти ошибку.
Ну так вот место-то и есть самое интересное. Как анализировать-то? Я, например, именно для такого анализа распечатки и использую...

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

I>Опаньки, снова изменение условия задачи.
Я тебе с самого начала пишу, что мы знаем последовательность на которой взорвались и код реализации...

E>>ЧТО ДЕЛАЕМ ДАЛЬШЕ?

I>Дальше см. другое сообщение. Но ты понмаешь, что изменил условие по ходу задачи ?
Ну то, что нужно делать ДО этапа "анализируем код и находим ошибку" просто и линейно... Чего там обсуждать-то?

I>Анализируешь код и исправляешь. Не помогло — анализируешь дальше и так до победы. По ходу анализа у тебя обязательно появятся новые тесты.
I>Естественно, тесты не должны вносить доп. сложность.

А вот как процесс анализа-то происходит?

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

I>Предикаты, пред и пост условия отлично вставляются в редакторе кода.
Правда, что ли? И как ты вставляешь знак интеграла, например? Или, хотя бы знак суммы? А кванторы?

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

I>>Нужна эмуляция процессора, портов, памяти + все устройства, вроде ЦАП, АЦП и тд. Кроме того, нужна эмуляция сбоев на каждом из устройств. Еще нужно учитывать примерно десяток различных конфигураций на разные модули системы, всего модулей не более десятка. Каждый модуль это однопроцессорная система. Модулей в системе может быть до ста штук примерно.

Pzz>Процессоры разные бывают, ровно как и ЦАП, АЦП и т.д.

Ну значит пусть будет три дня

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

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

E>Ну ты же всегда имеешь дело с конкретной реализацией?

И что с того? Если есть алгоритм на С++ какой то, вроде qsort, я не знаю где ждать ошибки.

Процедура стандарная — найти выборку, выделить алгоритм и выборку в тест, подменить алгоритм после чего точно будет видно, где именно ошибка.

I>>Гуглишь сначала по своей модификации, ищешь реализацию. Нет своей — ищешь подходящую. Проверяешь, сравниваешь результаты.
I>>Не можешь гуглить — поищи код, например в crtl, главное что бы этот код был оттестирован и мог являться эталоном.
E>Ну я же тебе сказал, что для простоты считаем, что у нас код реализации QSort полностью доступен. Зачем что-то гуглить-то

Ты много чего говорил и менял условие

I>>Дальше тебе нужно взять отладчик, раскрыть дамп в каком редакторе и проверить, что не так.
E>А вот с этого места начинается интересное. Что именно ты планируешь делать с дампом и что именно в редакторе?

Дамп нужно представить в читаемом виде. Я не умею читать даблы в hex. Дальше код запускается в отладчике и проверяешь все что тебе нужно.

I>>То есть, проанализировать код и найти ошибку.
E>Ну так вот место-то и есть самое интересное. Как анализировать-то? Я, например, именно для такого анализа распечатки и использую...

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

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

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

I>>Опаньки, снова изменение условия задачи.
E>Я тебе с самого начала пишу, что мы знаем последовательность на которой взорвались и код реализации...

Это враньё. Вот твое условие — " борьба со взрывами QSort на каких-то специфичных данных"

E>>>ЧТО ДЕЛАЕМ ДАЛЬШЕ?

I>>Анализируешь код и исправляешь. Не помогло — анализируешь дальше и так до победы. По ходу анализа у тебя обязательно появятся новые тесты.
I>>Естественно, тесты не должны вносить доп. сложность.

E>А вот как процесс анализа-то происходит?

Походу, надо ждать вопросов вроде "а ты знаешь, что такое инвариант цикла ?"

Вобщем, сходи погуляй ?

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

I>>Предикаты, пред и пост условия отлично вставляются в редакторе кода.
E>Правда, что ли? И как ты вставляешь знак интеграла, например? Или, хотя бы знак суммы? А кванторы?

Опаньки ! Тебе снова нужно нечто отличное чем код

Нет никакой необходимости все это писать на бумажке с кодом.

Не нужна для этого распечатка вообще.

Формулы, диаграмы — что угодно, нужны, распечатка — не нужна.

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

SD>Сорри что влезаю но меня подобные вопросы вполне интересуют

я просто не заметил что народ от скобочек перешел к чему-то полезному.
SD>Для начала я не вижу никакой пользы в распечатке кода. Совсем. Пробовал — не помогает. Много рисунков на бумажке с конфигурациями и как они влияют на части алгоримов — да. Я даже искренне жалею что в код нельзя вставить картинку.
Ну и вообще много чего нельзя вставить без геморра.
Но в любом случае писать картинки/заметки в коде или в данных — это примерно одно и то же. Мне просто удобнее непосредственно код комментировать.

SD>то юниттест идет лесом.
Суть тестов не в этом. Это некая гарантия того, что код всё ещё выполняет свой контракт. Полезно при рефакторинге, например.

SD>Чего вы там с распечаткой делаете ?
Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный

SD>Видел реальный случай — чел ползал по простыне кода 3 месяца. Расрисовал ascii псевдографикой и комментариями весь файл и ... ничего. То есть совсем.

Это, скорее всего, не то. Обычно ползать надо не по простыне, и недолго

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

I>Процедура стандарная — найти выборку, выделить алгоритм и выборку в тест, подменить алгоритм после чего точно будет видно, где именно ошибка.
Интересно. Положим я заменю один qsort на другой. И на жругой реализации qsort на ЭТОЙ КОНКРЕТНОЙ выборке взрыва не будет.
Что делаем дальше?

I>Ты много чего говорил и менял условие

1) Это тут не важно
2) У нас, похоже, было некое взаимное непонимание. Я под отладкой взрыва имел в виду именно поиск особенности алгоритма, а ты всякие предшествующие шаги. Предшествующие шаги тут понятны и тривиальны. Их я обсуждать вообще не собирался.

I>Дамп нужно представить в читаемом виде. Я не умею читать даблы в hex. Дальше код запускается в отладчике и проверяешь все что тебе нужно.
Ну данные -- это 10 000 чисел double, или int, не важно.
Итак, у тебя есть код в отладчике, данные из 10 000 чисел и алгоритм, который выполняет 100 000 000 итераций, вместо 150 000 ожидаемых
Что делаем дальше?

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

I>И при этом, как выяснилось, тебе нужны и полуавтоматические средства и некое более удобное представление нежели код и все только для того, что бы бумажка с кодом помогать начала.
Ну это всё рутина же. А "более удобное представление" нужно редко. Обычно достаточно начать смтроить формальное доказательство алгоритма и ограничивающие функции циклов...

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

I>Это враньё. Вот твое условие — " борьба со взрывами QSort на каких-то специфичных данных"
Так это и есть борьба. Сначала мы детектируем проблему. Что программа не просто зависла, а взорвался такой-то алгоритм.
А потом нам надо как-то понять что такое сделать, чтобы представить гарантии того, что больше не взорвётся...

I>Походу, надо ждать вопросов вроде "а ты знаешь, что такое инвариант цикла ?"
Я надеюсь, что знаешь. Я тебе уже писал про то что
1) надеюсь, что ты знаешь
2) Если паки чаяния нет, то давал ссылку где посмотреть.
Ну я тебе объяснил уже много раз, что нетривильные алгоритмы МНЕ удобно доказывать, работая с распечаткой.
А как это делаешь ты?

I>Вобщем, сходи погуляй ?
Зачем грубить-то?

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

I>Опаньки ! Тебе снова нужно нечто отличное чем код

I>Нет никакой необходимости все это писать на бумажке с кодом.
Дык это же комменты к коду.

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

I>Не нужна для этого распечатка вообще.
I>Формулы, диаграмы — что угодно, нужны, распечатка — не нужна.

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

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

I>У Егора задача простая — доказать, что для вычисления инвариантов цикла обязательно нужна бумажка с распечатаным на ней кодом.
I>Доказать он это не может, пример привести — тоже не может.
У меня задача совсем другая. Я хочу понять, как ты делаешь без бумажки то, что мне удобно делать с бумажкой...

Но ты не хочепшь дать мастер-класс. Увы.

I>По этой причине он пытается хитрить — предлагает мне доказать что бумажка с кодом не нужна

Нет, я просто прошу показать, как ТЫ делаешь это без бумажки...

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

I>"инвариант цикла"

А что тебя веселит в этом термине?

I>Скажи честно, для чего по твоему используется юнит-тестирование ?
AFAIK, юнит-тестирование предназначено для контроля соблюдения контрактов компонентами ПО...

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

Крис (мышь) тоже пишет программный код со скобками, расположенными в правильном стиле. Поэтому истинного профессионала видно издалека!

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

Pzz>>Егор утверждает не более того, что существует класс людей, для которых распечатка полезна, и он принадлежит этому классу.
I>Это твои домыслы.

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

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

O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

К сожалению это пошло со времен господина Кернигана Ритчи.

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

I>>Доказать он это не может, пример привести — тоже не может.
E>У меня задача совсем другая. Я хочу понять, как ты делаешь без бумажки то, что мне удобно делать с бумажкой...

E>Но ты не хочепшь дать мастер-класс. Увы.
I>>По этой причине он пытается хитрить — предлагает мне доказать что бумажка с кодом не нужна

E>Нет, я просто прошу показать, как ТЫ делаешь это без бумажки...

Не надо хитрить. Бумага и распечатка это разные вещи.

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

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

I>>Это враньё. Вот твое условие — " борьба со взрывами QSort на каких-то специфичных данных"
E>Так это и есть борьба. Сначала мы детектируем проблему. Что программа не просто зависла, а взорвался такой-то алгоритм.
E>А потом нам надо как-то понять что такое сделать, чтобы представить гарантии того, что больше не взорвётся...

Мне не ясно, какой смысл ты вложил в слово "борьба". У меня в этом слове и воспроизведение и локализация ошибки и тд и тд и тд.

E>Ну я тебе объяснил уже много раз, что нетривильные алгоритмы МНЕ удобно доказывать, работая с распечаткой.
E>А как это делаешь ты?

Без распечатки. Все что необходимо, пишу, рисую на бумаге если это необходимо.

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

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

Это секретная боевая метода, которую запрещается разглашать в RSDN

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

I>>Процедура стандарная — найти выборку, выделить алгоритм и выборку в тест, подменить алгоритм после чего точно будет видно, где именно ошибка.
E>Интересно. Положим я заменю один qsort на другой. И на жругой реализации qsort на ЭТОЙ КОНКРЕТНОЙ выборке взрыва не будет.
E>Что делаем дальше?

Это значит, что дело в конкретной реализации. Потому я буду сравнивать, в чем разница между алгоритмами.

I>>Ты много чего говорил и менял условие

E>1) Это тут не важно
E>2) У нас, похоже, было некое взаимное непонимание. Я под отладкой взрыва имел в виду именно поиск особенности алгоритма, а ты всякие предшествующие шаги. Предшествующие шаги тут понятны и тривиальны. Их я обсуждать вообще не собирался.

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

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

Восторга это не вызывает.

E>Что делаем дальше?

дальше ничего не делам по известной тебе причине.

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

Господи, то "тебе удобно", то "cамый эффективный метод"

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

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

O>>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?

Q>К сожалению это пошло со времен господина Кернигана Ритчи.
Брайан Керниган и Деннис Ричи — четыре разных человека.

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

I>Не надо хитрить. Бумага и распечатка это разные вещи.

Ну, то есть спор о том, что удобнее? Писать на распечатке с кодом по месту, или писать на отдельной бумажке, в стиле "к строке номер 8: <<<коммент к строке номер 8>>>"?

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

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

I>Это значит, что дело в конкретной реализации. Потому я буду сравнивать, в чем разница между алгоритмами.
Думаешь проанализировать два проще, чем один?

I>Ну так надо было и говорить — есть самопальный qsort, есть выборка данных, есть гарантия отсутствия влияния извне, есть аномальное поведение.
Почему самопальный? Обычно берут какой-то конкретный, и таскают с собой, чтобы в случае чего не нарваться...

I>Ты вроде математик, а мне приходится и формулировать за тебя и примеры приводить вместо тебя

I>Господи, то "тебе удобно", то "cамый эффективный метод"

Ну альтернативу ты так и не показал...

Или суть альтернативы в стиле камментов. Писать их на бумажке с кодом, или на другой бумажке, а на код как-то ссылаться?
IMHO, это не важно. Методы изоморфны, так сказать.

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

I>>Не надо хитрить. Бумага и распечатка это разные вещи.
E>Ну, то есть спор о том, что удобнее? Писать на распечатке с кодом по месту, или писать на отдельной бумажке, в стиле "к строке номер 8: <<<коммент к строке номер 8>>>"?

Ни разу такого не писал

E>Сначала ты что-то писал о том что от компа не надо уходить, так как там есть какие-то полезные инструменты, вроде как...
E>Или ты это про тривиальный предварительный этап диагностики проблемы?

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

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

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

I>>Это значит, что дело в конкретной реализации. Потому я буду сравнивать, в чем разница между алгоритмами.
E>Думаешь проанализировать два проще, чем один?

Сложнее, зато два дадут больше информации, что можно использовать.

I>>Ну так надо было и говорить — есть самопальный qsort, есть выборка данных, есть гарантия отсутствия влияния извне, есть аномальное поведение.
E>Почему самопальный? Обычно берут какой-то конкретный, и таскают с собой, чтобы в случае чего не нарваться...

Чем стандартный не устраивает ?

E>IMHO, это не важно. Методы изоморфны, так сказать.

Изоморфтны. Что с того ? Я постоянно меняю код что бы раскопать ошибку. Ты предпочитаешь код не трогать. Может ты его боишься тронуть, учитывая твои слова про 200К на функцию ?

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

E>>Ну, то есть спор о том, что удобнее? Писать на распечатке с кодом по месту, или писать на отдельной бумажке, в стиле "к строке номер 8: <<<коммент к строке номер 8>>>"?

I>Ни разу такого не писал

Ну я всё жду, что ты покажешь как ТЫ делаешь...

I>На самом деле он никакой не тривиальный в общем случае. Но в основном про него.
Это не интересно, и не по теме распечаток.
Обычно, если что-то тормозит, то это что-то профилируют и сразу увидят, что взорвалось-то. В один шаг так сказать.
Потом надо ещё суметь зпписать данные, которые приводят к взрыву. но в нормальных системах и так есть развитая система логгирования. Так что это второй шаг. Часто тоже банальный.
Ну и потом начинается небанальный шаг. Как лечить-то?
Если первые два я легко могу поручить подчинённому, то последний шаг сложнее намного...

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

I>>>Ну так надо было и говорить — есть самопальный qsort, есть выборка данных, есть гарантия отсутствия влияния извне, есть аномальное поведение.
E>>Почему самопальный? Обычно берут какой-то конкретный, и таскают с собой, чтобы в случае чего не нарваться...

I>Чем стандартный не устраивает ?
Что такое "стандартный"? У каждого вендора он свой. Так как есть всегда шанс при смене версии qsort'а нарваться, то лучше взять какую-то конкретную реализацию и таскать её вместе с проектом. Она где-то когда-то была "стандартной", но это не важно на самом деле

I>Изоморфтны. Что с того ? Я постоянно меняю код что бы раскопать ошибку. Ты предпочитаешь код не трогать.

Ну я использую контроль версий. Так что мне не сложно откатиться к trunk...

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

I>Может ты его боишься тронуть, учитывая твои слова про 200К на функцию ?

Что-то не припомню. Ссылочку не дашь?

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

E>>>Ну, то есть спор о том, что удобнее? Писать на распечатке с кодом по месту, или писать на отдельной бумажке, в стиле "к строке номер 8: <<<коммент к строке номер 8>>>"?

I>>Ни разу такого не писал

E>Ну я всё жду, что ты покажешь как ТЫ делаешь...

У тебя все в порядке ? С пятницы на субботу ты получил внятный ответ. Тебе его повторить ?

E>Обычно, если что-то тормозит, то это что-то профилируют и сразу увидят, что взорвалось-то. В один шаг так сказать.

А если тормоза вылезли во время эксплуатации, что тогда ?

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

I>>Может ты его боишься тронуть, учитывая твои слова про 200К на функцию ?

E>Что-то не припомню. Ссылочку не дашь?

I>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

Интересно, 200 КБ кода это сколько метров бумаги ?

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

I>У тебя все в порядке ? С пятницы на субботу ты получил внятный ответ. Тебе его повторить ?
Я так понял, что ты сможешь ответить через 2 недели.
Я жду...

E>>Обычно, если что-то тормозит, то это что-то профилируют и сразу увидят, что взорвалось-то. В один шаг так сказать.
I>А если тормоза вылезли во время эксплуатации, что тогда ?
А какая разница?

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

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

I>>>Может ты его боишься тронуть, учитывая твои слова про 200К на функцию ?

E>>Что-то не припомню. Ссылочку не дашь?

I>

I>>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
I>И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

I>Интересно, 200 КБ кода это сколько метров бумаги ?

Не знаю. Это же был код из ТВОЕЙ практики?

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

I>>У тебя все в порядке ? С пятницы на субботу ты получил внятный ответ. Тебе его повторить ?
E>Я так понял, что ты сможешь ответить через 2 недели.
E>Я жду...

E>>>Обычно, если что-то тормозит, то это что-то профилируют и сразу увидят, что взорвалось-то. В один шаг так сказать.
I>>А если тормоза вылезли во время эксплуатации, что тогда ?
E>А какая разница?

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

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

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

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

В случае взрыва qsort она уже и покажет, что проблема именно во взрыве qsort и состоит. Или у тебя какие-то другие подходы?

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

I>>

I>>>Приходилось иметь дело с кодом в 200 и более КБ причем на одну функцию. Код этот завязан на кое какие алгоритмы которых я не знал.
I>>И что? 200 КБ на функцию ничего не говорит ни о качестве кода ни о сложности алгоритмов.

I>>Интересно, 200 КБ кода это сколько метров бумаги ?

E>Не знаю. Это же был код из ТВОЕЙ практики?

Зато мнение "200 КБ на функцию ничего не говорит ни о качестве кода " — твоё.

У меня мнение про 200 КБ нафункцию — говно. А у тебя " ничего не говорит "

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

I>У меня мнение про 200 КБ нафункцию — говно. А у тебя " ничего не говорит "

Ну и зря. Бывает длинный-длинный линейный код... Неприятно, но несмертельно...

Но это опять не про то разговор. 200К печатать не особо хорошая идея. Но если тебе интересно, это всего сотня страниц где-то...

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

E>Слушай, я опять чего-то не понимаю.
E>По идее анализ лога проблемного запроса или его профилирование -- это первая реакция на тормоза.

E>В случае взрыва qsort она уже и покажет, что проблема именно во взрыве qsort и состоит. Или у тебя какие-то другие подходы?

Мне как то везло и запросы могли тормозить по самым разным причинам

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

I>Мне как то везло и запросы могли тормозить по самым разным причинам

Конечно по разным. За этим анализ лога и профилирование и проводят, чтобы сузить круг. КОНКРЕТНО в случае взрыва qsort эти меры однозначно выявят причину...

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

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

SD>>Сорри что влезаю но меня подобные вопросы вполне интересуют

я просто не заметил что народ от скобочек перешел к чему-то полезному.
SD>>Для начала я не вижу никакой пользы в распечатке кода. Совсем. Пробовал — не помогает. Много рисунков на бумажке с конфигурациями и как они влияют на части алгоримов — да. Я даже искренне жалею что в код нельзя вставить картинку.
E>Ну и вообще много чего нельзя вставить без геморра.
E>Но в любом случае писать картинки/заметки в коде или в данных — это примерно одно и то же. Мне просто удобнее непосредственно код комментировать.

дык картинки они к коду отношения почти не имеют. Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

SD>>то юниттест идет лесом.
E>Суть тестов не в этом. Это некая гарантия того, что код всё ещё выполняет свой контракт. Полезно при рефакторинге, например.

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

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

SD>>Чего вы там с распечаткой делаете ?
E>Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный

дык см выше.

SD>>Видел реальный случай — чел ползал по простыне кода 3 месяца. Расрисовал ascii псевдографикой и комментариями весь файл и ... ничего. То есть совсем.

E>Это, скорее всего, не то. Обычно ползать надо не по простыне, и недолго

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

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

E>>Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный

SD>дык см выше.

Ну у вас не бывает что ли ошибок в алгоритмической части?

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

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

E>>>Ну я доказываю про код разные факты. Обычно есть конкретная задача. Ну, например, найти причину какого-то поведения. Ну вот и доказываем разные факты про код, пока не докажем нужный

SD>>дык см выше.

E>Ну у вас не бывает что ли ошибок в алгоритмической части?

ну зачем скипать весь текст чтобы увидев отсыл к нему задавать столько знаков вопроса?

повтор предыдущей серии:
Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

То есть в коде реализовано много чего что реально происходит зависит от данных и настроек в точке Х. Разумеется ошибки могут быть начиная от спек и далее. Помню как ужаснуло когда нашел баг закрепленный юнит-тестом. Неудобно в тесте описывать сложную геометрическую ситуацию. Первый же взгляд на картинку (вот тут я и захотел вставку картинок в код) показал что ошибка в логике, но в простынке "кода" это осталось неочевидным, тк были десятки случаев правильных а этот нет.

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

SD>Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

Не понимаю. Ну есть код, который запускается во многих режимах. Ну, казалось бы, вот в этом-то случае и надо его проверять ФОРМАЛЬНО, так как на уровне "общих рассуждений" обязательно прошляпишь какой-нибудь частный случай.

SD>То есть в коде реализовано много чего что реально происходит зависит от данных и настроек в точке Х. Разумеется ошибки могут быть начиная от спек и далее. Помню как ужаснуло когда нашел баг закрепленный юнит-тестом. Неудобно в тесте описывать сложную геометрическую ситуацию. Первый же взгляд на картинку (вот тут я и захотел вставку картинок в код) показал что ошибка в логике, но в простынке "кода" это осталось неочевидным, тк были десятки случаев правильных а этот нет.

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

Давай какой-нибудь простой модельный пример рассмотрим.
Скажем у нас есть выделялка связанных областей, которая параметризуется представлением и итератором изображений, представлением связанной области и определялкой локальной связанности (ну там 4-связанность, 8-связанность или что-то более экзотическое)

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

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

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

SD>>Писать код который работает с 1-2мя вещами экономически невыгодно. В итоге имеем семейство алгоритмов которое имеет много настроек и работает с разными данными. Чтобы понять какое сочетание данных и настроек из факториала выделилось и требует внимания нужно диагностировать конкретный случай. То есть цепочка данных + настройки + поток обработки данных. К коду это имеет отношение постольку-поскольку.

E>Не понимаю. Ну есть код, который запускается во многих режимах. Ну, казалось бы, вот в этом-то случае и надо его проверять ФОРМАЛЬНО, так как на уровне "общих рассуждений" обязательно прошляпишь какой-нибудь частный случай.

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

Так сказать практические наблюдения.

SD>>То есть в коде реализовано много чего что реально происходит зависит от данных и настроек в точке Х. Разумеется ошибки могут быть начиная от спек и далее. Помню как ужаснуло когда нашел баг закрепленный юнит-тестом. Неудобно в тесте описывать сложную геометрическую ситуацию. Первый же взгляд на картинку (вот тут я и захотел вставку картинок в код) показал что ошибка в логике, но в простынке "кода" это осталось неочевидным, тк были десятки случаев правильных а этот нет.

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

E>Давай какой-нибудь простой модельный пример рассмотрим.
E>Скажем у нас есть выделялка связанных областей, которая параметризуется представлением и итератором изображений, представлением связанной области и определялкой локальной связанности (ну там 4-связанность, 8-связанность или что-то более экзотическое)

E>Ну вот мы нашли, что что-то не так выделяется в каком-то частном случае. Нам надо понять, баг ли это выделялки или одного из параметров. Так?

Да, если рассматривать 1 функцию изолированно.

Но если взять и приблизиться еще на шаг к реальности могу привести иллюстрацию-пример над уже векторной геометрией. Есть операции : booleans( and, or, not ), cut, enclose, inside, interact, outside, touch, area, perimeter, extents, vertex_count ... Кто их будет делать независимыми формально проверяемыми функциями ? Это меняет оценку стоимости на порядок или даже на 2 так как и тестировать разную обработку с ними придется по новой и проблемы будут разные. А теперь зададим простой вопрос — а работает ли каждая из них над всеми данными или частью ? А части взаимодействуют ? Это только в идеальном мире вся геометрия лежит в одном массиве, все полигоны не самопересекающиеся и тп

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

Здравствуйте, Игoрь, Вы писали:

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

Pzz>>80 — это хорошая ширина. Не слишком большая, не слишком маленькая. Обычно если код не умещается в эту ширину, это свидетельствует о чрезмерном уровне вложенности. Разбиение такого кода на несколько функций помогает и ширину уменьшить, и логику кода сделать более внятной.

Pzz>>P.S. Кстати, экраны-то широкие появились, но слишком широкий код на принтере нормально не напечатаешь, а это иногда бывает полезно, чтобы с ним карандашом поработать

И>От блин, теоретики-рассуждатели.
И>

И>namespace BlahBlahaBlah
И>{
И>    class BlahBlah
И>    {
И>        public void DoBlah(FlowDocument original)
И>        {
И>            var sourceRange = new TextRange(original.ContentStart, original.ContentEnd); // <-- 88 символов
И>        }
И>    }
И>}
И>

а может, лучше так?
И>

И>namespace BlahBlahaBlah
И>{
И>        class BlahBlah
И>        {
И>                public void DoBlah(FlowDocument original)
И>                {
И>                        var sourceRange = new TextRange( original.ContentStart, original.ContentEnd ); // <-- куда больше символов
И>                }
И>        }
И>}
И>

а что, ширина экрана не проблема. зачем ужиматься?

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

И>>

И>>namespace BlahBlahaBlah
И>>{
И>>        class BlahBlah
И>>        {
И>>                public void DoBlah(FlowDocument original)
И>>                {
И>>                        var sourceRange = new TextRange( original.ContentStart, original.ContentEnd ); // <-- куда больше символов
И>>                }
И>>        }
И>>}
И>>

M_>а что, ширина экрана не проблема. зачем ужиматься?

Ну да, купил монитор в два раза ширше и все дела

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

E>>Я указал конкретную проблему. Взрыв QSort на каких-то специфичных данных. Чем там поможет подсветка и рефакторилка? Ну и вообще что именно поможет-то, кроме головы?

I>Сколько тебе лет ?

I>У меня были похожие задачи, получалось решать их используя инструменты.
но при этом просто взять и привести конкретный список инструментов ты не можешь?

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

SD>Ну "формально" проверять можно много чего и как. Если в коде отсутствует проверка предусловий/постусловий/инвариантов (даже если она отключаемая) то над исходником на бумаге можно разве что рыдать

Так сказать практические наблюдения.

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

SD>Да, если рассматривать 1 функцию изолированно.
Ну это же очень упрощённая модельная задача. Просто на моделе проще понимать друг дурга.

SD>Но если взять и приблизиться еще на шаг к реальности могу привести иллюстрацию-пример над уже векторной геометрией. Есть операции : booleans( and, or, not ), cut, enclose, inside, interact, outside, touch, area, perimeter, extents, vertex_count ... Кто их будет делать независимыми формально проверяемыми функциями ? Это меняет оценку стоимости на порядок или даже на 2 так как и тестировать разную обработку с ними придется по новой и проблемы будут разные. А теперь зададим простой вопрос — а работает ли каждая из них над всеми данными или частью ? А части взаимодействуют ? Это только в идеальном мире вся геометрия лежит в одном массиве, все полигоны не самопересекающиеся и тп

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

SD>То есть мой пойнт в том что рассматривать функции изолированно могут обладатели бесконечного времени и ресурсов. И читать код вместо того чтобы он сам проверил контракты просто не рационально.

Проверять контракты руками не стоит. Рками надо делать совсем другое. Проверять спеки, ну это в твоём случае.
У теюя ситуация ещё более располагающая к работе без компа, чем обычно.
Потому что, насколько я понял, есть некая довольно абстрактная модель обработки данных, которая наполняется реальным содержанием после того, как мы задали данные и параметры. Соответственно ошибки могут быть как на уровне этой абстрактной можели, так и на уровне её реализации, и на уровне параметризации этой реализации конкретными настройками. Так? Ну так искать ошибки в абстрактных уровнях реально только на бумажке как раз. И убеждаться, что их там нет тоже.

Правда тут есть ход. Можно сделать альтернативную, более абстрактную реализацию можели. Ну, типа на прологе каком, например. И иметь инструемтарий для отображаения реальной ситуации в модельную, и прогона там. Опять же можно из той реализации и из боевой писать лог работы абстрактной модели. И если абстрактная модель тоже падает, то значит, что проблема в модели. А если абстрактная работает, а боевая нет, то значит проблема в реализации. Что можно проверить сличив логи.

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

От:	okman	https://searchinform.ru/
Дата:	27.11.10 13:57
Оценка:	15 (8) +24 -15

	От:	Ops
	Дата:	27.11.10 14:09
	Оценка:

	От:	dilmah
	Дата:	27.11.10 14:13
	Оценка:	1 (1) +2

	От:	iHateLogins
	Дата:	27.11.10 14:17
	Оценка:

	От:	_Ursus_
	Дата:	27.11.10 14:25
	Оценка:	1 (1) +2

	От:	minorlogic
	Дата:	27.11.10 17:26
	Оценка:	1 (1) +8

	От:	CreatorCray
	Дата:	27.11.10 17:40
	Оценка:	2 (2) +2

	От:	Antikrot
	Дата:	27.11.10 17:58
	Оценка:	1 (1) +11

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	27.11.10 19:34
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	27.11.10 20:01
Оценка:	1 (1)

	От:	Игoрь
	Дата:	28.11.10 11:24
	Оценка:	1 (1) +3 -3

От:	jazzer	Skype: enerjazzer
Дата:	28.11.10 22:38
Оценка:	+2

От:	Mamut	http://dmitriid.com
Дата:	29.11.10 16:00
Оценка:	10 (4) +2

	От:	Eugeny__
	Дата:	29.11.10 16:49
	Оценка:	2 (1) +2 -3

	От:	Pyromancer
	Дата:	29.11.10 21:58
	Оценка:	+1 -1

От:	henson	http://www.njt-rails.com
Дата:	29.11.10 22:16
Оценка:	1 (1) +5

От:	Фанатик	http://vk.com/id10256428
Дата:	30.11.10 06:31
Оценка:

	От:	yoriсk.kiev.ua
	Дата:	30.11.10 14:46
	Оценка:	+4 -1

	От:	Воронков Василий
	Дата:	08.12.10 14:59
	Оценка:

От:	R.O. Prokopiev	http://127.0.0.1/
Дата:	08.12.10 16:24
Оценка:	+2

	От:	vladimir.vladimirovich
	Дата:	08.12.10 22:41
	Оценка: