hpprc/jawiki-books huggingface dataset:
近江弁/尊敬

近江弁には軽い敬意を表す助動詞が複数あり、地域差や世代差もからんで複雑な状況となっています。ここではそのうち主なものを解説します。
近江弁の尊敬語は、本人がいない場ほどよく使われるという特徴があります。共通語では尊敬語は目上の話し相手に対して使うことが多く、その場にいない人に対して使うと相当かしこまった言い方になりますが、近江弁では逆に、「あんたとこのお母さん元気にしてはる?」「うん、元気やで。今日も元気にパート行かはったわ」のように普段尊敬語を使って話しかけないような間柄の人(家族、友人、漠然とした集団など)にも、会話のなかでその人のことを話題に出す時には尊敬語をよく使います。その場合は尊敬語というよりも「きつくない言い方」ぐらいの軽い感覚で使われ、会話相手への敬意が多少込められます。
もっともよく使われる表現で、公の場でも通用します。丁寧形は「~はります」、過去形は「~はった」、否定形は「~はらへん」(まれに~はらん)になります。
五段活用では京都と同じく「a+はる」の形で使われます。大阪のような「i+はる」はほとんど使われません。
上一段活用・下一段活用・カ変・サ変では「連用形+はる」の形で使われます。年配層では「連用形+やはる」と言うこともありますが、その場合カ変とサ変では「きゃはる」「しゃはる」に変化することがあります。また「居る」に「やはる」を付けると、頭の「い」の発音が弱まって「いやはる→やはる」になることもあります。
進行形は「~てはる」の形で使われますが、大津など京都に近い地域では「~たはる」とも言います。年配層では「~てやはる」と言うこともあります。
湖北・湖東・甲賀にかけてよく使われる、「~はる」のややくだけた表現です。丁寧形は「~(や)あります」、過去形は「~(や)あった」(湖東・甲賀では「~(や)った」、湖北では「~(や)あた」と言うことが多い)、否定形は「~(や)あらへん」または「~(や)あらん」(湖北・湖東では「~(や)あれん」と言うこともある)になります。
五段活用では「a+ある」の形で使われます。
上一段・下一段・カ変・サ変では「連用形+やある」の形で使われます。カ変とサ変では「きゃある」「しゃある」(湖北では「さある」と言うことが多い)によく変化します。また「居る」に「やある」を付けると、頭の「い」の発音が弱まって「いやある→やある」になることが多いです。
進行形は「~てやある」の形で使われますが、湖北では「~てある」と言うこともあります。
びわ湖放送の「野洲のおっさんカイツブリ」というキャラクターがよく使っていますが、野洲に限らず、滋賀県内各地(湖北では少ない)の農山村の年配層で使われます。くだけた表現なので、丁寧形はありません。
五段活用では「a+る」の形で使われます。過去形は「a+った」、否定形は「a+らん」になります。
上一段・下一段・カ変・サ変では「連用形+らる」の形で使われます。過去形は「連用形+らった」、否定形は「連用形+ららん」になります。
進行形は「~てらる」の形で使われます。
近江弁/目下待遇

近江弁には、会話のなかで話題に出している人物について、下に見ている存在であることを表す助動詞があります。
主に湖東と甲賀で、「ほほえましいなあ」「世話が焼けるやつだなあ」などプラスの感情を込めて使われる表現です。直接の関係があるかどうかは不明ですが大阪弁と共通します。丁寧形は「~やります」ですが、ほとんど使われません。過去形は「~やった」、否定形は「~やらへん」または「~やらん」になります。
すべての活用で「連用形+やる」の形で使われますが、年配層では五段活用で「連用形+ゃる」と言うこともあります。
進行形は「~てやる」の形で使われます。意気込みなどを表す際の「~てやる」とはアクセントが異なります。
主に湖北と湖西で、「ほほえましいなあ」「世話が焼けるやつだなあ」などプラスの感情を込めて使われる表現ですが、年配層では軽い尊敬語として使う人もいます。地域や世代による細かな言い方の違いが多い表現でもあります。丁寧形はありません。過去形は「~(や)んた」または「~(や)んした」です。否定形は「~(や)んせん」が一般的ですが、「~(や)んへん」「~(や)んさへん」「~(や)んしゃへん」などの言い方もあります。
五段活用では「a+んす」の形が一般的ですが、一部の地域では「i+やんす」や「e+んす」という形もあります。
上一段活用・下一段活用では「連用形+やんす」の形で使われます。「居る」に「やんす」を付けると、頭の「い」が弱まって「いやんす→やんす」になることが多いです。
カ変では「きやんす」「きゃんす」「こんす」の三種類の形があり、そのうち「こんす」は農村部に多い形です。農村部の年配層では「ごんす」と言うこともあります。
サ変では「しやんす」「しゃんす」「さんす」の三種類の形があり、そのうち「さんす」は農村部に多い形です。
進行形は「~てやんす」の形で使われますが、湖西の一部では「~たんす」と言う地域もあります。
「~(や)んせ」という命令形もあり、主に年配層が目上以外に優しく命令する時に使われます。湖西の朽木には「~(や)いせ」という形もあります。
県全域で、「アホなことをしているな」「余計なことをしてくれたな」などマイナスの感情を込めて使われる表現ですが、特に男性のくだけた会話では、親しみを込めて使うこともあります。共通語の「~やがる」に近いですが、「~やがる」は面と向かって本人にも直接使えるのに対し、「~よる」は本人には直接使いません。丁寧形は「~よります」ですが、ほとんど使われません。過去形は「~よった」、否定形は「~よらん」または「~よらへん」になります。
すべての活用で「連用形+よる」の形で使われますが、五段活用の一部で「行きよる→いっきょる」「死による→しんにょる」のように変化することがあり、湖北ではさらに「いっこる」「しんのる」のように変化することがあります。上一段の「居る」は頭の「い」が弱まって「いよる→よーる」と言うことがあり、カ変・サ変は「きよる→きょーる」「しよる→しょーる」と言うことがあります。
進行形は「~てよる」になりますが、ニュアンスが「~とる」とかぶるため、ほとんど使われません。
対象を下に見ているというよりも、会話のラフさや臨場感を強めるために「~よる」を付け足していると思われる使い方もあります(特に主語が無生物の場合)。
刑事訴訟法第290条の3

