Куда вы идете, чтобы прочитать хорошие примеры исходного кода? [закрыто]


53

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


Это было задано в StackOverflow: stackoverflow.com/questions/3083525/…
nikie

3
Я просто оглядываюсь на мой старый код.
Пол

Пол, это не поможет ОП, не так ли? Очевидно, у них нет хорошего кода, уже написанного в прошлом. Sheesh.
Джанки

2
@junky, надеюсь, у них есть чувство юмора, хотя :)
Конрад Моравски

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

Ответы:


30

Вы можете просматривать проекты с открытым исходным кодом на сайтах репозитория, таких как GitHub , Codeplex , Google Code или BitBucket . Вы найдете проекты разных уровней сложности, так что вы сможете найти что-то, что вас заинтересует и поначалу не пойдет слишком много.

Другой вариант - еженедельные публикации в блоге Скотта Хансельмана .

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

Смотреть на кучу чужого кода может быть пугающим, поэтому начните с mainфункции (или эквивалентной) и продолжайте свой путь оттуда.


3
-1: новичок не может различить хороший и плохой код, поэтому «просмотр» проектов не поможет. Вы как бы покрыли это рекомендациями «установленных» проектов, но я видел ужасный код в проектах, о которых мы все слышали. У меня нет лучшего ответа, хотя. На самом деле это сложный вопрос, требующий ответа, адаптированного к уровням навыков, интересам человека и отфильтрованных через знания наставника.
Cris

1
@Cris Я не согласен, но отмечу, что и из плохого кода можно многому научиться. Возможно, чтение и следование плохому коду еще сложнее, чем погружение в правильно организованный проект. (И это прежде, чем мы попытаемся выяснить, что такое «хороший» код. :))
Адам Лир

1
достаточно верно. Но для большинства из нас, не гениев, самообразование имеет пределы. Большинство начинающих (во всех областях) воздействия должны «благо» , чтобы получить ощущение того , что это хорошо. А «Интернет» - это мировой шум «Я хороший!», Который не помогает.
Cris

10

Очень немногие люди пишут хороший исходный код с первой попытки. Хороший исходный код часто создается серией ревизий. Таким образом, если вы можете найти исходный код, который был проверен несколько раз и исправлен несколько раз, вы, вероятно, находитесь в лучшем месте. Некоторые проекты с открытым исходным кодом (и некоторые их части) особенно хорошо рассмотрены. Код от компаний, которые имеют обязательные циклы просмотра (например, Google, но есть много других), может соответствовать всем требованиям.

При этом я не уверен, что ваша цель должна заключаться в том, чтобы найти «отличный код». Нужно взглянуть на разные стили кода (например, написанные вашими коллегами) и научиться определять хорошие и плохие моменты в этом. Чем больше плохих моментов вы выявите, тем больше вы будете стремиться сделать свой код лучше и лучше знать.

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

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


4

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

например, Code Complete, Написание твердого кода, Шаблоны проектирования (я уверен, что есть много других книг в другом вопросе и ответе на этом сайте)

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

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

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


1
Я хотел бы упомянуть «Чистый код» в качестве хорошего ресурса.
Мр

3

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

Хотя вы не хотите начинать с таких мест, как алгоритмы сортировки или сложные контейнерные классы.

Еще одно место для интересных идей при написании кода - Project Euler ( http://projecteuler.net/ ). Небольшой недостаток: сначала нужно решить проблему, чтобы получить доступ к форуму, где другие публикуют свои решения (интересные задачи для всех уровней опыта). Но когда вы закончите, вы найдете примеры почти для всех основных языков программирования. И поскольку вы уже решили проблему, это поможет вам понять код других людей. Плюс вы увидите код языков, которые вы еще не знаете, но можете найти интересным.


3

Мне очень понравилось читать Beautiful Code . У этого есть короткие, но очень хорошие примеры кода с подробными объяснениями.

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

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

Эта книга содержит 33 главы, предоставленных Брайаном Керниганом, Карлом Фогелем, Джоном Бентли, Тимом Бреем, Эллиоттом Расти Гарольдом, Майклом Фезерсом, Альберто Савойей, Чарльзом Петцольдом, Дугласом Крокфордом, Генри С. Уорреном, младшим, Ашишем Гулхати, Линкольном Стейном, Джимом Кентом Джек Донгарра и ПётрЛушчек, Адам Колава, Грег Кроа-Хартман, Диомидис Спинеллис, Эндрю Кучлинг, Трэвис Э. Олифант, Рональд Мак, Рожерио Атем де Карвальо и Рафаэль Моннерат, Брайан Кантрилл, Джефф Дин и Кентон Джонсон Сэнджей Саймон Джэйнджайон Сенджай Джон Сильджай Уильям Джэйджон Симон Джэйджон Уильям Дженгайон Сенджай Джон Сильджай Уильям Дженгайон Сенджай Джонигон, Сэнджи Симбайон, Джек Донгарра и Петр Люшчек, Адам Колава, Грег Кроа-Хартман, Диомидис Спинеллис, Эндрю Кучлинг, Трэвис Э. Олифант, Рональд Мак, Роджерио Атем де Карвальо и Рафаэль Моннерат Отте и Дуглас С. Шмидт, Эндрю Патцер, Андреас Зеллер, Юкихиро Мацумото, Арун Мехта, Т. В. Раман, Лаура Вингер и Кристофер Зейвальд, а также Брайан Хейс ...

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.