Как улучшить свои навыки чтения кода [закрыто]

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

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

Я понял, что то, что действительно мешает прогрессу в разработке, это мои навыки чтения кода. Как улучшить свои навыки чтения кода, чтобы я мог определить большинство ошибок и проблем в коде даже до того, как нажал клавишу «do compile», даже до того, как я запустил отладчик?

Читать дальше код

Я, например, получил несколько приличные навыки чтения кода от чтения сертификационных вопросов, за которыми было очень трудно следовать, потому что они были плохо написаны специально

Они должны проверить ваши знания языка (Java в моем случае) в конце концов.

Чем больше кода вы прочитаете, тем больше опыта вы накопите, это так просто

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

Современные IDE могут помочь много, если вы можете предоставить им необходимую информацию. Примеры:

• Раскраска синтаксиса: константы одного цвета, комментарии другого, идентификаторы третьего, строки четвертого и т. Д. Недавно я нашел фрагмент кода, который был ... странным ... Оказалось, что переменная была названа как константа будет - неправильный цвет отдал его.
• Поймать простые ошибки компиляции. Большинство языков имеют простой синтаксис, которому редактор может научить, поэтому он может заранее предупредить вас, что у вас будут ошибки.
• Поймать сложные ошибки компиляции. Многие компиляторы могут генерировать информационные файлы, которые могут быть загружены в вашу IDE, чтобы он знал, сколько аргументов принимает данная функция и т. Д.

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

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

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

В дополнение к тому, что говорили все остальные, вам нужно терпение, если вы собираетесь читать код (особенно если он не ваш). Да, чтение каждой строки кода наизусть требует практики, но это того стоит, и вы также изучаете стили / приемы кодирования других. Вот что я проверяю по порядку:

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

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

Теперь, если вы тот, кто собирается писать код, не бойтесь ставить пробелы, отступы и комментарии. Честно говоря, если это не выглядит приятным для глаз, это становится болью в голове.

Даже если бы я мог распознать все ошибки до того, как я нажму «сделать компиляцию», я все равно проверил бы это путем тестирования и компиляции. Я бы только доверял положительному тесту и запущенной программе.

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

Лучший способ добиться этого - написать код самостоятельно. Второй лучший способ заключается в том, что код просто действительно хорош и объясняет себя (если он действительно сложный, то код просто не так хорош)

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

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

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

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

Если вы говорите об ошибках компиляции, этого не произойдет. Лучшее решение для ошибок компилятора - назначить человека, который нарушил сборку, сборками «baby-sit», пока кто-то другой не нарушит сборку. Вы сломали это, вы исправили это.

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

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

И это одно из тех мест, где командная строка - ваш друг, grep и конвейеры могут сделать много полезных вещей.

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

Для того, чтобы сделать это хорошо, нам нужно было внимательно следить за этим типом ошибок и уметь «пробовать» код. Этот вид деятельности также познакомил меня со многими стилями кодирования. Сегодня мои навыки чтения кода довольно хороши благодаря этому периоду.

Поэтому я предлагаю вам следующее:

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

Удачи!