вкуривать чужой код

Что значит "вкуривать"?

>Что значит "вкуривать"?

разобрать исходники до полного понимания каждой строчки

А зачем? Ведь быстрее же написать новые исходники.

>А зачем? Ведь быстрее же написать новые исходники.

нет, не всегда

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

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

1. Изучать доки.
2. Генерить новые (doxygen)
3. Схемки всякие ручкой на бамажке рисовать тоже полезно бывает
4. Я в одном проекте брал целые куски кода, писал к ним обвязку и запускал отдельно от всего проекта - чтобы смотреть как оно 
шевелится - мне помогало разобраться

Покрой код юниттестами на 100 процентов.

совсем недавно пробегал линк: http://www.bolero.ru/books/9785845906045.html

не читал. только собираюсь :)

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

я люблю дебагером гулять... прицепиться и

next,
next,
next
p что-нибудь, и опять
next
next
....


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


Вообще, зависит от кода - есть за ним какие-то идеи или это свалка хаков.

Знаешь про

http://sourceforge.net/projects/sourcenav

? Штука сдохшая, но все еще полезная.

Говорят, что это самый верный способ, учить программирование.

Сам не пробовал, сначала разбирался как писать - потом с чужим.

Понимание приходит с опытом *)

думаю, сильно зависит от "парадигмы", которой мыслил автор.

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

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

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

Почитай «искусство программирования UNIX» снчала.

> думаю, сильно зависит от "парадигмы", которой мыслил автор.

Смотря на каком языке он писал. Если С, то никаких парадигм не надо. Всё в рамках языка. Если же какой-нибудь быдлоязык вроде С++, то никакие парадигмы не помогут. Проще переписать всё с ноля.

Так, это чего тут за унылые пионэрские вопли "невозможно"? Все возможно, сидишь и вникаешь. Нужно время. Читаешь исходный текст и параллельно документацию какая есть. /me так разбирал obfuscated? код на С с примесью плюсов, в котором 90% имен функций не превышало трех символов, а переменные - одного. %Е Ужс, тяжело, моск перегревается. ~ 20 тыс. строк. Бывает и хуже. :D

Зачем? Если разобратся как что то работает - проще найти документацию. Если документации нет - дебаггером степом {привет емагз!}. Если драйвер едра - рыдать, плакать, читать документацию, вставлять kprint.

Если впаивать куски к себе - смотреть входы выходы функций.

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

Сильно зависит от самих сырцов и своих знаний в данной области.

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

А так, как уже предлагали выше:

0 Доки по проекту

1 Рисовать графы/схемы чего там и как происходит

2 Гонять в эмуляторе отладчике

3 Найти автора, схватить за причинное место, ткнуть носом в его же сырцы со словами "рассказывай, что тут у тебя и как"

> ? Штука сдохшая, но все еще полезная.

Есть WindRiver SHIFF Pro+, штука коммерческая, но для разбора чужого кода незаменимая.