ソースコード

「 Hello world 」プログラムのシンプルなCソースコード。これは、1974年にベル研究所のブライアン・カーニガンが考案した、画期的な書籍『プログラミング言語C』に由来する。 [ 1 ]

コンピューティングにおいて、ソース コード（または単にコードあるいはソース ）は、人間が読めるプレーンテキストであり、最終的にはコンピュータの動作を制御することができます。コンピュータを制御するには、コンピュータ プログラムで処理する必要があります。つまり、インタープリタを介して直接実行するか、コンパイラなどを使用して、よりコンピュータが処理しやすい形式に変換する必要があります。場合によっては、コードはマシン コードに直接コンパイルされ、それ以上処理することなくコンピュータのネイティブ言語で実行できます。ただし、最近の多くの環境では、インタープリタを介して実行することも、ジャス​​トインタイム コンパイルによってオンデマンドでマシン コードにコンパイルすることもできる、バイトコードなどの中間表現へのコンパイルが必要になります。

背景

1940年代末に登場した最初のプログラム可能なコンピュータ[ 2 ]は、機械語(プロセッサで直接実行できる単純な命令)でプログラムされていました。機械語はデバッグが難しく、異なるコンピュータシステム間での移植性がありませんでした。 [ 3 ]当初、ハードウェアリソースは不足して高価でしたが、人的リソースは安価でした。[ 4 ]プログラムが複雑になるにつれて、プログラマの生産性がボトルネックになりました。これが、1950年代半ばにFortranなどの高水準プログラミング言語の導入につながりました。これらの言語はハードウェアの詳細を抽象化し、人間が理解しやすいアルゴリズムを表現できるように設計されました。[ 5 ] [ 6 ]ソフトウェアは、基礎となるコンピュータハードウェアとは異なる命令であるため、 Fortran、Lisp、Cobolなどの初期の高水準プログラミング言語にまで遡る、比較的最近のものです。[ 6 ]高水準プログラミング言語の発明は、ソースコードをコンピュータハードウェア上で直接実行できる機械語に自動的に変換するために必要なコンパイラと同時に行われました。[ 7 ]

ソースコードとは、人間が直接変更するコードの形式で、通常は高水準プログラミング言語で記述されます。オブジェクトコードは、機械によって直接実行可能であり、ソースコードから自動的に生成されます。ソースコードの生成には、多くの場合、中間段階としてアセンブリ言語が使用されます。オブジェクトコードは特定のプラットフォームでのみ動作しますが、ソースコードは別のマシンに移植し、そこで再コンパイルすることができます。同じソースコードでも、オブジェクトコードは大きく異なる可能性があります。これは、コンパイルされたマシンだけでなく、コンパイラによるパフォーマンス最適化によっても異なります。[ 8 ] [ 9 ]

組織

‹下記のテンプレート（Further）は、カテゴリ「more」との統合を検討中です。合意形成のための議論については、テンプレートをご覧ください。›

ほとんどのプログラムは実行に必要なリソースをすべて備えておらず、外部ライブラリに依存しています。コンパイラの機能の一部は、これらのファイルをリンクし、プログラムをハードウェアで実行できるようにすることです。[ 10 ]

より複雑なJavaソースコードの例です。オブジェクト指向プログラミングスタイルで記述されており、定型コードの例を示しています。プロローグコメントは赤、インラインコメントは緑、プログラムステートメントは青で示されています。

ソフトウェア開発者は、ソースコードファイルの変更を追跡するために構成管理（バージョン管理）をよく利用します。構成管理システムは、どのオブジェクトコードファイルがどのバージョンのソースコードファイルに対応しているかも追跡します。[ 11 ]

目的

推定

ソースコード行数（SLOC）は、コンピュータプログラマーの生産性、コードベースの経済的価値、開発中のプロジェクトの労力見積もり、リリース後のソフトウェアメンテナンスの継続的なコストを評価する際の指標としてよく使用されます。[ 12 ]

