Чому налагодження краще в IDE? [зачинено]

Я був розробником програмного забезпечення більше двадцяти років, програмував на C, Perl, SQL, Java, PHP, JavaScript і останнім часом Python. У мене ніколи не виникало проблем, я не міг налагоджувати, використовуючи ретельну думку і добре розміщені printзаяви про налагодження .

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

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

Що я пропускаю? Що робить інструменти налагодження IDE настільки ефективнішими, ніж продумане використання діагностичних printзаяв?

Чи можете ви запропонувати ресурси (навчальні посібники, книги, скріншоти), які показують більш точні методи налагодження IDE?

Солодкі відповіді! Велике спасибі всім, що знайшли час. Дуже освітлююча. Я проголосував багато, і ніхто не проголосував.

Деякі помітні моменти:

• Отладчик може допомогти мені зробити спеціальну перевірку або зміна змінних, коду або будь-який інший аспект середовища виконання, в той час як ручна налагодження вимагає від мене , щоб зупинити, редагувати і повторно запустити додаток (можливо , що вимагає перекомпіляції).
• Налагоджувачі можуть приєднатися до запущеного процесу або використовувати дамп аварійного завершення, тоді як при ручній налагодженні необхідні "кроки до відтворення" дефекту.
• Налагоджувачі можуть легко та більш читабельно відображати складні структури даних, багатопотокове середовище або повний стек виконання.
• Налагоджувачі пропонують безліч способів скоротити час і повторювану роботу, щоб виконати практично будь-які завдання з налагодження.
• Візуальні налагоджувачі та консольні налагоджувачі корисні та мають багато спільних функцій.
• Візуальний налагоджувач, інтегрований в IDE, також надає вам зручний доступ до інтелектуального редагування та всіх інших функцій IDE в єдиному інтегрованому середовищі розробки (звідси назва).

Деякі приклади деяких здібностей, які дасть вам налагоджувач IDE над повідомленнями про сліди в коді:

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

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

Коли я вперше почав кодування, я не міг зрозуміти, у чому полягає велика справа з налагоджувачами, і я подумав, що можу досягти будь-чого за допомогою трасування (дано, що це було на unix, а налагоджувач - GDB). Але як тільки ви навчитеся правильно використовувати графічний налагоджувач, ви не хочете повертатися до друку операторів.

• Налагоджувач IDE дозволяє змінювати значення змінних під час виконання.

• Відладчик IDE дозволяє бачити значення змінних, які ви не знали, що хотіли бачити, коли почалося виконання.

• Налагоджувач IDE дозволяє переглядати стек викликів і вивчати стан функції, що передається дивними значеннями. (думаю, що ця функція викликається з сотень місць, ви не знаєте, звідки беруться ці дивні значення)

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

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

Ось одне, що ви точно не можете налагоджувати за допомогою оператора "print", коли клієнт приносить вам дамп пам'яті і каже, що "ваша програма вийшла з ладу, ви можете мені сказати, чому?"

• Роздрукуйте виписки через ваш код знижує читабельність.
• Додавання та видалення їх лише з метою налагодження займає багато часу
• Налагоджувачі відстежують стек викликів, що дозволяє легко бачити, де ви знаходитесь
• Змінні можна змінювати на ходу
• Команди Adhoc можуть виконуватися під час паузи у виконанні для полегшення діагностики
• Можна використовувати В ЗВ'ЯЗКУ з твердженнями про друк: Debug.Write ("...")

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

З цього приводу, ви дійсно повинні знати, як використовувати налагоджувальний покроковий механізм, оскільки для іншого класу помилок НАРОДНО простіше. Я залишаю це до інших відмінних відповідей, вже розміщених, щоб пояснити чому :)

Вгорі голови:

1. Налагодження складних об'єктів - налагоджувачі дозволяють вам заглибитися у внутрішню частину об'єкта. Якщо ваш об'єкт має, скажімо, масив масиву складних об'єктів, оператори друку отримають вас лише поки що.
2. Можливість переходити до минулого коду - Налагоджувачі також дозволять вам пропустити минулий код, який ви не хочете виконувати. Щоправда, ви можете це зробити і вручну, але це набагато більше коду, який вам потрібно ввести.

В якості альтернативи налагодженню в IDE ви можете спробувати велику розширення PHP-консолі Google Chrome з бібліотекою php, яка дозволяє:

• Див. Помилки та винятки в консолі JavaScript JavaScript та у спливаючих вікнах сповіщень.
• Дамп будь-якої змінної типу.
• Виконайте PHP-код віддалено.
• Захистіть доступ паролем.
• Журнали консолей групи за запитом.
• Перейти до файлу помилок: рядок у текстовому редакторі.
• Скопіюйте дані про помилки / налагодження в буфер обміну (для тестерів).