法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
(公開の法廷での証人等特定事項の秘匿)
2016年改正により新設。
前条(第290条の2)において、被害者の人身及びプライバシー保護の観点から、被害者を特定する事項を公開の法廷で明らかにしない旨の決定をすることができるとしていたが、証人等においても、個人を特定することにより不利益を受ける可能性があることから、同様に特定する事項を開示しないことができることとした。。
供述録取書等 - 本条にて定義。
Microsoft PowerPoint/アニメーション

Microsoft PowerPointにはアニメーションという機能があります。
アニメーションを使うとスライドにテキストやオブジェクト(図形、画像など)を出現させたり、隠したり、動かしたりすることができる。アニメーションは、リボンのなかにあるアニメーションというタブから入れることができる。
アニメーションの種類などはバージョンによって異なる。
アニメーションには大きく4つの種類があり、その4つの中に更にアニメーションがある。アニメーションの種類はバージョンによって異なる。
オブジェクトを出現させるアニメーション。
オブジェクトを強調させる(点滅、拡大など)アニメーション。
オブジェクトを消すアニメーション。
オブジェクトを動かすアニメーション。
刑事訴訟法第301条の2

法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
(取り調べの録音・録画と記録媒体の証拠調べの請求)
以下のとおり改正。2025年6月1日施行。
2016年改正により新設。
近江弁/接続助詞

ここでは近江弁で使われる接続助詞について解説します。ほとんどは近隣地域の方言と共通します。
動詞や形容詞、断定「や」の後ろに付けて、原因や理由を表します。文の最初に使う時は「そや」または「ほや」を頭に付けます。大阪などでは「高齢者しか使わないコテコテすぎる関西弁」という印象がありますが、滋賀県内(都市部を除く)では中年世代ぐらいでもまだまだ盛んに使われています。地域によっては「さけ(に)」とも言います。また湖北などの年配層では「はかい(に)」「はけ(に)」のように「さ」を「は」に変えて言うことがあります。
動詞や形容詞、断定「や」の後ろに付けて、原因や理由を表します。文の最初に使う時は「そや」または「ほや」を頭に付けます。福井県や東海地方などと共通する表現で、それらの県と隣接した湖北・湖東・甲賀で特によく使われます。なお、東海地方では「で」とともに「もんで」もよく使われますが、滋賀県内では「もんで」はほとんど使われません。
動詞や形容詞、断定「や」の後ろに付けて、原因や理由を表します。文の最初に使う時は「そや」または「ほや」を頭に付けます。京都弁から取り入れたと思われる表現で、共通語にも似たような用法があるため、田舎臭さの薄い表現として、湖南を中心に比較的若い世代でよく使われます。
動詞や形容詞、断定「や」の後ろに付けて、逆接を表します。文の最初に使う時は「そや」または「ほや」を頭に付けることが多いですが、付けずに言うこともできます。都市部以外では「けんど」という言い方もよく使われます。
C言語/標準ライブラリ/locale.h

ヘッダー <locale.h> は、2つの関数と1つの型を宣言し、いくつかのマクロを定義しています。
ヘッダー <locale.h> で定義される型 struct lconv で、数値のフォーマットに関連するメンバーを含む。この構造体は、少なくとも以下のメンバーを任意の順序で含まなければならない。メンバーのセマンティクスとその正常範囲は、#localeconv関数 で説明します。C "ロケールでは、メンバーはコメントで指定された値を持ちます。

ヘッダー <locale.h> で定義されるマクロは、NULL と
で、値が明確な整数の定数式に展開され、setlocale関数の第一引数として使用するのに適しています。また、LC_ と大文字で始まる追加のマクロ定義も実装によって指定できます。
setlocale()関数は、プログラムの現在のロケールを設定または照会するために使用します。
localeがNULLでない場合、プログラムの現在のロケールは引数に応じて引数に応じて変更されます。 引数 category は、プログラムの現在のロケールのどの部分を修正するかを決めます。
localeがNULLの場合、現在のロケールは問い合わせをするだけで変更はません。
localeconv()関数は、現在のロケールの構造体lconvへのポインタを返します。
この構造体は次のセクションで示され、ロケールカテゴリ LC_NUMERIC' および LC_MONETARY に関連するすべての値を含みます。
プログラムでは、関数printf()やstrfmon()を使用することもできますが、これらは実際に使用されているロケールに応じて動作します。
The struct lconv contains the following fields:
struct lconvには、以下のフィールドがあります。
小数点を表す文字。
小数点の左にある桁グループの区切り文字。
各要素はグループ内の桁数であり、インデックスが大きい要素はさらに左になります。
CHAR_MAXという値を持つ要素は、それ以上のグループ化が行われないことを意味します。
0の値を持つ要素は、前の要素が左隣のすべてのグループに使用されることを意味します。
最初の3文字は通貨記号 ISO 4217の通貨記号です。
4番目の文字は セパレータです。
5文字目は'0'です。
現地通貨記号。
上記 decimal_point に同じ。
上記 thousands_sep に同じ。
上記 grouping に同じ。
正の値を示す符号。
負の値を示す符号。
国際的な小数点以下の桁数。
ローカルな小数点以下の数字。
currency_symbolの前に正の値がある場合は1、成功した場合は0とります。
正の金額のとき、通貨記号と金額をスペースで区切るなら、currency_symbol を 1とします。
負の金額のとき、通貨記号が符号に前置するならばcurrency_symbol を 1に、さもなければ 0 になります。
負の金額をセパレータで区切る場合、currency_symbol は 1に、さもなければ 0 になります。
正負の符号位置:
C言語/標準ライブラリ/setjmp.h

