Як покращити навички читання коду [закрито]

Ну, питання в назві - як я вдосконалюю навички читання коду.

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

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

Детальніше читайте код

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

Вони повинні перевірити ваше знання мови (Java в моєму випадку) врешті-решт.

Чим більше ви читаєте коду, тим більше досвіду накопичуєте, це так просто

Покращуйте своє середовище розробки якнайбільше, щоб воно могло давати вам зворотній зв'язок.

Сучасні IDE можуть допомогти ЛОТі, якщо ви зможете надати їм необхідну інформацію. Приклади:

• Забарвлення синтаксису: Константи в одному кольорі, коментарі в іншому, ідентифікатори в третьому, рядки в четвертому і т. Д. Я нещодавно знайшов фрагмент коду, який був ... дивним ... Виявилося, що змінна була названа як постійним було б - неправильний колір віддав його.
• Ловіть прості помилки компіляції. Більшість мов мають простий синтаксис, якому можна викладати редактор, тому він може заздалегідь повідомити про помилки.
• Ловіть складні помилки компіляції. Багато компіляторів можуть генерувати інформаційні файли, які можна завантажувати у вашу IDE, щоб він знав, скільки аргументів займає дана функція тощо.

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

Також ваш IDE може допомогти вам орієнтуватися на джерело, коли він знає всі ці речі. Це дозволяє вам легко шукати речі, а не запам'ятовувати все

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

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

1. назви змінних, відповідні дужки, імпорт тощо
2. перевірте, чи умови належним чином встановлені, і помилки виявлені
3. все інше - використання функцій тощо.

Я звик кодувати в текстовому редакторі звичайний текст, тому Ctrl + F - мій друг, але IDE дуже корисний, особливо коли ви читаєте з декількох файлів.

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

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

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

Найкращий спосіб дістатися - написати код самостійно. Другий найкращий спосіб - це те, що код просто справді хороший і пояснює себе (якщо це дійсно важко, код просто не так добре)

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

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

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

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

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

Логічні помилки набагато складніше виявити, нехай вони запобігають. Однією з методик запобігання простих випадків є написання одиничних / регресійних тестів.

Одну пораду, яку я почув сьогодні вранці (на SE Radio), було взяти файл і зменшити його до типу 3pt, а потім шукати шаблони в тексті. Ви не зможете прочитати текст, але з’являться всілякі візерунки. Це досить приємний трюк.

І це одне з тих місць, де командний рядок - ваш друг, греп і трубопроводи можуть зробити багато корисного.

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

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

Тож моя пропозиція до вас:

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

Удачі!