Интерпретация чужого исходного кода [закрыто]

Примечание. Мне известен этот вопрос. Этот вопрос немного более конкретен и углублен, однако сосредоточен на чтении реального кода, а не на его отладке или обращении к автору.

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

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

Обычно я сначала проверяю общие ошибки - пропущенные точки с запятой или круглые скобки, использование запятых вместо операторов экстрактора и т. Д.

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

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

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

Второй шаг: Автоформатировать весь код в удобном для вас формате. Вы могли бы подумать, что это не имеет большого значения, но удивительно, это имеет значение.

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

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

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

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

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

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

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

Помните, что для начинающего студента могут быть некоторые артефакты редактирования, которые будут препятствовать компиляции программы, которые не будут видны. Например, однажды я увидел студента (не одного из моих), который использовал пробел вместо возврата: его код выглядел нормально на редакторе, который переносился после 80 столбцов (студент был очень терпеливым), и код даже работал, пока он не добавил //комментарий в стиле " ", который закомментировал всю остальную часть программы. Точно так же, если вы копируете примеры кода с веб-сайта, часто появляются непечатные символы, которые также копируются (в зависимости от того, как сайт отформатировал код). Если вы сомневаетесь, повторите строку без копирования и вставки. [Это удивительно, но я видел, как это происходит намного позже.]

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

Хорошо, а что если нет синтаксических ошибок? Тогда пришло время пройти через код! Для этого вы можете использовать отладчик, но использование вызовов printfв коде также очень эффективно. Например, если есть forцикл, добавьте оператор print для счетчика цикла. В случае вложенных forциклов вы можете обнаружить, что неверная переменная увеличивается.

Преимущество использования printfs заключается в его способности «сжимать» во времени / пространстве то, на что вы сейчас смотрите. Когда вы проходите через отладчик, вы также видите много неуместного состояния, и оно может быть более утомительным. Кроме того, не видя истории того, что было напечатано на консоли, вы можете пропустить некоторые шаблоны. Дело в том, что отладчик и printfs являются взаимодополняющими методами, и ни один из них не всегда лучше, чем другие.

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

Как отмечалось в другом месте, все это становится лучше с опытом. Несмотря на то, что я программирую в течение 20 лет, только за последние 5 лет, когда я работал со студентами, я стал лучше помогать им с их ошибками.

Ненавижу это говорить, но здесь нет серебряной пули.

Честно говоря, если бы я был достаточно ясновидящим, чтобы понять, что имели в виду другие, когда они писали о том, что делали, даже в 10% случаев, я бы без тени сомнения заработал миллионы к настоящему времени.

С практической точки зрения, использование интеллектуальной IDE - это шаг 1.

Шаг 2 будет запускать doxygen или что-то подобное, чтобы выяснить иерархию исходного кода.

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

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

Одним словом: опыт, чем больше вы набираетесь опыта, тем больше вы узнаете о лучших практиках и можете судить / понимать код других людей. Это не происходит автоматически, а часто происходит только из-за того, что вы сами совершаете ту же ошибку!

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

Меня часто спрашивали то же самое в лаборатории в школе. Обычно вопрос начинался с "Как я могу исправить эту ошибку компилятора?" так что я довольно хорошо различал висячие else, пропущенные точки с запятой и тому подобное. (Макросы тоже весело отлаживать -#define CUBE(x) x * x * x это ошибка, которую нам всем суждено сделать.) У меня было преимущество в том, что я проходил одни и те же занятия с теми же учителями, поэтому я уже был знаком с требованиями.

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

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

Синтаксические ошибки намного легче найти, чем логические ошибки. Если большинство проблем связано с синтаксисом, найдите среду IDE, скопируйте и вставьте в нее свой код и исправьте ошибки. Логические ошибки гораздо сложнее. Я не уверен, почему вы говорите, что не можете попросить их объяснить их код. Я обнаружил много логических ошибок, объясняя код кому-то еще.