ヘッダー<setjmp.h> では、マクロ setjmp を定義し、通常の関数呼び出しと戻りの規律を回避するための 1 つの関数と 1 つの型を宣言しています。

setjmpがマクロであるか、外部リンクで宣言された識別子であるかは不詳です。 もし マクロ定義が実際の関数にアクセスするために抑制されている場合や、プログラムがsetjmpという名前の外部識別子を定義している場合、 プログラムがsetjmpという名前の外部識別子を定義した場合、その動作は未定義です。
これらの関数は、プログラムの低レベル関数で発生する異常な状態に対処するのに便利です。
C言語/標準ライブラリ/signal.h

ヘッダー<signal.h> では、さまざまなシグナル(プログラムの実行中に報告される条件)を処理するために、型と2つの関数を宣言し、いくつかのマクロを定義しています。
シグナル関数の第2引数とその戻り値に対応した型を持ち、かつ宣言可能な関数のアドレスと比較して不等な値を持つ定数式に展開されるものと、 int型の正の整数の定数式に展開され、それぞれ指定された条件に対応するシグナル番号である明確な値を持つ以下のものがあります。
実装では、明示的に raise 関数を呼び出した場合を除き、これらのシグナルを生成する必要はありません。
SIGと大文字、またはSIG_と大文字で始まるマクロ定義を持つ、追加のシグナルと宣言不可能な関数へのポインタも、実装によって指定することができます。
シグナルの完全なセット、そのセマンティクス、およびデフォルトの処理は、実装によって定義されます。すべてのシグナル番号は正の値でなければなりません。
シグナル処理の指定。
C言語/標準ライブラリ/stdatomic.h

ヘッダー <stdatomic.h> では、いくつかのマクロが定義されており、スレッド間で共有されるデータに対してアトミック操作(atomic operation; 不可分操作)を行うためのいくつかの型や関数が宣言されています。
マクロ __STDC_NO_ATOMICS__ を定義している実装は、このヘッダーを提供する必要はなく、また、その機能をサポートする必要もありません。
アトミック・ロックフリー・マクロ( atomic lock-free macros )
これらは,#if 前処理ディレクティブでの使用に適した定数式に展開され,対応する原子型(符号付きおよび符号なしの両方)のロックフリー特性を示します。
これはatomic_flag型のオブジェクトのイニシャライザに展開されます。
は、列挙型であり、その列挙者はメモリ順序制約を識別します。
ロックフリーのプリミティブ・アトミック・フラグを表す構造体タイプである「アトミック・フラグ」や、整数型のアトミック・アナログがいくつかあります。
以下のシノプスでは
アトミックな整数型の場合、M は C です。アトミックなポインタ型の場合、M は ptrdiff_t です。
<stdatomic.h> で宣言されたジェネリック関数が、マクロであるか、外部リンクで宣言された識別子であるかは不定( unspecified )です。
実際の関数にアクセスするためにマクロ定義を抑制した場合や 実際の関数にアクセスするためにマクロ定義が抑制されたり、プログラムがジェネリック関数の名前で外部識別子を定義した場合、その動作は未定義( undefined )です。
フェンスと呼ばれる同期プリミティブの1つです。
C言語/標準ライブラリ/stdbool.h

ヘッダー <stdbool.h> には、4つのマクロが定義されています。
残りの3つのマクロは、#if 前処理ディレクティブでの使用に適しています。
bool、true、falseというマクロを定義解除して、おそらく再定義する機能は、時代遅れの機能です。
ヘッダー <stdbool.h> は、ISO/IEC 9899:1999(通称:C99)で追加されました。
C言語/標準ライブラリ/stdint.h

ヘッダー <stdint.h> では、指定された幅を持つ整数型の集合を宣言し、それに対応するマクロの集合を定義しています。
また、他の標準ヘッダーで定義された型に対応する整数型の限界を指定するマクロも定義しています。
型は以下のカテゴリーで定義されています。
(これらの型のいくつかは同じ型を表すことがあります)
対応するマクロは、宣言された型の制限を指定し、適切な定数を構築します。
ここに記述されている各型のうち、実装が提供するものについては、<stdint.h>はそのtypedef名を宣言し、関連するマクロを定義しなければならない。
逆に、ここに記述されている型のうち、実装が提供していないものについては、<stdint.h>はそのtypedef名を宣言せず、関連するマクロを定義してはならない。
実装は、「必須("required")」と記述されている型を提供しなければならないが、「任意("optional"))」と記述されているその他の型を提供する必要はない。
機能テストマクロ __STDC_VERSION_STDINT_H__ は、 yyyymmL というトークンに展開されます。
最初のuの有無だけが異なる型名が定義されている場合、それらは§6.2.5 Types に記載されているように対応する符号付き及び符号なしの型を表すものとする。 §6.2.5 Types に記述されているように、対応する符号付きおよび符号なしの型を示す。 これらの対応する型の一方を提供する実装は、他方も提供しなければならない。
以下の記述では、記号 N は、先頭にゼロを持たない符号なしの10進整数を表す(例えば、8や24であり、04や048ではない)。
これらの型はオプションです。ただし、8、16、32、64ビットの幅を持ち、パディングビットを持たない整数型を提供する場合は、対応するtypedef名を定義しなければならない。
以下の各型は、少なくとも指定された幅を持つすべての整数型の中で、通常、最も高速に演算できる整数型を指定しています。
以下のオブジェクト型マクロは、<stdint.h>で宣言された型の幅を指定します。各マクロ 名前は#整数型と同様の型名に対応しています。
定義されたマクロの各インスタンスは、#if 前処理ディレクティブで使用するのに適した定数式で置き換えられなければならない。その実装定義値は、以下に示す値と同等以上でなければならない。 ただし、正確に指定された値であると述べられている場合を除く。実装では、実際に提供する 型名に対応するマクロのみを定義しなければならない。
例えば、uint_least64_tがunsigned long long int型の名前である場合、UINT64_C(0x123)は整数定数0x123ULLに展開されます。
幅を表す接尾辞_WIDTHを持つマクロが存在するすべての整数型に対して、接尾辞_MAXを持つ最大値マクロと、すべての符号型に対して接尾辞_MINを持つ最小値マクロは、以下のように定義されます。 § 5.2.4.2. Characteristics of integer types <limits.h> で定義されています。符号付きか符号なしかの指定がなく、実装上、符号なしの型となっている場合は、接尾辞_MIN の最小マクロと、対応する型の値 0 が定義される。
C言語/標準ライブラリ/time.h

