Как прочитать код без любой борьбы

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

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

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

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

• Имея дело с экстремальными проблемами, когда работа людей терпит неудачу, вы учитесь исследовать и погружаться во внутреннее устройство любой системы. / language / platform / framework, с которыми вы работаете. Эта исследовательская способность сама по себе очень полезна, когда ничего не помогает. Но ты' Я никогда не узнаю, когда и что начинать искать, пока не разберетесь в грязной работе других людей. Хороший или плохой код - все это ценно в той или иной форме или моде.

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

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

Просто чтобы дать вам немного Воодушевление, я уже 30 лет работаю профессиональным программистом и до сих пор считаю чтение чужого кода очень трудным. Основная причина этого, к сожалению, в том, что качество кода соответствует закону осетровых рыб - 90% это дерьмо. Так что не думайте, что это ваша вина, если вам тяжело!

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

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

Как увеличить мой код навыки понимания / чтения?

Чтение кода похоже на танец в одиночестве. Вам нужен партнер, и я предлагаю отладчик.

Пошаговое выполнение кода с помощью отладчика - это настоящий живой танец. Я рекомендую получить качественный проект с открытым исходным кодом на выбранном вами языке, а затем приступить к работе с отладчиком. Концепции оживут, если вы спросите: «Почему это произошло?», «Что должно произойти дальше?».

В конце концов, человек должен иметь возможность рассуждать о коде без отладчика; не позволяйте этому стать костылем. Но при этом это очень ценный инструмент.

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

Я думаю, что многое из того, что упомянуто здесь , применимо к кодированию ...

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

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

Как увеличить мой код понимание / навыки чтения?

Читать читать читать. Учись на своих ошибках. Просмотрите ответы на SO и в других местах. Когда вы можете вспомнить фрагмент кода, который вы написали, и сказать «ага! Я должен был сделать xyz вместо этого!» тогда вы учитесь. Прочтите хорошую книгу на выбранном вами языке, выйдите за рамки основ и поймите более сложные концепции.

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

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

Также улучшится ли это. качество кода Напишу?

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

Есть ли лучшая нотация кода, чем Венгерский?

Смотря как. Обычно я избегаю их и использую описательные имена. Единственное исключение, в котором я мог бы использовать венгерский тип обозначений, - это элементы пользовательского интерфейса, такие как Windows Forms или элементы управления ASP.NET, например: использование btn в качестве префикса для кнопки «Отправить» ( btnSubmit ), txt для TextBox ( txtFirstName ) и так далее, но он отличается от проекта к проекту в зависимости от подхода и используемых шаблонов.

Что касается элементов пользовательского интерфейса, некоторые Людям нравится сохранять элементы в алфавитном порядке и добавлять тип элемента управления в конце, поэтому предыдущие примеры становятся submitButton и firstNameTextBox соответственно. В Windows Forms многие люди называют формы как frmMain, что на венгерском языке, в то время как другие предпочитают называть его на основе имени приложения или цели формы, например MainForm, ReportForm, и т. д.

РЕДАКТИРОВАТЬ: не забудьте проверить разницу между Apps Hungarian и Systems Hungarian , как упомянул @Tobias Langner в комментарии к более раннему ответу.

Обычно используется Pascal Case используется для имен методов, классов и свойств, где первая буква каждого слова начинается с заглавной буквы. Для локальных переменных обычно используется Camel Case, где первая буква первого слова - строчная, а первые буквы последующих слов - заглавные.

Вы можете проверить соглашения об именах и многое другое из Руководства по проектированию .NET Framework. На MSDN есть книга и некоторые из них .

Есть ли действительно хорошие книги для не забудьте проверить разницу между Apps Hungarian и Systems Hungarian , как упоминалось @Tobias Langner в комментарии к предыдущему ответу.

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

Вы можете проверить соглашения об именах и многое другое из Руководства по проектированию .NET Framework. На MSDN есть книга и некоторые из них .