Я не розробляю вже майже 20 років, але вважаю, що за допомогою IDE / налагоджувача я можу:

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

Однією з причин використання IDE може бути те, що сучасні IDE підтримують більше, ніж прості точки проходу. Наприклад, Visual Studio пропонує такі розширені функції налагодження:

• визначити умовні точки перерви (перерва лише, якщо виконується умова, або лише в n-й раз, коли виконується оператор у точці розриву)
• перерва на необроблений виняток або коли потрібно кинути (конкретний) ексепсив
• зміни змінної під час налагодження
• повторення фрагмента коду, встановивши наступний рядок, який потрібно виконати
• тощо.

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

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

printfналагодження може працювати досить добре, навіть якщо ви використовуєте стандартний налагоджувач (на основі IDE чи ні). Зокрема, із системою реєстрації журналів, щоб ви могли залишити все або більшість у випущеному продукті, щоб допомогти у діагностуванні проблем із клієнтами.

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

На мій досвід, прості роздруківки мають одну величезну перевагу, про яку, здається, ніхто не згадує.

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

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

Так в моєму досвіді. IDE та відладчики - це фантастичний інструмент для вирішення простих проблем, коли щось в одному стеку викликів пішло не так і вивчити поточний стан машини при певній аварії.

Однак, коли ми підходимо до більш складних проблем, пов'язаних із поступовою зміною штату. Наприклад, коли один алгоритм пошкодив структуру даних, це, в свою чергу, призвело до відмови алгоритму Іншого. Або якщо ми хочемо відповісти на запитання на кшталт "як часто це відбувається", "чи все відбувається в порядку та в порядку, як я уявляю, що вони трапляються". і т. д. Тоді "старомодна" техніка лісозаготівлі / роздрукування має очевидну перевагу.

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