ヘッダー <time.h> では、いくつかのマクロが定義されており、時間を操作するための型や関数が宣言されています。
多くの関数は、(グレゴリオ暦に基づく)現在の日付と時刻を表すカレンダータイムを扱います。いくつかの関数は、特定のタイムゾーンで表現されるカレンダータイムであるローカルタイムや、ローカルタイムを決定するアルゴリズムの一時的な変更である夏時間を扱います。ローカルタイムゾーンと夏時間は実装で定義されます。
C2xでは、機能テストマクロ __STDC_VERSION_TIME_H__ は、 yyyymmL というトークンに展開されます。その他のマクロはNULLが定義されています(§7.19 Common definitions <stddef.h>に記載)。
ヘッダー <time.h> で定義されているマクロと型と、宣言されている関数。
処理系が __STDC_LIB_EXT1__ を定義し、ユーザが __STDC_WANT_LIB_EXT1__ を 1 に停止した場合、以下の境界チェックインターフェースが有効になります。
POSIX(IEEE Std 1003.1)では、time.hに2つの関数を追加しています。asctime_rとctime_rです。 これらはasctimeとctimeのリエントラント版( reentrant version )です。どちらの関数も、呼び出し側が、ある瞬間のテキスト表現を格納するバッファを提供することを必要とします。 以下のサンプルでは、リエントラント版のlocaltimeとasctimeの使用方法を示しています。
これらの関数はC++の標準にはないので、C++の名前空間stdには属していません。
刑事訴訟法第499条の2

法学>コンメンタール>コンメンタール刑事訴訟法=コンメンタール刑事訴訟法/改訂
(電磁的記録に係る記録媒体の交付又は複写ができない場合の取扱い)
2011年改正にて新設。
民事訴訟法第125条

法学>民事法>民事訴訟法
(所有者不明土地に関する訴訟手続の中断及び受継)
2021年民法改正により新設(2023年施行予定)。
2004年改正まで「破産財団に関する訴訟手続の中断及び受継」について規定されていたが、同年の破産法改正により、破産法第44条に定められたため削除。空番となっていた。
近江弁/文末詞

ここでは近江弁の語尾で使われる表現(終助詞・間投助詞をひっくるめて文末詞と呼ぶことにします)を解説します。
主に湖北と湖東で使われ、関西のほかの方言にはない「これぞ近江弁」という表現ですが、若い世代ではほとんど使われなくなっています。頻度は低いですが、「~ほんな」と言うこともあります。次の二つの用法があります。
相手に呼びかけたり注意したりする際に使われる、関西全般で共通する表現です。近江弁には接続助詞の「で」(=から)もありますが、発音が少し違います。
相手に自分の考えや事情を伝える際に使われる、関西全般で共通する表現です。「です」「ます」にも付けます。
共通語の「ね」に相当する、関西全般で共通する表現です。年配層では「です」「ます」にも付けます。湖東・湖北の高齢女性の丁寧な言い方として「~なーし」「~なし」もあります。湖西などでは「~のー」とも言います。
共通語の「さ」に相当する、主に湖東・甲賀・湖南で使われる表現です。特に「~けどよ」「~さかいによ」「~しよ」のように接続助詞とともによく使われます。HLと抑揚を付けて伸ばして言うこともよくあります。
湖東・甲賀・湖南などの一部で「ぞ」を「じょ」と言うことがあります。
COBOL