コミュニケーション

ソースコードは、オンラインや書籍内のコードスニペットなど、関係者間でアルゴリズムを伝達するためにも使用されます。[ 13 ]

コンピュータプログラマーは、既存のソースコードを確認することでプログラミング技術を学ぶことができる。[ 13 ]開発者間でソースコードを共有することは、プログラミングスキルの成熟に寄与する要因としてよく挙げられる。[ 13 ]ソースコードを表現力豊かな芸術的媒体と考える人もいる。[ 14 ]

ソースコードには、コンパイラが無視するようにマークされたテキストブロックであるコメントが含まれることがよくあります。このコンテンツはプログラムロジックの一部ではなく、読者がプログラムを理解するのに役立つことを目的としています。 [ 15 ]

企業は、企業秘密とみなされるアルゴリズムを隠すために、ソースコードを秘密にしておくことがよくあります。独自の秘密ソースコードとアルゴリズムは、刑事司法などの機密性の高い政府アプリケーションに広く使用されており、アルゴリズムの手法に関する透明性が欠如したブラックボックス状態を引き起こしています。その結果、バイアスなどの問題に対する公的な監視を回避しています。[ 16 ]

修正

ソースコード（オブジェクトコードだけでなく）へのアクセスは、それを変更するのに不可欠です。[ 17 ]既存のコードを理解することは、それがどのように機能するかを理解するために必要です。 [ 17 ]そして、それを変更する前に。[ 18 ]理解の速さは、コードベースとプログラマーのスキルの両方に依存します。[ 19 ]経験豊富なプログラマーは、コードが高レベルで何をするかを理解するのが簡単です。[ 20 ]ソフトウェアの視覚化は、このプロセスをスピードアップするために使用されることがあります。[ 21 ]

多くのソフトウェアプログラマーは、生産性を向上させるために統合開発環境（IDE）を使用しています。IDEには通常、よくあるエラーをプログラマーに警告するソースコードエディタなど、いくつかの機能が組み込まれています。 [ 22 ]変更には、多くの場合、コードのリファクタリング（機能を変えずに構造を改善すること）と再構築（構造と機能を同時に改善すること）が含まれます。[ 23 ]コードを変更すると、ほぼ必ず新しいバグや予期せぬ波及効果が発生し、再度の修正が必要になります。[ 18 ]

他の開発者によるコードレビューは、プロジェクトに追加された新しいコードを精査するためによく使用されます。[ 24 ]このフェーズの目的は、コードがスタイルと保守性の基準を満たしていること、およびソフトウェア設計の正しい実装であることを確認することです。[ 25 ]いくつかの推定によると、コードレビューにより、ソフトウェアテストの完了後に残るバグの数が劇的に減少します。[ 24 ]コードを実行して機能するソフトウェアテストに加えて、静的プログラム解析では、自動化ツールを使用してソースコードの問題を検出します。多くの IDE はコード解析ツールをサポートしており、コードの明瞭さと保守性に関するメトリックを提供できる場合があります。[ 26 ]デバッガーは、多くの場合、プログラマが実行をステップ実行しながら、どのソースコードが各状態の変化に対応しているかを追跡できるようにするツールです。[ 27 ]

コンパイルと実行

高水準プログラミング言語のソースコードファイルは、命令を実行する前に、機械語への前処理段階を経る必要があります。 [ 7 ]コンパイルされたプログラムはオブジェクトファイルとして保存され、ローダー（オペレーティングシステムの一部）はこの保存されたファイルを読み込み、コンピュータハードウェア上のプロセスとして実行することができます。 [ 10 ]一部のプログラミング言語では、コンパイラではなくインタープリタが使用されます。インタープリタは実行時にプログラムを機械語に変換するため、コンパイル型プログラミング言語に比べて10～100倍遅くなります。[ 22 ] [ 28 ]

携帯性

