Как перевести исходный код в программу. Программный код

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

• Популярные программы включают Notepad++ (Windows), TextWrangler (OS X) и JEdit (любая система).

Скачайте любые необходимые компиляторы. Некоторые языки программирования требуют компилятор для отображения исходного кода, который вы написали. Компиляторы транслируют исходный код в эквивалентную программу на языке низкого уровня, которая затем обрабатывается компьютером. Многие компиляторы являются открытыми и бесплатными программами. Языки, которые требуют использование компиляторов, включают:

• BASIC
• Fortran
• Pascal

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

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

Правило 1. Следуйте стандартам оформления кода.

У каждого языка программирования есть свой стандарт оформления кода, который говорит, как надо делать отступы, где ставить пробелы и скобки, как называть объекты, как комментировать код и т.д.

Например, в этом куске кода в соответствии со стандартом есть 12 ошибок:

For(i=0 ;i

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

Многие организации подстраивают стандарты под свои специфические нужды. Например, Google разработал стандарты для более чем 12 языков программирования. Они хорошо продуманы, так что изучите их , если вам нужна помощь в программировании под Google. Стандарты даже включают в себя настройки редактора, которые помогут вам соблюдать стиль, и специальные инструменты, верифицирующие ваш код на соответствию этому стилю. Используйте их.

Правило 2. Давайте наглядные имена.

Ограниченные медленными, неуклюжими телетайпами, программисты в древности использовали контракты для имён переменных и процедур, чтобы сэкономить время, стуки по клавишам, чернила и бумагу. Эта культура присутствует в некоторых сообществах ради сохранения обратной совместимости. Возьмите, например, ломающую язык функцию C wcscspn (wide character string complement span). Но такой подход неприменим в современном коде.

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

Гораздо важнее то, чтобы вы долго и хорошо думали перед тем, как что-то назвать. Является ли имя точным? Имели ли вы ввиду highestPrice заместо bestPrice? Достаточно ли специфично имя, дабы избежать его использования в других контекстах для схожих по смыслу объектов? Не лучше ли назвать метод getBestPrice заместо getBest? Подходит ли оно лучше других схожих имён? Если у вас есть метод ReadEventLog, вам не стоит называть другой NetErrorLogRead. Если вы называете функцию, описывает ли её название возвращаемое значение?

В заключение, несколько простых правил именования. Имена классов и типов должны быть существительными. Название метода должно содержать глагол. Если метод определяет, является ли какая-то информация об объекте истинной или ложной, его имя должно начинаться с «is». Методы, которые возвращают свойства объектов, должны начинаться с «get», а устанавливающие значения свойств - «set».

Правило 3. Комментируйте и документируйте.

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

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

Правило 4. Не повторяйтесь.

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

• Создание справочников API из комментариев, используя Javadoc и Doxygen.
• Автоматическая генерация Unit-тестов на основе аннотаций или соглашений об именовании.
• Генерация PDF и HTML из одного размеченного источника.
• Получение структуры классов из базы данных (или наоборот).

Правило 5. Проверяйте на ошибки и реагируйте на них.

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

Правило 6. Разделяйте код на короткие, обособленные части.

Каждый метод, функция или блок кода должн умещаться в обычном экранном окне (25-50 строк). Если получилось длиннее, разделите на более короткие куски. Даже внутри метода разделяйте длинный код на блоки, суть которых вы можете описать в комментарии в начале каждого блока.

Более того, каждый класс, модуль, файл или процесс должен выполнять определённый род задач. Если часть кода выполняет совершенно разнородные задачи, то разделите его соответственно.

Правило 7. Используйте API фреймворков и сторонние библиотеки.

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

Правило 8. Не переусердствуйте с проектированием.

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

Правило 9. Будьте последовательны.

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

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

Правило 10. Избегайте проблем с безопасностью.

Современный код редко работает изолированно. У него есть неизбежный риск стать мишенью атак. Они необязательно должны приходить из интернета; атака может происходить через входные данные вашего приложения. В зависимости от вашего языка программирования и предметной области, вам возможно стоит побеспокоиться о переполнении буфера, кросс-сайтовых сценариях, SQL-инъекциях и прочих подобных проблемах. Изучите эти проблемы, и избегайте их в коде. Это не сложно.

Правило 11. Используйте эффективные структуры данных и алгоритмы.

Простой код часто легче сопровождать, чем такой же, но изменённый ради эффективности. К счастью, вы можете совмещать сопровождаемость и эффективность, используя структуры данных и алгоритмы, которые даёт ваш фреймворк. Используйте map, set, vector и алгоритмы, которые работают с ними. Благодаря этому ваш код станет чище, быстрее, более масштабируемым и более экономным с памятью. Например, если вы сохраните тысячу значений в отсортированном множестве, то операция пересечения найдёт общие элементы с другим множеством за такое же число операций, а не за миллион сравнений.

Правило 12. Используйте Unit-тесты.

Сложность современного ПО делает его установку дороже, а тестирование труднее. Продуктивным подходом будет сопровождение каждого куска кода тестами, которые проверяют корректность его работы. Этот подход упрощает отладку, т.к. он позволяет обнаружить ошибки раньше. Unit-тестирование необходимо, когда вы программируете на языках с динамической типизацией, как Python и JavaScript, потому что они отлавливают любые ошибки только на этапе исполнения, в то время как языки со статической типизацией наподобие Java, C# и C++ могут поймать часть из них во время компиляции. Unit-тестирование также позволяет рефакторить код уверенно. Вы можете использовать XUnit для упрощения написания тестов и автоматизации их запуска.

Правило 13. Сохраняйте код портируемым.

Если у вас нет особой причины, не используйте функциональность, доступную только на определённой платформе. Не полагайтесь на то, что определённые типы данных (как integer, указатели и временные метки) будут иметь конкретную длину (например, 32 бита), потому что этот параметр отличается на разных платформах. Храните сообщения программы отдельно от кода и на зашивайте параметры, соответствующие определённой культуре (например, разделители дробной и целой части или формат даты). Соглашения нужны для того, чтобы код мог запускаться в разных странах, так что сделайте локализацию настолько безболезненной, насколько это возможно.

Правило 14. Делайте свой код собираемым.

Простая команда должна собирать ваш код в форму, готовую к распространению. Команда должна позволять вам быстро выполнять сборку и запускать необходимые тесты. Для достижения этой цели используйте средства автоматической сборки наподобие Make , Apache Maven , или Ant . В идеале, вы должны установить интеграционную систему, которая будет проверять, собирать и тестировать ваш код при любом изменении.

Правило 15. Размещайте всё в системе контроля версий.

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

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

Исходный код, написанный на HTML, с использованием JavaScript

Исходный код, представляющий собой программу, как правило, содержится в одном или более текстовых файлах, иногда сохраняется в базах данных, как хранимые процедуры, а также может появиться, как фрагменты кода, напечатанные в книгах или других средствах печати. Большая коллекция файлов исходноко кода может быть организована в дерево каталогов, и, в этом случае, оно может быть также известно как дерево исходных кодов (англ. source tree ) или дерево кода дерево исходного кода и т.д.

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

Цели

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

Лицензирование

Программные средства, и исходный код, что их сопровождает, как правило, относятся к одной из двух парадигм лицензий: открытое программное обеспечение и несвободное программное обеспечение (или проприетарное). В целом, программное обеспечение является открытым , если исходный код может свободно использоваться, распространяться, модифицироваться и анализироваться, и проприетарным , если исходный код держится в секрете, или находится в частной собственности и доступ к нему ограничен. Для обеспечения закрытости используются преимущественно положения различных законов об авторском праве, но часто используются также коммерческая тайна и патенты. Кроме того, дистрибутив программы, как правило, приходит с лицензионным соглашением (EULA), которое, главным образом, запрещает декомпиляцию, реинжениринг, анализ, редактирование, или обход защиты от копирования. Виды защиты исходного кода (кроме традиционного компилирования в объектный код включают шифрование кода, запутывания кода (англ. code obfuscation ) или морфинг кода.

Качество

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

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