メインページ > 工学 > 情報技術 > プログラミング > COBOL
COBOL(コボル)は、1959年に事務処理用に開発されたプログラミング言語です。 名前は「Common Business Oriented Language」(共通事務処理用言語)に由来します。 Fortran・Lispとともに最も古いプログラミング言語の1つですが、 それ故、多くのソフトウェア資産の蓄積があり、2022年の今日でも現役のプログラミング言語として使用されています。
COBOLの特徴を簡単なコード例とともに示します。以下は、COBOLのいくつかの特徴を示す基本的なコードスニペットです。
以下は簡単なCOBOLのプログラムです。
GnuCOBOL(旧OpenCOBOL、短期間GNU Cobolとして知られていました)は、COBOLのフリーな実装です。 GnuCOBOLは、ネイティブのCコンパイラを使用するCへのトランスコンパイラです。
ディストリビューションにより、パッケージマネージャとパッケージ体系に違いがありますが、例えば Fedora Linux では、
FreeBSD Ports/Packages Collection の、ports/lang/gnucobol にあるので、
でビルドしインストールできます。 また
でビルド済みパッケージをインストールできますが、GnuCOBOL自身のバージョンアップやportsのパッチレベルの更新で gnu-cobol-3.1.2_1の部分は変わるので、
の様に、最初に最新のパッケージ名を確認してください。
簡単なCOBOLプログラムのソースコードを hello.cbl という名前で保存し、コンパイルし実行してみよう。
COBOLの正書法には、自由書式正書法と固定書式正書法の2種類があります。
それぞれの正書法には以下のような特徴があります。
処理系によっては、コマンドラインオプションなどで正書法の切り替えが可能な場合があるので、詳しくは使用している処理系のマニュアルを参照してください。
COBOLプログラムのトップレベルは
の4つのパートから構成され、順序もこの順序である必要があります。
IDENTIFICATION DIVISIONは、COBOLプログラムの最初のパートで、 プログラム名、作成者、作成日などのプログラム保守情報を含みます。 これらは、見出し部の段落として記述します。
ENVIRONMENT DIVISIONは、COBOLプログラムの2番目のパートで、 作成するプログラムをコンパイルして実行するコンピュータの名前、環境変数の受け渡しに関する情報、プログラムとの間で読み書きするファイルの名前と種類を定義します。
DATA DIVISIONはCOBOLプログラムの3番目のパートで、これまでのDIVISIONはCOBOLプログラムを構築するためのメタデータで、 DATA DIVISIONからが実際にプログラムを構築していくところだと言えます。 DATA DIVISIONでは、入出力ファイルの配置、データ項目(変数)、外部プログラムとのインタフェース(引数)など、プログラムで扱うすべてのデータを定義します。
PROCEDURE DIVISIONは、COBOLプログラムの最後のパートで、プログラムが実行する処理を記述します。
前3つのDIVISIONとは異なり、手続き部には定義された節や段落の様な既定の構造はありません。 節や段落は、プログラマが必要に応じて作成します。
COBOLにおいて、FortranのSubroutineやC言語の関数に相当する構文は、主に「サブルーチン」と「関数」です。以下に、それぞれの概要を説明します。
COBOLのサブルーチンと関数は、プログラムの構造を明確にし、再利用性を高めるために使われます。
COBOL(Common Business-Oriented Language)は、ビジネスアプリケーション向けに開発されたプログラミング言語で、1959年にアメリカ国防総省の委員会が設立したCODASYL(Conference on Data Systems Languages)委員会によって設計されました。以下に、COBOLの変遷について簡単に説明します。
これらのバージョンは、COBOLの進化を示しています。それぞれの規格で新しい機能や改善が導入され、COBOLは長い間にわたって広く利用され続けています。
弁護士法第23条

法学>コンメンタール>コンメンタール弁護士法
(秘密保持の権利及び義務)
弁護士又は弁護士であつた者は、その職務上知り得た秘密を保持する権利を有し、義務を負う。但し、法律に別段の定めがある場合は、この限りでない。
弁護士の守秘義務および秘密保持権の根拠規定である。
弁護士職務基本規定第23条 - 弁護士の守秘義務に関する日本弁護士連合会会則上の規定。
情報技術/構造化プログラミング

構造化プログラミングは、非構造化プログラミングの解毒剤として提案されたものです。 非構造化プログラミングは、構造化プログラミングが発明される数十年前から既に存在していました。
非構造化プログラミングとは、手続き型のプログラムのことで、書かれている通りに文が順番に実行されます。しかし、このタイプのプログラミングでは、GOTO文を使用します。GOTO文は、プログラム内の任意の場所に制御を渡すことができます。 GOTO文が実行されると、GOTOの対象から順番に実行されます。このように、プログラムの仕組みを理解するためには、プログラムを実行するふりをしなければなりません。つまり、このようなプログラムの論理を理解するのは難しい場合が多いのです。プログラムコンパイラの中には、GOTOの接続先をクロスインデックス化して、ソースコードを高速にナビゲートする実用的なものもある。 しかし、いくつかのプログラミング言語では、GOTOの行き先に関連した変数を使用することが一般的であったため、自動インデックス化は実用的ではありませんでした。 構造化されたプログラミング言語の中には、多くの人が同じコンピュータのデータを人間の言語で見ることができるようにするための外国語ビューの実装方法など、同様の問題があります。
これは、構造化プログラミングのように、プログラムがどのように動作するかを理解するために、ある種の抽象化を使用するという考えとは対照的です。
このような理由から、ダイクストラはGOTO文を禁止すべきだと提案しました。
構造化されたプログラミングとは、危険なGOTO文を使わないようにしたプログラミングという見方があります。これにより、混乱を招く恐れのある制御の移行を防ぐことができます。 多くの構造化プログラミング言語はGOTO文をサポートしており、構造化された方法で使用することができます。 例えば、ルーチンの最後に抜けたり、ループの最初に戻ったりするために使用します。
別の見方をすれば、構造化プログラミングは、1つのエントリーポイントと1つのエグジットポイントのみを持つ制御構造を使用することに限定される。これらの構造のうち最も重要なものは、順接、選択(ifおよびif...else)、反復(while)です。
また、構造化されたプログラムとは、抽象化によって容易に理解できるように書かれたプログラムであるという見方もあります。抽象化とは、細かい部分を理解しなくても、コードの全体的な目的を理解できるようにすることです。抽象化のための代表的なメカニズムは、プロシージャ(メソッド)です。しかし、上記のような単一エントリ単一出口の構造もまた抽象化に役立ちます。
構造化されたプログラミングを可能にしたのは、高レベルの言語と関連するプログラムのパッケージであり、プログラマーでなくても理解できるソフトウェアの図解技術を用いてフローチャートを作成することができる。
構造化プログラミングのアイデアを発見し、それを他のプログラマーの世界に伝えたのは、数人のコンピュータ科学者である。構造化プログラミングを最初に具現化したのはALGOL(Algorithmic Language)言語で、これはバロース B5000 MCP(OS)でシステムプログラミングに使われた最初の高級言語となりました(設計したのはBob Bartonで、後にユタ大学の教授となり、GUIウィンドウを発明した学生Alan Kayに影響を与え、Smalltalkの開発者の一人となりました)。その結果、ALGOLは最初のオブジェクト指向言語であるSimulaの基礎となりました。
ALGOLは、John BackusとPeter Naurの名前をとってBNF(Backus-Naur Form)と呼ばれる言語設計形式をベースにしていました。
この技術の画期的な本は、"Structured Programming"(Academic Press 1972: ISBN 978-0-12-200550-3)で、Edsger W. Dijkstraの "Notes on Structured Programming"、C.A.R. Hoareの "Notes on Data Structuring"、Ole-Johan DahlとC.A.R. Hoareの "Hierarchical Program Structures "という3つのセクションで構成されています。最後のセクションでは、Simulaとそのオブジェクト指向および並行処理機能が紹介されています。
Edsgar Djikstraは「A Discipline of Programming」(Prentice Hall, 1976: ISBN 978-0132158718)という本も書いています。
また、構造化プログラミングの世界では、Donald Knuthも有名です。彼は、複数巻からなる『The Art of Computer Programming』を執筆しました。
その後、Ed YourdonとLarry Constantineによって『Structured Design』(ISBN 978-0138544713)という本が書かれ、多くの人がこれを構造化プログラミングとみなしていますが、そうではありません。これはグラフィカルな手法で、実際には非常に退屈なものだった。ほとんど放棄されてしまったが、UMLのような他の非形式的なアプローチの後継者がいる。ストラクチャード・デザインとストラクチャード・プログラミングで説明されている手法は全く異なるものであり、Structuredという言葉を共有しているからといって混同してはならない。
高等学校古文/古典文法入門