‹下記のテンプレート（Further）は、カテゴリ「more」との統合を検討中です。合意形成のための議論については、テンプレートをご覧ください。›

多くのプログラムが実行可能なバイナリ ファイルではなくソース コード形式で配布されるもう 1 つの理由は、多くの場合、単一のソース コード ファイルを一度記述すれば、さまざまなエンド ユーザー マシン (それぞれ独自のローカライズされたコンパイラまたはインタープリタを使用) で実行できることです。一方、実行可能コード ファイルは、一般にほぼ同一のマシンでしか動作しません。ソース コードは、Unix の歴史の初期にはこの方法で Unix オペレーティング システムを配布するために使用され、後にスクリプト言語(特にJavaScriptクライアント側スクリプト言語) で記述されたプログラムをさまざまなマシンで実行できるようにするために使用されました。

この目的のために、縮小、難読化、または逆コンパイルされたソース コード ファイル (いずれも元のコード内のコメントを削除したもの) は、変更にはあまり役に立たないため、GNU 一般公衆利用許諾書バージョン 2 (GPL2) のソース コードの定義を満たしていないにもかかわらず、一般に元のソース コード ファイル (ほぼ常にコメントを含む) と同様に移植可能です。

品質

‹下記のテンプレート（Further）は、カテゴリ「more」との統合を検討中です。合意形成のための議論については、テンプレートをご覧ください。›

ソフトウェアの品質とは、コードの正確性と効率性、再利用性と移植性、変更の容易さなどを指す包括的な用語です。[ 29 ]開発プロセスの後半で品質を追加するよりも、最初から製品に品質を組み込む方が通常は費用対効果が高くなります。[ 30 ]高品質のコードは、信頼性と保守性の向上により、サプライヤーと顧客の両方の生涯コストを削減します。[ 31 ] [ 32 ]

