Программы, игры и их исходные коды
Чтобы сделать важный шаг в разработке, необходимо просмотреть много литературы, протестировать множество вариантов программного кода. В таких случаях ускорит разработку рабочий исходник.
Исходники
Исходники игр, приложений, сетевых программ, сайтов. Подробно описывается программный код и алгоритм.
Исходный код часов со стрелками на С++
Часы корректируют размеры своих «запчастей» цифр, стрелок, надписей. Исходник построен на базе MFC. Приложение может быть использовано в качестве ч.
Веб сервер IIS, запуск и настройки
IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP. IIS сервер позволяет использовать для сайтов программирование на ASP.NET, PHP, Python, баз.
WPF. Практика трансформаций
В приложениях WPF можно трансформировать всё что угодно. Визуальные элементы, контейнеры с дочерним содержимым, кисти, рисованные объекты и даже те.
Простой 3D движок DirectX с помощью MFC
На примере полета сквозь звезды, шаг за шагом, создается 3D движок DirectX. Исходник С++ 3D программы, способной выдержать изменения режимов показа.
О программировании
Статьи тематики программирование. Инструменты программирования. Рассуждения новичков и профессионалов
Программы и игры
Приложения, утилиты, логические и развлекательные игры
TransK v1.1
Программа для расчета трансформаторов. Облегчает нудный расчет витков, очень простая в эксплуатации. В помощь радиолюбителям и электротехникам.
Игра для сборки фишек в линии LinesK
Занимательная головоломка для гимнастики ума. Необходимо геометрические фигуры собирать в линии наименьшим количеством ходов. До окончания игры набрать как м.
EasyReplaceText v2.0
Инструмент для вебмастеров и не только. Когда файлов множество, то замена фрагментов текста станет долгой и кропотливой работой. Программа существенно облегч.
CompoundFK v2.0
Программа создания и редактирования составных файлов. Внутри одного файла вы можете разместить целую файловую систему. Уникальными возможностями заинтересует.
Программирование с нуля
Данная статья описывает основные конструкции в программировании и предназначена для тех, кто хочет в этом разобраться. Но статья не описывает все нюансы, потому что их слишком много. Если описывать их все, будет очень нудно и непонятно.
Использовать будем си-подобный синтаксис, то есть подобный языку си, но не будем вникать в заголовочные файлы, указатели и другие особенности относительно низкоуровневых языков, перейдём на синтаксис более высокоуровневых языков, которые сделают рутинную работу за нас. А конкретно, будем использовать синтаксис языка Java. Добро пожаловать под кат.
Двоичная система счисления
Числа в двоичной системе счисления состоят всего из двух знаков. Нуля и единицы. 00000001 – число один. 00000010 – число два. 00000100 – число 4. Как вы можете заметить, когда единица смещается влево, число увеличивается в два раза. Чтобы получилось число 3, необходимо написать 00000011. Таким образом можно составить все необходимые числа. В данном примере мы использовали двоичное число с восемью знаками, иначе говоря число восьмиразрядное. Чем больше у числа разрядов, тем большее оно может вместить значение. Например, восьмиразрядное число вмещает максимальное значение 255, если считать ноль, тогда 256, а в программировании ноль считается всегда. Если увеличить разряд на один, получится девятиразрядное число и его вместимость увеличится в два раза, то есть станет 512. Но так в программировании никогда не делается и обычно каждая следующая разрядность увеличивается вдвое. Один разряд, потом 2 разряда, потом 4 разряда, потом 8 разрядов, потом 16 разрядов, потом 32 разряда и далее.
Шестнадцатеричная система счисления
Всё аналогично двоичной, только вместо нулей и единиц участвуют цифры от 0 до 15. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, где A – 10, B – 11, C – 12, D – 13, E – 14, F – 15.
Знак минус в программировании
Буквы и знаки
Буквы, знаки, смайлики и так далее обозначаются также числами. Буква А может быть числом 00000001 или любым другим, или даже комбинацией чисел в зависимости от кодировки символов. Кодировок много.
Типы данных
В программировании есть типы данных. Числовые, такие как 233, которые разобрали выше. Называются почти везде int, от слова integer. С плавающей запятой, такие как 198,76, называются почти везде float. У букв тип char, у строк тип String. Тип bool имеет два значения – истина (true) и ложь (false). У этого типа реализация в разных языках разная, но самая простая, когда ноль — значит ложь, а любое другое число истину. Нестандартные типы данных, такие как числа с фиксированной запятой, рассматривать не будем.
Применение
Прежде чем использовать числа в программировании их нужно объявить, то есть сказать с помощью языка программирования, что они существуют.
Это стандартное объявление примитивного типа.
Сначала пишем тип, потом имя переменной, то есть нашего числа. Всегда заканчиваем наше выражение, да и любое, точкой с запятой.
Теперь мы можем использовать переменную по её имени.
Здесь мы присвоили переменной значение. В отличии от математики в программировании = значит взять значение справа и присвоить переменной слева. = — это знак/оператор присвоения.
Можно объединить объявление и присвоение, то есть сразу инициализировать переменную.
Буквы выделяются одинарными кавычками, строки выделяются двойными кавычками. Числа типа int не выделяются.
К числам с плавающей запятой одинарной точности в конце добавляется f.
К числам с плавающей запятой двойной точности ничего не добавляется.
Операторы
После того как мы записали наше выражение, например сложения,
получается значение. Но так как оно ни одной переменной не присваивается, оно исчезает. Чтобы присвоить значение переменной используется специальный оператор присвоения, который коротко описан выше.
Повторим ещё раз. Он берёт значение со своей правой стороны и присваивает его переменной в левой стороне. Это оператор =, и он не имеет ничего общего со знаком равно из математики.
Также у нас есть логические операторы, такие как (больше),
Описание и образцы кода
У документации для разработчиков есть тенденция включать большое количество примеров кода. Примеры кода могут быть не включены в конечные точки, которые документируются. Но по мере того, как будут создаваться задачи и более сложные рабочие процессы, касающиеся того, как использовать API для достижения различных целей, будут использоваться разные конечные точки в которых будет указываться, как решать различные сценарии. Руководства по коду являются важной частью руководства пользователя.
Образцы кода играют важную роль, помогая разработчикам использовать API. Код является другим языком, и когда пользователи, использующие этот язык, видят его, они получают гораздо больше, чем от простого текста (каким бы хорошим ни было описание).
Код написан на другом языке, поэтому, как ни стараться описать общение на таком другом языке с помощью текста, все часто оказывается неэффективным. Разработчики понимают код гораздо лучше, чем текст
В ходе пользовательского тестирования документации, проведенного Twilio, было обнаружено, что страницы, имеющие примеры кода, удобнее пользователям.
В Twilio обнаружили, что когда у страниц было меньше предложений перед примерами кода, страницы привлекали пользователей больше
В частности, страницы с менее чем 4 предложениями перед примерами кода выполняются дважды также, как и страницы с 11 предложениями перед примерами кода. Jarod Reyes объясняет:
Дело больше в умственном блоке, чем в неспособности видеть код. Текст сообщает разработчику, что этой странице есть, что сказать, и что у него (разработчика) много работы. Разработчики не будут тратить время на чтение того, что вы хотите сказать. Мы видели это по всем разделам; мы видели это на всех страницах. Всякий раз, когда на странице много прозы и не так много кода, такая страница хорошо не работает. (Как Twilio пишет документацию)
Дело не только в адресной документации
Иногда разработчики хотят избегать включения примеров кода в документы API, поскольку считают, что адресная документация по конечным точкам содержит всю информацию, необходимую разработчикам. Однако эта точка зрения часто недальновидна. В статье о программируемой сети под названием Шесть столпов полной документации для разработчиков авторы объясняют:
В то время как руководство разработчика должно помочь понять основные принципы использования API и его функциональных возможностей, оно не может охватить все возможные варианты использования этого API согласованным образом. Именно здесь появляются статьи и учебные пособия, чтобы научить разработчиков касательно или специализированному использованию API, например сочетать его с другим сервисом, фреймворком или API.
Другими словами, статьи и учебные пособия дополняют адресную документацию для предоставления полной инструкции. Примеры кода, которые показывают, как использовать различные конечные точки для достижения цели, занимают важное место в руководстве пользователя.
Кроме того, даже если включать примеры кода, уровень детализации и объяснения также может быть спорным. Многие разработчики предполагают, что аудитория имеет набор навыков, схожий с их собственным, без признания различных специализаций разработчиков. И поэтому они добавят пример кода, но не будут давать никаких объяснений по этому поводу. Внутренние разработчики часто говорят: «Если пользователь не понимает этот код, то и использовать наш API не стоит».
Если вы сталкиваетесь с таким отношением, напомните разработчикам, что пользователи часто имеют технические знания в разных областях. Например, пользователь может быть экспертом по Java, но только слегка знаком с JavaScript. Кто-то, кто является программистом базы данных, будет иметь другой набор навыков, чем тот, кто является программистом Python, у которого будет другой набор навыков и т.д. Учитывая эти различия и вероятную вероятность того, что у вас будет много начинающих (или незнакомых) пользователей, необходимы более обширные учебные руководства и пояснения.
Фокус на “Почему?” а не “Что?”
Например, вот разница:
Добавляем комментарии к коду и пояснения “до и после”
Комментарии в коде обычно представляют собой короткие однострочные заметки, которые появляются после каждых 5-10 строк кода. Можно дополнить код более подробными объяснениями в своей документации, но лучше всего разбавить примеры кода комментариями, потому что он помещает объяснение рядом с кодом, выполняющим действие. Такой подход добавления кратких комментариев в коде, сопровождаемый более здравыми объяснениями после кода, согласуется с принципами постепенного раскрытия информации, которое помогает как опытным, так и начинающим типам пользователей. В этом случае постепенное раскрытие информации означает, что вы предоставляете некоторые подробности в контексте действия, а затем добавляете ссылки для получения дополнительной информации, если это необходимо пользователю.
Разве не будет несколько избыточным писать комментарии, перемежающиеся в коде, а также в разделах до или после кода? На самом деле, нет. Некоторые исследования о том, как разработчики используют документацию, обнаружили, что существует два распространенных поведения: разработчики, которые начинают с кода и читают концептуальную документацию высокого уровня только по мере необходимости (так называемое «оппортунистическое» поведение). И разработчики, которые начинают с концептуальной документации более высокого уровня, прежде чем переходить к коду (так называемое «систематическое» поведение). Майкл Мэн, Стефани Штайнхардт и Андреас Шуберт объясняют:
Как только сформировалось понимание уровня и функций API, появились два разных пути, которые очень похожи на «систематических» и «оппортунистических» личностей разработчиков, описанных Clarke (2007) (см. Также Stylos, 2009). По словам Кларка (2007), систематические разработчики работают сверху вниз в том смысле, что они пытаются глубже понять систему в целом, прежде чем переходить к отдельным компонентам. С другой стороны, цели обучения оппортунистических разработчиков уже сфокусированы на решении конкретной проблемы и зависят от конкретных проблем и блокировщиков, с которыми они сталкиваются при работе над решением (“Документация интерфейса прикладного программирования: чего хотят разработчики программного обеспечения?: технического письма и коммуникации”. 2018, том 48 (3) 295–330. ResearchGate)
Для оппортунистического разработчика, который сначала запускает код, комментарии в коде могут быть полезнее документации. Но не все начинают с кода. Некоторые предпочитают сначала читать документацию.
Дополнительные сведения о том, как документировать код, см. В статье «Когда не следует комментировать: вопросы и компромиссы с документацией API для проектов C ++», написанной Эндрю Хедом, Кейтлин Садовски, Эмерсоном Мерфи-Хиллом и Андреа Найт (2018 ACM / IEEE 40-я Международная конференция по Программная инженерия. ResearchGate). Исследователи выясняют, где более склонны искать разработчики: в верхнеуровневых файлах (где появляются более формальные описания класса и методов) или в коде реализации документации (они сосредоточены на C ++). В некоторых случаях чтение кода реализации напрямую обеспечивает более ясный путь к пониманию для разработчиков. Кроме того, некоторые разработчики не доверяют актуальности документации и поэтому предпочитают смотреть на код напрямую. Однако для более сложного кода было полезно учиться на более сложной документации верхнеуровневых файлов.
Делаем примеры кода простыми
Примеры кода должны быть сокращены до их самой простой формы. Предоставление кода для всей HTML-страницы, вероятно, не требуется. Но включение некоторого окружающего кода никому не повредит, а для новичков может помочь им увидеть общую картину. (Также легче копировать и вставлять.)
Кроме того, избегайте включения большого количества стилей или других деталей в код, которые потенциально отвлекут аудиторию от основного момента. Чем минималистичнее пример кода, тем лучше. Например, если вы демонстрируете простую функцию JavaScript, у вас может возникнуть желание поддержать ее с помощью тщательно разработанного стиля CSS, чтобы демонстрация выглядела четко. Тем не менее, весь дополнительный CSS будет только вносить больше сложности и путаницы, которые конкурируют с оригинальным принципом, который вы пытаетесь показать с примером кода.
Когда разработчики интегрируют код в производственную среду, они, вероятно, внесут какие-то изменения, учитывая масштабирование, многопоточность и эффективность, а также другие факторы производственного уровня.
Делаем удобные примеры кода для “копипасты”
Часто разработчики копируют и вставляют код непосредственно из документации в свое приложение. После чего правят его под свои конкретные параметры или методы.
В идеале, нужно протестировать все примеры кода самостоятельно (или внедрить более надежный процесс для тестирования кода). Тестирование позволяет выявлять ошибки, понимать, являются ли все параметры полными и действительными, и многое другое. В видео от Twilio авторы говорят, что они хотели обрабатывать примеры кода в документации как их другой инженерный код, поэтому они хранили свой код в отдельном контейнере (также помещенном в GitHub) для выполнения регулярных тестов. Они вставили код в свою документацию. Для длинных примеров кода можно рассмотреть возможность хранения кода на GitHub. Таким образом, инженеры могут легче тестировать его как часть своих тестов для каждого выпуска. Иногда, когда блоки кода скрываются в документации, они теряются в новых релизах.
Предоставляем образец на целевом языке
REST API позволяет разработчикам использовать практически любой язык программирования для выполнения запроса. Неизбежно возникнет один вопрос: следует ли показывать примеры кода, охватывающие несколько языков? Если да, сколько языков?
Каждый пример предоставленного кода должен быть протестирован. При обновлении API, нужно будет обновлять каждый из примеров кода на используемых языках. Когда API выдвигает новую версию, нужно проверять все примеры кода, чтобы убедиться, что код не нарушает изменения в новой версии (это называется «регрессионное тестирование» на языке QA).
Примеры описания кода
Ниже приведены несколько примеров разделов с примерами кода в документации API.
Weather Underground
В этом примере Weather Underground есть несколько примеров кода на нескольких языках, но нет объяснения того, что возвращает пример кода. В этом случае код, достаточно прост, чтобы разработчики могли посмотреть на него и понять из самого кода, что происходит. Тем не менее, некоторые объяснения обычно оправданы, особенно если есть несколько способов сделать запрос.
Иногда разработчики могу говорить, что код «самодокументируется», то есть из самого кода видно, что происходит. Без знания языка программирования трудно оценить это утверждение. Если столкнуться с таким выражением, нужно рассмотреть возможность проверки этого утверждения у других разработчиков, особенно вне группы разработчиков продукта (или с пользователями, если к ним есть доступ).
Eventful
Здесь не видно примеров кода, но документы Eventful содержат различные примеры параметров строки запроса для конечных точек. Хотя эти параметры также определены в их справочной документации для конечной точки поиска, этот раздел раскрывает, как использовать параметры более удобным и подробным способом.
У Eventful хорошее описание в разделе, оно показывает, как документация, которая обычно содержится в справочном материале, может быть извлечена и объяснена более подробно с помощью примеров. Это показывает больше разницы между справочной и учебной информацией.
Twilio
Раздел “Примеры кода” Twilio, пожалуй, самый впечатляющий и имеет самые подробные описания из приведенных здесь примеров. Они не только проводят пользователей от начала до конца, но и представлены на многих языков. Конкретные примеры кода расположены в правую колонку, в то время как описательная часть раздела занимает среднюю колонку. Все шаги не сразу отображаются в разделе. При достижении одного конца шага, нужно нажать кнопку, чтобы показать следующий шаг. Такое постепенное раскрытие информации может уменьшить чувство страха, которое могут испытывать пользователи в начале работы.
Mailchimp
Как обычно, Mailchimp предоставляет полные описания своих продуктов. В разделе «Перед началом работы» перечислены все необходимые предварительные условия перед началом работы. Каждая часть раздела выделяется заголовками.
Выделение разделов заголовками более приемлемо, чем нумерованные списки (шаги). Большинство технических писателей используют нумерованные шаги в качестве привычки в технических документах, поэтому, когда они начинают писать описание кода, первое желание состоит в том, чтобы пронумеровать шаги. Но в разделе описания кода могут быть длинные примеры кода, за которыми следуют подробные объяснения и так далее. Ведение пронумерованных шагов может стать обременительным. Заголовки разделов обеспечивают менее проблематичное форматирование, и по-прежнему можно вводить заголовок каждого раздела с помощью «Шаг 1», «Шаг 2» и т.д.
IBM Watson
Пример кода для API прогноза погоды
В примерах кода ниже показано, как использовать конечную точку surfreport для получения высоты прибоя для определенного пляжа.
В этом примере используется метод ajax из jQuery, поскольку он позволяет асинхронно загружать удаленный ресурс.
В запросе мы отправляем авторизацию в URL строки запроса. Конечная точка ограничивает количество дней, возвращаемых к 1, для увеличения скорости загрузки.
Мы получаем только высоту прибоя, но есть много других данных, которые можно выбрать для отображения.
Можно объяснить детали более подробно, даже построчно просматривая код, но здесь комментарии уже составляют примерно половину длины кода. Присутствуют комментарии и в самом коде. Комментарии больше относятся к вопросу «почему?», а не «что?».
Документирование кода может быть одним из самых сложных аспектов документации. Часть проблемы заключается в том, что код не организован таким образом, что построчное (или блочное) описание не имеет смысл. Переменные часто определяются в первую очередь, вызываются функции, которые определены в другом месте, да и многие другие аспекты также являются нелинейными. Объясняя логику, можно обнаружить, что приходится прыгать по разным местам кода, не обязательно перемещаясь сверху вниз.
Для более глубокого понимания того, как документировать примеры кода, см. презентацию автра курса «Создание примеров кода для документации API / SDK».
👨💻 Практическое занятие: примеры кода
В своем найденном опен-сорс проекте найдем примеры кода в API документации. Ответим на следующие вопросы:
Исходный код и его 11 составляющих
Теперь, когда вы понимаете концепцию программирования, мы рассмотрим исходный код – его главные составляющие и принципы работы с ними.
Часть 2 – Исходный код
В предыдущей части мы затронули азы программирования, где рассказали о машинном языке, преобразователях, языках программирования и работе с CLI. Двигаемся дальше.
Исходным кодом называется основной файл вроде Microsoft (.doc), но немного другой. Это текстовый файл, написанный с помощью простых редакторов, таких как Windows Блокнот. В предыдущем разделе мы перечислили, что нужно, чтобы интерпретаторы или компиляторы конвертировали исходный код в двоичный. Первый должен быть сохранен в файле, что передается для ввода в переводчик (преобразователь).
Когда вы закончите писать код, запустите его через переводчик. Рассмотрим в качестве примера запуск кода на языке Python с использованием команды python.
Начало работы: ваша первая программа
3. Откройте в нем новый файл и введите следующее:
Результат должен выглядеть так:
Анатомия типичного кода
Теперь мы рассмотрим содержимое типичного файла исходного кода. Ниже приведены регулярные компоненты.
Ключевые слова
Короткие человекочитаемые слова, обычно называемые ключевыми. Они свойственны изучаемому вами языку и они особенны. Их просто нужно знать. Вот небольшой набор ключевых слов, часто используемых в Python.
Идентификаторы
Слова, изобретенные вами. Да, не удивляйтесь! Вы, программист. Эти слова обычно называются идентификаторами. Они могут быть созданы вами или другими программистами. Они упакованы в плагины, более известные как библиотеки.
Примером является библиотека Math. Она позволяет получить доступ к функциям, таким как квадратный корень (Math.sqrt), используемый в JavaScript.
Многие языки программирования поставляются со множеством библиотек. Они обычно называются SDK (комплекты разработки программного обеспечения). Загружаются вместе с компилятором для дальнейшего создания технологий, приложений и проектов. Также существуют фреймворки, созданные, чтобы облегчить разработку проекта и объединить его различные составляющие.
Некоторые идентификаторы в комплекте с выбранным языком не могут использоваться в качестве идентификатора пользователя. Примером является слово string в Java. Такие идентификаторы вместе с ключевыми словами называются Зарезервированными Словами. Они также являются особыми.
Все ключевые слова являются зарезервированными. Также слова, которые вы выбираете, должны иметь смысл для тех, кто впервые их видит.
Основные типы данных
Целые числа могут быть знаковыми и беззнаковыми, большими и малыми. Последние фактически зависят от объема памяти, зарезервированного для таких чисел. Есть числа с десятичными частями, обычно называемые double и float, в зависимости от языка, который вы изучаете.
Также существуют логические типы данных boolean, которые имеют значение true или false.
Сложные типы данных
Указанные выше типы известны как элементарные, первичные или базовые. Мы можем создавать более сложные типы данных из приведенных базовых.
Массив (Array) – это простейшая форма сложного типа. Строка (String) – это массив символов. Мы не можем обойтись без этих данных и часто используем их при написании кода.
Комбинация символов – это строка. Чтобы использовать аналогию, строка для компьютера означает, что слово принадлежит человеку. Слово «термометр» состоит из 9 символов – мы просто называем это строкой символов. Обработка строк – это обширная тема, которая должна изучаться каждым начинающим программистом.
Сложные типы данных поставляются с большинством языков программирования, которые используются. Есть и другие, такие как системы классов. Это явление также известно как объектно-ориентированное программирование (ООП).
Переменные
Переменные – это просто имена областей памяти. Иногда нужно сохранить данные в исходном коде в месте, откуда их можно вызвать, чтобы использовать. Обычно это место памяти, которое резервирует компилятор/интерпретатор. Нам нужно дать имя этим ячейкам памяти, чтобы потом их вспомнить. Рассмотрим фрагмент кода Python ниже:
pet_name – пример переменной, и тип данных, хранящихся в pet_name, является строкой, что делает переменную строковой. Существуют также числовые. Таким образом, переменные классифицируются по типам данных.
Константы
Константы – это значения, которые не изменяются на протяжении всего жизненного цикла программы. Чаще всего в их именах используются заглавные буквы. Некоторые языки поддерживают создание постоянных значений, а некоторые – нет.
Существуют строго типизированные языки программирования, в которых каждая переменная должна быть определенного типа. Выбрав тип один раз, вы больше не сможете его изменить. Java – хороший пример такого ЯП.
Другие же не предоставляют эти функции. Они являются свободно типизированными или динамическими языками программирования. Пример – Python.
Вот как объявить постоянное значение в JavaScript:
Литералы
В каждом исходном коде существуют типы данных, которые используются повсюду и изменяются только в том случае, если их отредактировали. Это литералы, которые не следует путать с переменными или константами. Ни один исходный код не обходится без них. Литералы могут быть строками, числами, десятичными знаками или любыми другими типами данных.
В приведенном выше фрагменте слово «Hippo» является строковым литералом. Это всегда будет «Hippo», пока вы не отредактируете исходный код. Когда вы научитесь кодить, узнаете, как управлять литералами таким образом, чтобы оставлять неизменной большую часть кода.
Пунктуация/Символы
В большинстве написанных программ вы найдете различные знаки препинания в зависимости от выбранного языка программирования. Например, в Java используется больше знаков препинания, чем в Python.
Основные знаки включают в себя запятую (,), точку с запятой (;), двоеточие (:), фигурные скобки (<>), обычные круглые скобки (()), квадратные скобки ([]), кавычки («» или »), вертикальную черту (|), слэш (\), точку (.), знак вопроса (?), карет (^) и процент (%).
Добро пожаловать в мир программирования, где знаки препинания – ваши лучшие друзья. Скоро вы обнаружите, что в коде их всегда очень много.
Операторы
Шансы, что вы будете писать исходный код для выполнения какой-нибудь операции, крайне высоки. Любые языки программирования, которые мы используем, включают в себя множество операторов. Среди применяемых выделяют сложение (+), деление (/) умножение (*), вычитание (—) и знак больше (>).
Операторы обычно классифицируются следующим образом:
Комментарии
Документация будет важным аспектом деятельности в сфере программирования. Это то, как вы объясняете свой код другим программистам. Подобное делается с помощью комментариев, которые добавляются к различным частям кода. С помощью комментариев вы можете направлять других программистов через написанную программу.
Компилятор игнорирует строки кода, которые являются комментариями.
Объявление комментариев разное для разных языков. Например, # используется для ввода комментариев в языке Python.
Вот пример комментария в Python:
Пробелы и вкладки
Это пробелы, созданные между кодом, который вы пишете. Они ставятся при нажатии пробела или клавиши табуляции на клавиатуре.
Двигаемся дальше
Вы познакомились с исходным кодом и изучили его содержимое. Скомпилированный или преобразованный код может не запускаться по ряду причин. Эти причины обычно связаны с ошибками. Действие поиска и удаления ошибок называется отладкой и является навыком, который вы должны изучить. Ошибки мы рассмотрим в следующей части.
Убедитесь, что вы правильно настроили Python в своей компьютерной системе, и запустите свою первую программу.
Викторина
Определите элементы, которые мы изучили, в приведенном ниже фрагменте кода Java: