Інтерпретація вихідного коду інших [закрито]

Примітка: мені відомо це питання. Це питання дещо конкретніше та поглибленіше, однак зосереджене на читанні фактичного коду, а не налагодження його чи питанні автора.

Будучи студентом початкового класу з інформатики, мої друзі періодично просять мене допомогти їм у виконанні завдань. Програмування - це те, чим я дуже пишаюся, тому завжди раджу зобов’язатись. Однак у мене зазвичай виникають труднощі з інтерпретацією їх вихідного коду.

Іноді це пов’язано з дивним чи непослідовним стилем, іноді це пов’язано з дивними вимогами до дизайну, визначеними у дорученні, а іноді це просто через мою дурість. У будь-якому випадку, я в кінцевому підсумку виглядаю як ідіот, який кілька хвилин дивиться на екран, кажучи: "А-а ..."

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

Біда виникає, коли це не вдається. Я часто не можу перейти через відладчик, оскільки це синтаксична помилка, і я часто не можу запитати автора, оскільки він / вона сам / сам не розуміє дизайнерських рішень.

Як ти зазвичай читаєш вихідний код інших? Читаєте ви код зверху вниз чи дотримуєтесь кожної функції, як вона називається? Звідки ти знаєш, коли сказати "Пора рефактор?"

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

Другий крок: Автоматичне переформатування всього коду у форматі, в якому ви відчуваєте себе комфортно. Ви можете подумати, що це не має великого значення, але дивно, але це так.

Не бійтеся перейменовувати локальні змінні, якщо вони погано названі. (Якщо у вас є доступ до повної системи, ви можете перейменувати все, що завгодно.)

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

Будьте терплячі. Зрозуміти чужорідний код непросто, але завжди є переломний момент, коли більшість фрагментів головоломки раптом потрапляють на місце. До цього моменту я боюся всієї важкої праці та зухвалості. Хороша новина полягає в тому, що з практикою цей момент еврики настане швидше.

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

Я вважаю, що ця здатність є сукупністю досвіду та просто маючи для цього талант. У нас були співробітники, які могли вирішити більш-менш що-небудь, якби ми попросили їх зробити щось з нуля, в той же час абсолютно не в змозі знайти очевидних помилок у шматочках коду, які вони не написали. І водночас у нас були співробітники, яким ми не довіряли б нічого, що перевищує базовий дизайн, але які могли зануритися в інший код і відстежити проблеми в найкоротші терміни.

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

По-перше, якщо є синтаксичні помилки, вам просто потрібно уважно прочитати помилки компілятора. Часто рядок виділяється як помилка, але помилка була насправді в попередньому рядку.

Майте на увазі, що для вступного студента можуть бути деякі артефакти редагування, які не дозволять програмі складати програму, яку неможливо побачити. Наприклад, я одного разу бачив студента (не одного мого), який використовував пробіл замість повернення: його код виглядав нормально на редакторі, який загортався після 80 стовпців (студент був дуже терплячим), і код навіть працював, поки він не додав А " //« -стиль коментар, який закоментувавши всі інші програми. Так само, якщо ви копіюєте зразки коду з веб-сайту, часто є недруковані символи, які теж копіюються (залежно від того, як веб-сайт відформатував код). Коли ви сумніваєтесь, повторно введіть рядок без копіювання та вставлення. [Це щось дивно, але останнім часом я бачив це набагато більше.]

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

Гаразд, а що робити, якщо немає синтаксичних помилок? Тоді саме час переступити через код! Ви можете використовувати для цього налагоджувач, але виконувати дзвінки наprintf весь код також є високоефективним. Наприклад, якщо є forцикл, додайте у друкований вислів для лічильника циклу. У разі вкладених forциклів ви можете виявити, що неправильна змінна збільшується.

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

Нарешті, просто запитайте свого друга, що відбувається! Замість того, щоб дивитись на це і говорити «е-е», запитайте їх, що вони роблять: «тепер що робитьn робити?" Запустивши діалогове вікно, вони можуть відповісти на власне запитання, або, можливо, ви зрозумієте, як вони осмислили програму, мали недолік, який може привести вас до рішення.

Як коментується в іншому місці, все це покращується з досвідом. Незважаючи на те, що я програмував 20 років, лише за останні 5 років, коли я працював зі студентами, я став краще допомагати їм у їх помилках.

Я ненавиджу це говорити, але тут немає срібної кулі.

Відверто кажучи, якби я був досить ясновидцем, щоб можна було зрозуміти, що означають інші коли вони писали те, що робили навіть у 10% випадків, я б без відтінку сумнівів вже заробив мільйони.

Більш практична примітка - використання інтелектуального IDE - це крок 1.

Крок 2 - це запуск доксигену або щось подібне, щоб з'ясувати ієрархію вихідного коду.

Крок 3 - це знайти якірні функції або об'єкти, речі, які обробляють ваш командний рядок або файл, а потім виконують логіку.

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

Одним словом: досвід, чим більше ви набираєтеся досвіду, тим більше ви дізнаєтесь кращих практик і зможете судити / розуміти код інших людей. Це не приходить автоматично, натомість часто виникає лише те, що ви робите ту саму помилку!

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

Мене часто запитували в школі в лабораторії. Зазвичай питання починається з "Як виправити цю помилку компілятора?" так що я досить добре помітив балаканини else, відсутні крапки з комою тощо. (Макроси також цікаві для налагодження -#define CUBE(x) x * x * x це помилка, якій ми всі судилися зробити.) Перевагою, яку я мав, було те, що я пройшов ті ж класи з тими ж вчителями, тому я вже був ознайомлений з вимогами.

Процес, за яким я найкраще працював, - це підтримувати запущений діалог. Ви не хочете писати програму для них, оскільки саме вони повинні навчитися. Це означає, що ви повинні бути за одним комп'ютером з ними. У лабораторії я б зайшов до їх комп'ютера. Я б спробував змусити їх помітити помилку, починаючи з повідомлення компілятора. (Ми використовували C.) Почніть з номера рядка та вкажіть, де відповідають повідомлення та помилка. Якщо є одна і та ж помилка, я б запитав їх, що було подібним щодо двох помилок.

Вся ідея полягає у тому, щоб допомогти орієнтуватися на іншого учня. Переписання коду для них не допоможе їм навчитися.

Помилки синтаксису набагато простіше знайти, ніж логічні помилки. Якщо більшість їх проблем є синтаксисом, знайдіть IDE, скопіюйте та вставте в нього свій код та виправте помилки. Логічні помилки набагато складніше. Я не впевнений, чому ви кажете, що не можете просити їх пояснити свій код. Я знайшов багато логічних помилок, пояснюючи код комусь іншому.