保守性とは、既存の機能を壊すことなくソフトウェアを簡単に変更できる品質のことです。[ 33 ]目的に合った明確な関数名や変数名を使用するなどのコーディング規約に従うと、保守が容易になります。[ 34 ]コードが複数回実行される可能性がある場合にのみ条件付きループ文を使用し、実行されることのないコードを削除しても、理解しやすさが向上します。 [ 35 ]多くのソフトウェア開発組織は、長期的にはコストが増加するにもかかわらず、開発フェーズで保守性を無視しています。[ 32 ]技術的負債は、プログラマが、多くの場合、期限に間に合わせるための怠惰または緊急性から、コードに保守性を組み込むのではなく、急ごしらえの解決策を選択した場合に発生します。[ 36 ]一般的な原因は、ソフトウェア開発の労力見積もりを過小評価し、開発に割り当てられるリソースが不十分になることです。 [ 37 ]保守性の課題は、多くのソフトウェアエンジニアリングコースで保守性が強調されていないことです。[ 38 [ 18 ]

‹下記のテンプレート（Further）は、カテゴリ「more」との統合を検討中です。合意形成のための議論については、テンプレートをご覧ください。›

状況は世界各地で異なりますが、1974年以前のアメリカ合衆国では、ソフトウェアとそのソースコードは著作権の対象ではなく、常にパブリックドメインソフトウェアでした。[ 39 ] 1974年、米国著作物の新技術利用委員会（CONTU）は、「コンピュータプログラムは、著作者の独自の創作を具体化する限りにおいて、著作権の適切な対象である」と決定しました。[ 40 ] [ 41 ]

プロプライエタリソフトウェアがソースコードとして配布されることは稀である。[ 42 ]オープンソースソフトウェアという用語は文字通りソースコードへの公開アクセスを指すが、[ 43 ]オープンソースソフトウェアには追加の要件がある。それは、自由な再配布、ソースコードを変更して同じライセンスの下で派生作品をリリースする許可、そして商業的利用を含む異なる用途間の差別禁止である。[ 44 ] [ 45 ]オープンソースソフトウェアの自由な再利用性は開発を加速させることができる。 [ 46 ]

参照

参考文献

  1. ^ Kernighan, Brian W. 「C言語によるプログラミング：チュートリアル」（PDF）。ベル研究所、ニュージャージー州マレーヒル。 2015年2月23日時点のオリジナル（PDF）からアーカイブ。
  2. ^ガッブリエリ＆マルティーニ 2023、p. 519.
  3. ^ガッブリエリ＆マルティーニ 2023、520–521 ページ。
  4. ^ガッブリエリ＆マルティーニ 2023、p. 522。
  5. ^ガッブリエリ＆マルティーニ 2023、p. 521.
  6. ^ a bトレイシー 2021、p.1。
  7. ^ a bトレイシー2021、p.121。
  8. ^リンら。 2001 年、238 ～ 239 ページ。
  9. ^カティアル 2019、1194頁。
  10. ^ a bトレイシー2021、pp.122–123。
  11. ^ O'Regan 2022、230–231、233、377。
  12. ^フォスター2014、249、274、280、305頁。
  13. ^ a b c Spinellis, D.: Code Reading: The Open Source Perspective . Addison-Wesley Professional, 2003. ISBN 0-201-79940-5
  14. ^「アートとコンピュータプログラミング」 ONLamp.com、 2018年2月20日アーカイブ、Wayback Machine、(2005)
  15. ^カズマレクら。 2018、p. 68.
  16. ^カティアル 2019、1186–1187 ページ。
  17. ^ a bカティアル 2019、1195頁。
  18. ^ a b c Offutt, Jeff (2018年1月). 「ソフトウェアの保守と進化の概要」 .ジョージ・メイソン大学コンピュータサイエンス学部. 2024年5月5日閲覧。
  19. ^トリパシーとナイク 2014、p. 296.
  20. ^トリパシーとナイク 2014、p. 297.
  21. ^ Tripathy & Naik 2014、pp. 318–319。
  22. ^ a bオレガン 2022、375頁。
  23. ^トリパシーとナイク 2014、p. 94.
  24. ^ a bドゥーリー 2017、272頁。
  25. ^オレガン 2022、18、21頁。
  26. ^オレガン 2022、133頁。
  27. ^カズマレクら。 2018、348–349 ページ。
  28. ^セベスタ 2012、28ページ。
  29. ^ガリン2018、26頁。
  30. ^オレガン 2022、68、117頁。
  31. ^オレガン 2022、3、268頁。
  32. ^ a b Varga 2018、12ページ。
  33. ^ Varga 2018、5ページ。
  34. ^ Tripathy & Naik 2014、296–297 ページ。
  35. ^トリパシーとナイク 2014、p. 309.
  36. ^ヴァルガ 2018、6～7頁。
  37. ^ Varga 2018、7ページ。
  38. ^ヴァルガ 2018、7～8頁。
  39. ^ Liu, Joseph P.; Dogan, Stacey L. (2005). 「著作権法と主題の特定性：コンピュータソフトウェアの事例」ニューヨーク大学アメリカ法年次調査61 (2). 2021年6月25日時点のオリジナルよりアーカイブ。
  40. ^ Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs Archived 7 May 2017 at the Wayback Machine in Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (Jan 1984)
  41. ^ Lemley、Menell、Merges、Samuelson著「ソフトウェアとインターネット法」 34ページ。
  42. ^ボイル 2003、45ページ。
  43. ^ Morin et al. 2012、「オープンソースとクローズドソース」。
  44. ^センら2008年、209頁。
  45. ^ Morin et al. 2012、「フリーおよびオープンソースソフトウェア（FOSS）ライセンス」。
  46. ^オレガン 2022、106頁。

出典

無料の辞書である Wiktionary でコード またはソース コードを調べます。
ウィキメディア コモンズには、ソース コードに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=Source_code&oldid=1334135874」から取得