現在私たちが使っている言葉を口語(現代語)と言う。対して、明治初期まで使用されていた言葉を文語(古典語)という。高校の学習や一般社会において文語は、奈良時代から江戸時代までの言葉を指すことが多い。
次の文章は『竹取物語』の冒頭部分である(この文章の内容は中学校国語 古文/竹取物語を参照)。
この文章から、現代語と古典語の違いをまとめる。
「竹取の翁といふもの(が)ありけり」 「もと(が)光る」
「野山にまじりて」(現代語では「まじって」となる)
「いふ」(いう)「よろづ」(よろず)
全ての単語は3つの基準で分類される。
民事訴訟法/弁論の準備

口頭弁論よりも前に、当事者は準備書面を裁判所に提出して、事実の主張や証拠の提出を行わなければならない。準備書面に書いてない事は、口頭弁論の際にもし相手方が法廷に在席していない場合には、書かれていないその主張をする事ができない(161条1項)。なお、被告が最初に提出する「答弁書」も準備書面の一種である。
準備書面を提出しただけでは訴訟資料にはならず、準備書面の内容を口頭弁論でその内容を陳述する事によって訴訟資料として認められるようになる。
準備書面には一般に、当事者の氏名や裁判所の記載に加え、
が記載される。
なお、ここでいう「攻撃」とは相手方当事者に不利になるような主張のような意味、「防御」とは相手方当事者の攻撃に対する反論のような意味であり、民訴法などにもよく用いられる表現である。
最初の口頭弁論期日だけだが、当事者が口頭弁論に出席しない場合、準備書面に記載された内容は、口頭弁論で陳述したものと同じ効果がある事になり、これを陳述擬制または擬制陳述という(158条)。
争点整理手続は、口頭弁論に先立って行われる、争点および証拠を整理するための手続である。正式名称は「争点及び証拠の整理」であり、その名の通り、争点の他、のちの集中証拠調べで必要とされる証拠も整理する。
争点整理手続きには下記の3種類ある。
裁判所は、当事者の意向も確認しつつ、事件の内容などにもとづき、
の3種のうちから、いずれかを選んで実施する。
現在では、弁論準備手続きの利用率が圧倒的に高い。
平成15年の旧民事訴訟法の時代、条文には無い制度だが裁判所では慣習的に「弁論兼和解」という制度が運用されており、 これは公開法廷ではなく原告・被告当事者以外には非公開の「和解室」などの部屋においてインフォーマルな雰囲気の中では話し合いを行うという制度であり、実質的には裁判前に弁論を行っていた。昭和50年代頃から長らく運用されていた。
しかし憲法などの定める裁判公開の原則に反するなどの懸念もあり、学説には反対意見もあった。
一方で、弁論兼和解の有用性を認める学説もあり、弁論前の準備手続きとみなせるという意見もあった。
そこで、平成15年の改正の際、憲法問題にならないように「弁論」ではなく「手続き」という事にした。また、「和解」の目的を除去した。
なお平成15年の改正後は、(「和解室」ではなく)「準備手続室」などの名前の部屋で、これらの「手続き」が行われる事になり、法服を着用してないような裁判官のもとでのインフォーマルな雰囲気の中で裁判官と当事者たちが話し合いをする場になった。
口頭弁論ではないので、当事者がもし出席が困難なら電話会議システムなどを用いても手続きを実施しても良い(170条3項)。
口頭弁論ではないと言っても、公平性の観点から、双方の当事者が立ち会える期日に実施しなければならない事が法的に定められている(169条1項)(対席保証)。
公開義務は無いが、かといって非公開の義務も無いので、裁判所の裁量にもとづき一定の関係者に公開する事もできる(関係者公開、)(169条2項)。
「準備的口頭弁論」を選んで実施した場合、その名の通り口頭弁論であるので、これは公開の法廷で口頭弁論を実施する事である。
公開の法廷で実施する要件はあるが、必ずしも通常の法廷で実施する必要は無いので、ラウンドテーブル法廷で実施しても良い。
弁論兼和解(弁論準備手続)ではないので、電話会議などの方法は認められない。
特に定めの無い事に関しては、通常の口頭弁論や準備書面についての規定が適用される。。