Існують також гібридні підходи. Наприклад, коли ви робите console.log (об'єкт), ви отримуєте в журналі журнал даних про структуру даних, який ви можете розширити та детальніше вивчити. Це багато разів явна перевага перед "мертвим" текстовим журналом.

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

Людський мозок на жаль є лише однонитковим.

Оскільки ви попросили вказівники на книги ... Що стосується налагодження Windows, Джон Роббінс має кілька видань хорошої книги про налагодження Windows:

Програми налагодження для Microsoft .NET та Microsoft Windows

Зауважте, що найновіше видання ( налагодження програм Microsoft .NET 2.0 ) - це лише .NET, тому ви, можливо, хочете старішу версію ( наприклад, у першому посиланні), якщо ви хочете налагоджувати нативний код (охоплює як .NET, так і нативну).

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

Легкість , в якій інформація може бути відновлена, що робить їх краще , ніж просто налагодження командного рядка, або «Printf» налагодження.

Переваги налагоджувача над printf ( зверніть увагу не на відладчик IDE, а будь-який налагоджувач )

1. Можна встановити точки спостереження. Це один з моїх улюблених способів пошуку пошкоджень пам’яті

2. Може налагодити двійковий файл, який ви не можете перекомпілювати на даний момент

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

4. Може змінювати змінні під час руху

5. Може викликати функції на льоту

6. Не має проблеми, коли налагоджувальні параметри стану не змиваються, і, отже, проблему з тимчасовим виправленням неможливо налагоджувати акуратно

7. Налагоджувачі допомагають з основними скидами, друкують заяви не '

Це те, що я найбільше використовую у програмах налагодження VS.NET:

• Стек викликів, що також є прекрасним способом з'ясувати чужий код
• Місцеві жителі та годинники.
• Негайне вікно, яке в основному являє собою консоль C #, а також дозволяє мені змінювати змінний вміст, ініціалізувати речі тощо.
• Можливість пропустити рядок, встановити наступний оператор, який слід виконати десь в іншому місці.
• Можливість навести курсор на змінні та мати підказку, що показує мені їх значення.

Підсумовуючи, це дає мені 360-градусний вигляд стану мого виконуючого коду, а не лише маленьке вікно.

Ніколи не знаходив книгу, яка б викладала подібні речі, але знову ж таки, здається, це досить просто, це досить багато WYSIWYG.

• Відладчик може приєднатися до запущеного процесу

• Часто простіше налагоджувати потоковий код з налагоджувача

За допомогою відладчика IDE ви можете бачити значення ВСІХ змінних у поточному діапазоні (аж до стека викликів) кожного разу, коли ви зупиняєте виконання.

Заяви для друку можуть бути великими , але демпінг так багато інформації на екран в будь-якому даному місці можуть призвести цілі багато заяв для друку.

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

Я відчуваю, що налагоджувачі краще для деяких мов, ніж для інших, однак ...

Моя загальна думка полягає в тому, що налагоджувачі IDE абсолютно надзвичайно чудові для керованих мов, таких як Java або C #, досить корисні для C ++ і не дуже корисні для сценаріїв таких мов, як Python (але, можливо, я просто не спробував хорошого відладчик для будь-яких мов сценаріїв поки що).

Я абсолютно люблю налагоджувач в IntelliJ IDEA, коли займаюся розробкою Java. Я просто використовую заяви друку, коли використовую Python.

Як хтось сказав вище: Налагоджувач! = IDE.

gdb та (назад у той день) TurboDebugger (автономний) працює чудово для мов, які вони підтримують [ред], дякую. (або навіть старіша технологія: відладчик Clipper, пов'язаний із самим виконуваним файлом xBase) - жоден із них не потребував IDE

Крім того, хоча C / ++ кодування є більш рідкісним, заяви printf іноді маскують ту саму помилку, яку ви намагаєтесь знайти! (проблеми з ініціалізацією в автоматичній варі на стеку, наприклад, або розподілі / вирівнюванні пам'яті)

Нарешті, як заявили інші, ви можете використовувати і те, і інше. Деякі проблеми в реальному часі майже вимагають друку або, принаймні, розумного "* video_dbg = (is_good? '+': '-');" десь у відеопам'яті. Мій вік показує, це було в DOS :-)

TMTOWTDI

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

Що стосується навчальних ресурсів, я не використовував жодного - я просто вивчаю всі меню та варіанти.

Це навіть справжнє запитання від реального програміста?

Кожен, хто провів навіть 5 хвилин налагодження з друкованими заявами та налагодженням IDE - це OCCUR йому / їй, навіть не запитуючи!

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

Просто хотілося б згадати корисну функцію консольного відладчика проти printf та vs налагоджувача в IDE.

Ви можете приєднатись до віддаленого додатку (обов`язково, складеного в режимі DEBUG) і перевірити його стан, демпінг виводу налагодження у файл за допомогою teeутиліти POSIX . Порівняно з printf, ви можете вибрати, де виводити стан під час виконання.

Це мені дуже допомогло, коли я налагоджував програми Adobe Flash, розміщені в агресивному середовищі . Вам просто потрібно визначити деякі дії, які друкують необхідний стан у кожній точці розриву, запустити конфігураційний налагоджувач консолі fdb | tee output.logта пройти через деякі точки прориву. Після цього ви можете надрукувати журнал і проаналізувати інформацію шляхом ретельного зіставлення стану в різних точках прориву.

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

До речі, моя думка полягає в тому, що варто планувати, де і на що налагоджувати, перш ніж поглянути на налагоджувач.

Ну інша річ, що якщо ви приєднаєтесь до нового старого проекту, і ніхто насправді не знає, як код робить те, що він робить, то ви не можете налагоджувати, повторюючи змінні / об’єкти / ... b / c, ви не маєте поняття, що таке код виконані взагалі.

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

З найкращими побажаннями

Раффаель

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

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

Налагодження в IDE безцінне в умовах, коли журнали помилок та доступ до оболонки недоступні, наприклад, спільний хост. У цьому випадку IDE з віддаленим налагоджувачем - єдиний інструмент, який дозволяє робити прості речі, такі як перегляд stderrабо stdout.

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

Уоу, мені подобається це питання. Я ніколи не наважувався позувати ...

Здається, що у людей просто різні способи роботи. Для мене найкраще це:

• Маю міцну модель розуму свого коду, включаючи управління пам'яттю
• Використовуючи прилади (наприклад, виписки з друку), слідкуйте за тим, що відбувається.

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

Я не кажу, що це добре. Я не кажу, що це погано. Я просто хочу цим поділитися.

Це не просто налагодження. IDE допомагає швидше створювати краще програмне забезпечення різними способами:

• інструменти рефакторингу
• intellisense, щоб зробити api більш відкритим, або нагадати про точне написання / випадок знайомих предметів (не дуже корисно, якщо ви використовували ту саму систему протягом 15 років, але це рідко)
• заощадити на введенні за допомогою автозаповнення імен змінних та класів
• знайти певні види помилок, перш ніж навіть починати збирати
• Автоматично переходити до декларацій / визначень змінних / методів / класів, навіть якщо вони не в одному файлі чи папці.
• Перерва на виправлені та оброблені винятки

Я міг би продовжувати.