Есть ли действительно хорошие книги для не забудьте проверить разницу между Apps Hungarian и Systems Hungarian , как упоминалось @Tobias Langner в комментарии к предыдущему ответу.

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

Вы можете проверить соглашения об именах и многое другое из Руководства по проектированию .NET Framework. На MSDN есть книга и некоторые из них .

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

Вы можете проверить соглашения об именах и многое другое из Руководства по проектированию .NET Framework. На MSDN есть книга и некоторые из них .

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

Вы можете проверить соглашения об именах и многое другое из Руководства по проектированию .NET Framework. На MSDN есть книга и некоторые из них .

Есть ли действительно хорошие книги для Шаблоны проектирования C ++ (или язык не имеет значения?)?

Шаблоны проектирования должны быть применимы к любому языку. Как только вы поймете концепцию и аргументы в пользу полезности этого шаблона, вы сможете применить его на выбранном вами языке. Конечно, не подходите ко всему с позиции «высеченного в камне»; шаблон - это цель, реализация может немного отличаться для разных языков в зависимости от доступных вам языковых функций. Возьмите, к примеру, шаблон декоратора , и посмотрите, как методы расширения C # позволяют реализовать его иначе, чем без него .

Книги шаблонов проектирования:

Шаблоны проектирования Head First - хорошее вступление для начинающих, использующих Java, но код для C ++ и C # доступен для загрузки (см. Раздел «Код книги и загрузки» на книге ' s site )

Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования - классическая группа четырех (GOF)

Шаблоны архитектуры корпоративных приложений ​​- Мартин Фаулер

Если вы ' если вы ищете передовой опыт для качественного кодирования на C ++ и C #, то поищите книги « Эффективный C ++ » и « Более эффективный C ++ » (Скотт Мейерс) и « Эффективный C # "и" Более эффективный C # "книги (Билла Вагнера). Однако они не будут держать вас за руку на пути, поэтому вы должны понимать язык в целом. В серии «Эффективные» есть и другие книги, поэтому убедитесь, что вы знаете, что доступно для ваших языков.

I '

В настоящее время я читаю шаблоны проектирования Head First, и они очень полезны. Он представляет информацию новым, легким для понимания способом. Приятно видеть, что у них есть версия C # для загрузки.

Всегда будут проблемы с чтением кода, если вы не Джон Скит. Это не значит, что это большая проблема, скорее, если вы не можете есть, спать и дышать на этом языке программирования, на переваривание кода всегда уйдет немного времени. Взгляд на код других людей, безусловно, является хорошим предложением для помощи в некоторых отношениях, но помните, что существует множество различных соглашений о кодировании, и некоторые из них могут быть более строгими, чем другие, например, имена интерфейсов начинаются с I, чтобы дать простой пример. Итак, я думаю, я говорю, что даже с Visual Studio и Resharper,

Я обнаружил, что эта статья о Джоэле о программном обеспечении очень важна для обсуждения венгерской нотации.

Похоже, что первоначальная цель нотации заключалась в кодировании типа информация, которая не была очевидна сразу - не является ли переменная типом int (iFoo), а каким видом int она является - например, расстояние в сантиметрах (cmFoo). Таким образом, если вы видите «cmFoo = mBar», вы можете сказать, что это неверно, потому что, хотя оба являются целыми числами, один - в метрах, а другой - в сантиметрах, и, таким образом, логика оператора неверна, даже хотя синтаксис в порядке. (Конечно, я лично предпочитаю использовать такие классы, чтобы этот оператор даже не компилировался или выполнял преобразование за вас).

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

Каждый должен прочитать эту статью- Как сделать неправильный код неправильным

1) Самообразование. Прочтите соответствующую литературу. 2) Напишите код 3) Прочитать код 4) Читайте соответствующие блоги. Посетите http://hanselminutes.com . Он программист из Microsoft. Даже если вы не программируете в стеке Microsoft, это полезно прочитать. Там есть подкаст, который отвечает на этот вопрос.

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

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

Есть много хороших редакторов с открытым исходным кодом, включая Eclipse и CDT .