「書面による準備手続き」は主に当事者が遠隔地に住んでいるなどの場合を想定した手続きである。
当事者が遠隔地に住んでいる場合や、その他裁判長が必要と認めた場合に実施される。
このため、当事者は裁判所に出頭する必要は無い。また必要とあらば電話会議システムが認められる(175条3項)。
医療や建築など、裁判官が通常有しない知識が必要な場合、それらの知見をもった医師や建築士などの専門家からなる専門委員を関与させる事ができる(92条2)。 専門委員は、非常勤の国家公務員となる。
このほか、知的財産関係の事件では、裁判所調査官に専門委員と同様の仕事をさせる事もできる(92条8)。
民訴法や刑訴法には「鑑定」という制度があり、医者などの学識を持った有識者に鑑定を依頼する制度がある。
鑑定には高度な学識が必要なため、口頭弁論(刑訴なら「公判」)での鑑定の結果の説明も難解になってしまい、その分野の学識を持たない原告や被告には、意味が理解できなくなってしまうという問題点が、昔から指摘されていた。
あるいは、もし口頭弁論(民事)や公判(刑事)で、専門外の人に分かるように説明をしていたら、審理が長くなってしまい、非効率である。
そこで平成15年(2003年)に導入された制度として「カンファレンス鑑定」などと呼ばれる制度が、医師会や弁護士会などの協力もあって創設された。
このカンファレンス鑑定の制度は、現行では東京地裁など一部の裁判所にしかない。(※ もしかしたら東京地裁だけ? 要確認)
カンファレンス鑑定では、鑑定人・裁判官・原告・被告の4者が裁判所に集まって、専門外の人にも分かり易い言葉で鑑定人が残り三者に説明をする制度である。
争点整理手続ではないので、カンファレンス鑑定では争点は整理しない。(なお、刑訴法では、そもそも争点整理手続が無い。)あくまで、鑑定内容について、訴訟や審理に必要な程度の科学的な理解を得るために、鑑定人からの説明が得られる場でしかない。
現状では、カンファレンス鑑定の制度は、医療訴訟にだけ適用されており、医者が鑑定の結果の説明をする。
証人尋問ではないので、カンファレンスでの発言内容などに証拠能力は無い。また、証人の交互尋問でもないので、もし鑑定内容についての質問があれば、その場で鑑定人にすぐ質問できるという利点などもある。
民事訴訟法には、証拠の保全命令を出せる規定がある(234条など)。典型例としては、医療過誤訴訟におけるカルテの差し押さえが、法学教育での証拠保全の典型例であった。
しかし、(証拠でない)財産などを保全する命令の規定は現行の民事訴訟法には無い。
財産隠しや差押え逃れなどを防ぐために財産の保全も必要であるが、そのような財産保全の手続のことを民事保全手続ともいい、その規定は(民事訴訟法ではなく)民事保全法に規定がある。(元々、民事保全法は民事訴訟法から分離独立したものである。)
民事保全法による手続により、判決が出る前でも、被告などの財産を保全する事ができ、このような命令を「仮差押え」または「仮処分」という。 金銭債務なら「仮差押え」という。そうでない場合が「仮処分」である。
また、証拠保全にしろ民事保全にしろ、迅速性が要求されるので、原告主張の信憑性の程度は、裁判官が「一応は確からしい」と思える程度の疎明で良い(証拠保全については規153条)。
上記とは別の証拠収集制度として、平成15年の民訴法改正によって導入された提訴予告通知に基づく提訴前証拠収集(132条の2)という方法で、当事者からの申立により裁判所に証拠収集をできる可能性のある制度がある。

弁護士は、弁護士会を仲介して、公務所または公私の団体から必要な情報の報告を受けることができ、この制度を弁護士会照会という(弁護23条の2)。
弁護士から申し出を受けた弁護士会が、照会が適切かの審査をし、照会が不適切と判断すれば、弁護士会は照会を拒絶する。
※調査中
民事訴訟法/多数当事者訴訟

訴訟は必ずしも原告1人と被告1人との一対一である必要は無い。
「共同訴訟」という制度では、複数の原告または複数の被告が、ひとつの訴訟に参加する事もできる。
原告の意思によって訴えの始めから併合される場合を訴えの主観的併合という。 共同訴訟の起きる要因は主に、
である。
なお、これに対して「訴えの客観的併合」とは共同訴訟とは異なり、「訴えの客観的併合」とは複数の請求がひとつの訴えから出てくる場合であるので、主に請求の併合に関するものである(136条)。
なお、共同訴訟において、判決の内容の統一を図る必要がある場合には、そのことを「合一確定の必要がある」とも言う。 また、合一確定の必要があるかないかによって共同訴訟は「通常的共同訴訟」と「必要的共同訴訟」に分類される。
以下の通常共同訴訟などは、共同訴訟における主観的併合の類型でもある。
通常共同訴訟は、合一確定の必要とされていない種類の共同訴訟である。
通常共同訴訟によって、証拠を共通とする事ができるので、裁判を効率化できる(共同訴訟人間の証拠共通)。 より詳細には、通常共同訴訟人では、共同訴訟人の1人がした訴訟行為は、その行為が同陣営の他の共同訴訟人の利益になる場合に限り、同陣営の他の共同訴訟人にも効力が生じる(40条1項)。
また、共同訴訟は併合して審理されるので、たとえば審理は同一期日になる。
しかし、共同訴訟人の一人に対して生じた事項は、他の共同訴訟人には影響を及ぼさず(39条)、これを「共同訴訟人独立の原則」という。具体的には、この独立の原則により、共同訴訟人の各人はそれぞれ独立に、請求の放棄、和解、訴えの取り下げをできる。

以下3つの要件のいずれかを満たせば、通常共同訴訟が可能である。 (1) 訴訟の目的である権利または義務が数人について共通であるとき(38条前段)、
(2) 訴訟の目的である権利または義務が同一の事実上および法律上の原因にもとづくとき(38条前段)、
(3) 訴訟の目的である権利または義務が同種であって、事実上および法律上の同種の原因に基づくとき(38条後段)、
必要的共同訴訟は法律上、訴訟の目的の合一確定が要請されている(民訴40 I)。では合一確定とは何かが問題になるが、通説では、判決を共同訴訟人の個々人に別々に出す事が許されずに判決をひとつにまとめる事だと解されている。

固有必要的共同訴訟とは、全員が共同で訴える、または共同で訴えられなければ不適法になるという訴訟であり、次のような類型がある。
(1)他人間の権利関係の変動を生じさせる訴訟
(2)数人共同の管理処分権を行使すべき訴訟
(3)法律上、数人が共同で管理・共有すべき財産に関する訴訟
もし団体の構成員たちが固有必要的共同訴訟をしようとする場合に、構成員のひとりでも反対すると、条文などをそのまま解釈すれば訴訟できなくなる。だが実際は、団体構成員の中にいる反対者を被告に加えるという方法により、とりあえず反対者も法廷での訴訟に関与させるという形式により、要件から反対者が無しという条件を除外しているのが判例である(最判平成20・7・17民集62巻7号1994頁<百選97>)。

類似必要的共同訴訟とは、実体法上は共同で訴える事は要請されていないが、共同訴訟をした以上、合一確定を要請されるべきという訴訟である。
たとえば債務請求訴訟において、その債務の保証人は、その訴訟に当事者の補助として参加できる。
決して誰でも参加できるわではなく、例にあげた保証人のように、訴訟内容と深い関係をもつ人物でないとならない(42条)。
単に友人や家族といった程度では、裁判所は補助参加人としての参加を認めない可能性が比較的に高いだろう。
補助参加人は、自らの固有の請求をもたない。従って、補助参加人は、当事者ではなく、また判決の名宛人にもならない。
補助参加人には、独立的な地位が与えられており、その結果、期日の呼出しや書類の送達なども被参加人とは別に行われる。
しかし、補助参加人の役割はあくまで補助であるので、まず、
たとえば、建物明渡し訴訟で、原告と被告とが所有権を争っているときに、第三者がその建物の所有権は自分にあると主張するとき、この第三者は原告被告どちらの陣営にも属すべきではない。
このように、第三者の主張が、もとの訴訟の原告・被告のいずれの主張とも対立するとき、もとの訴訟が係属中なら、第三者に独立の当事者としての参加できる。このような仕組みを、独立当事者参加という。
この場合、もとの訴訟の原告をA、もとの被告をB、第三者をCとすれば、訴訟は、A対B、B対C、C対Aという三面的な構造になる。
独立当事者参加人が訴訟に参加するための手続としては、条文的には、もとの訴訟の原告および被告に、それぞれ訴状を送って訴えを提起しなければならないとされる(47条3項)。
だが実際には、独立当事者参加人がもとの訴訟の原告または被告の片方と利害が一致していて争いのない場合もあり、このような場合、争いのある残り片方だけに訴状を送れば良いと許容するのが現行法の規定である(47条1項)。(旧法では議論になっており許容説が有力説であった。)
民事訴訟法/訴えの提起

訴えの提起は、裁判所に訴状を提出して行うのが原則である(133条1項)。
訴訟を起こすと、その時点で時効の進行は止まる(民147上1項1号)。
地方裁判所以上の訴訟代理人は原則として弁護士でなければならないが(54条)、しかし例外がいくつかある。
例外的に、船舶における船長(商713条1項)、または企業における支配人(商21条1項、会社11条1項)は、代理人になる事が認められている。船長など、これらの法令による訴訟代理人は、弁護士である必要は無い(54条1項)。
日本の民事訴訟では、代理人を選任せずとも、当事者本人が自ら訴訟をする事もできる。これを本人訴訟という。しかし、本人が裁判をできるだけの充分に理解力および主張・陳述する能力(弁論能力)を持たない場合、そのままでは裁判が遅延してしまうので、裁判所は当事者の陳述を禁止できるとともに(155条1項)、必要があれば当事者に弁護士の付き添いを命じる事ができる(155条2項)。
民事訴訟の他にも、調停や仲裁など、訴訟以外の方法で紛争解決をする手続きもある。なお、仲裁については仲裁法に規定がある。
Go/ソースコードの表現方法

ソースコードは、UTF-8でエンコードされたUnicodeテキストです。テキストは正規化されていないので、1つのアクセント付きコードポイントは、アクセントと文字を組み合わせて作られた同じ文字とは区別され、それらは2つのコードポイントとして扱われます。『The Go Programming Language Specification』では、簡単のために、原文中のUnicodeコードポイントを参照するために、修飾語ではないcharacterを使用します。
例えば、大文字と小文字は異なる文字です。
実装上の制限。他のツールとの互換性のために、コンパイラーはソース・テキスト中の NUL 文字(NUL character; U+0000)を許可しないことがあります。
実装上の制限。他のツールとの互換性のため、コンパイラーは UTF-8 でエンコードされたバイトオーダーマーク(BOM; U+FEFF)がソース・テキスト内で最初の Unicode コードポイントである場合、それを無視してもかまいません。バイトオーダーマークは、ソース内の他の場所では許可されません。
この様に、ソースコードの文字コードを言語仕様書で明確に規定しているので、それ以外の文字コードを使うことは仕様に反した使用方法です。
UTF-8エンコードに規定されているのはソースコードだけなので、他の文字コードでエンコーディングされたファイルの読み書きは専用のパッケージで定義された関数を使います。

以下の用語は、特定のUnicode文字クラスを示すために使用されます。
The Unicode Standard 8.0の4.5項「General Category」では、一連の文字カテゴリが定義されています。 Goでは、LetterカテゴリのLu、Ll、Lt、Lm、Loのいずれかに含まれるすべての文字をUnicodeの文字として扱い、NumberカテゴリのNdに含まれる文字をUnicodeの数字として扱います。
アンダースコア文字「_」(U+005F)は、文字とみなされます。