Skip to content

Commit 206571b

Browse files
committed
chore: format
1 parent 1b780b1 commit 206571b

12 files changed

+974
-905
lines changed

.vscode/settings.json

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,8 @@
11
{
22
"eslint.validate": ["javascript", "javascriptreact", "vue", "markdown"],
33
"editor.codeActionsOnSave": {
4-
"source.fixAll.eslint": "explicit"
4+
"source.fixAll.eslint": "explicit",
5+
"source.fixAll.markdownlint": "never"
56
},
67
"editor.defaultFormatter": "esbenp.prettier-vscode",
78
"editor.formatOnSave": true,

documents/forJava/Javaコーディング規約.md

Lines changed: 211 additions & 210 deletions
Large diffs are not rendered by default.

documents/forJava/Javaコーディング規約_for_11.md

Lines changed: 183 additions & 182 deletions
Large diffs are not rendered by default.

documents/forJava/Javaコーディング規約_for_17.md

Lines changed: 204 additions & 203 deletions
Large diffs are not rendered by default.

documents/forJava/Javaコーディング規約_for_8.md

Lines changed: 174 additions & 172 deletions
Large diffs are not rendered by default.

documents/forOpenAPISpecification/OpenAPI_Specification_2.0.md

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -108,6 +108,7 @@ description: "何かしらの説明"
108108
- account_type
109109
- register_at
110110
```
111+
111112
- YAML は項目定義がネストすることで縦長な定義になりやすい。情報密度を上げるために配列リテラルを推奨する
112113

113114
## 改行の表現
@@ -297,8 +298,8 @@ schemes:
297298
Swagger では、次の認証タイプを記載できる([詳細](https://swagger.io/docs/specification/2-0/authentication/))。
298299

299300
1. ベーシック認証
300-
1. API キー(リクエストヘッダ, クエリパラメータ)
301-
1. OAuth2
301+
2. API キー(リクエストヘッダ, クエリパラメータ)
302+
3. OAuth2
302303

303304
もし、認証が必須であれば記載する。全ての Web API で未認証を受け入れる場合は記載しない。認証の要否が API ごとに異なる場合は、各 API 側で `security: []` と記載しして上書き定義する必要がある。
304305

@@ -522,6 +523,7 @@ URL に紐づく HTTP メソッドで、1 つの操作を定義します。
522523
type: string
523524
...
524525
```
526+
525527
- モデル名は、 `{HTTPメソッド名}{物理名}` の PascalCase で記載する
526528
- : PutUserAccount、PostUserAccount, PatchUserAccount
527529

@@ -957,7 +959,7 @@ Swagger 定義で以下の変更を行う場合は、利用するコード生成
957959

958960
# 推奨ツール
959961

960-
[本当に使ってよかった OpenAPI (Swagger) ツール ](https://future-architect.github.io/articles/20191008/) にあるように、様々なツールで開発ができる。VS Code を用いる場合は以下のプラグインを推奨する。
962+
[本当に使ってよかった OpenAPI (Swagger) ツール](https://future-architect.github.io/articles/20191008/) にあるように、様々なツールで開発ができる。VS Code を用いる場合は以下のプラグインを推奨する。
961963

962964
- [YAML](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml)
963965
- [Swagger Viewer](https://marketplace.visualstudio.com/items?itemName=Arjun.swagger-viewer)

documents/forOpenAPISpecification/OpenAPI_Specification_3.0.3.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -10,8 +10,8 @@ head:
1010

1111
<page-title/>
1212

13-
本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。
14-
ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。
13+
本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。\
14+
ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。\
1515
また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。
1616

1717
# はじめに
@@ -109,6 +109,7 @@ description: "何かしらの説明"
109109
- account_type
110110
- register_at
111111
```
112+
112113
- YAML は項目定義がネストすることで縦長な定義になりやすい。情報密度を上げるために配列リテラルを推奨する
113114

114115
## 改行の表現
@@ -779,7 +780,7 @@ components:
779780
...
780781
```
781782

782-
正常系のレスポンスの例としてはファイルアップロード・ダウンロードのレスポンスなどが該当する。
783+
正常系のレスポンスの例としてはファイルアップロード・ダウンロードのレスポンスなどが該当する。\
783784
個別のアプリケーション要件でブレが少なく、複数のエンドポイントで用いられる場合に定義する。オブジェクトのスキーマは、`schemas` に切り出して定義し、コード生成ツールのために型情報を付与させる。
784785

785786
良い例:

documents/forSQL/SQLコーディング規約(Oracle).md

Lines changed: 54 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -10,15 +10,15 @@ head:
1010

1111
<page-title/>
1212

13-
本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。
14-
ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。
13+
本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。\
14+
ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。\
1515
また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。
1616

1717
# はじめに
1818

1919
## 前提条件
2020

21-
本書は、SQL コーディング規約についてまとめたものである。
21+
本書は、SQL コーディング規約についてまとめたものである。\
2222
今回 RDBMS として採用する Oracle での SQL の使用を前提に記述している。
2323

2424
# SQL コーティング規約(可読性・管理性)
@@ -48,17 +48,17 @@ head:
4848

4949
SQL 中に記述するエイリアス名など単語の短縮について示す。
5050

51-
1. 外来語に関しては、原語の短縮形を使用する。短縮形が存在しない場合には、母音を抜かして表記する。
51+
1. 外来語に関しては、原語の短縮形を使用する。短縮形が存在しない場合には、母音を抜かして表記する。\
5252
例) corporation → corp / computer → cmptr
5353

54-
2. ローマ字の短縮は、単語の区切れの頭文字、または母音を抜かした子音字等を利用する。
54+
2. ローマ字の短縮は、単語の区切れの頭文字、または母音を抜かした子音字等を利用する。\
5555
例) nichijo → nchj
5656

5757
- カラムには必ずテーブルエイリアスを付与する
58-
- テーブルのエイリアスは必ず付与すること。
59-
必要ない場合(単一テーブルへの SELECT 等)も必ず付与すること
60-
また、テーブルのエイリアス名は同 SQL 文の中で重複しないように命名すること。
61-
(副問い合わせで利用したエイリアス名をメインの SQL 中のエイリアス名に利用しない。など)
58+
- テーブルのエイリアスは必ず付与すること。\
59+
必要ない場合(単一テーブルへの SELECT 等)も必ず付与すること\
60+
また、テーブルのエイリアス名は同 SQL 文の中で重複しないように命名すること。\
61+
(副問い合わせで利用したエイリアス名をメインの SQL 中のエイリアス名に利用しない。など)
6262

6363
## 文字コード
6464

@@ -70,14 +70,14 @@ SQL ファイルの文字コード(エンコーディング)は Java ソー
7070

7171
## SQL 文の整形
7272

73-
DML 文の節に対する予約語は左揃えにする。
74-
項目ごとに改行を入れ、項目の前にはインデントを挿入する。カンマは項目の前へ記入する。
75-
Java ソースファイルのようにファイルの先頭にコメント行を入れると DB 分析作業に支障があるため禁止とする。
73+
DML 文の節に対する予約語は左揃えにする。\
74+
項目ごとに改行を入れ、項目の前にはインデントを挿入する。カンマは項目の前へ記入する。\
75+
Java ソースファイルのようにファイルの先頭にコメント行を入れると DB 分析作業に支障があるため禁止とする。\
7676
よって SQL ファイルの先頭は必ず`SELECT``UPDATE``INSERT``DELETE``MERGE`の何れかになる。
7777

78-
物理カラム名、テーブル名に対応する論理名を入れる場合、その後ろに単数行コメント(`-- `)にて記述する。
79-
SQL 内に挿入する単数行コメントは、`/*(半角スペース)コメント本文(半角スペース)*/` で行う。
80-
`,`(カンマ)と`AND`については各行の先頭に記述する。(以下の例を参照のこと)
78+
物理カラム名、テーブル名に対応する論理名を入れる場合、その後ろに単数行コメント(`-- `)にて記述する。\
79+
SQL 内に挿入する単数行コメントは、`/*(半角スペース)コメント本文(半角スペース)*/` で行う。\
80+
`,`(カンマ)と`AND`については各行の先頭に記述する。(以下の例を参照のこと)\
8181
SQL フレームワークで実行する SQL の場合、SQL ステートメントの終わりを示す`;`(セミコロン)は記述しない。
8282

8383
良い例:
@@ -220,7 +220,7 @@ CASE
220220
END
221221
```
222222

223-
`CASE``WHEN``THEN``ELSE`の後に改行を挿入すること。
223+
`CASE``WHEN``THEN``ELSE`の後に改行を挿入すること。\
224224
`CASE`の後、`END`の前までは 1 インデント挿入すること。
225225

226226
### IN 句
@@ -233,9 +233,9 @@ END
233233

234234
### 改行位置
235235

236-
SELECT 句、ORDER BY 句、GROUP BY 句等は最初に出現するカラムとカラムの区切りのカンマ前に改行を入れること。
237-
SELECT の FROM 句の最初に出現するテーブルと結合テーブルの区切りのカンマ前に改行を入れること。
238-
WHERE 句、MERGE の ON 句の各条件文の(AND や OR の)前に改行を入れること。
236+
SELECT 句、ORDER BY 句、GROUP BY 句等は最初に出現するカラムとカラムの区切りのカンマ前に改行を入れること。\
237+
SELECT の FROM 句の最初に出現するテーブルと結合テーブルの区切りのカンマ前に改行を入れること。\
238+
WHERE 句、MERGE の ON 句の各条件文の(AND や OR の)前に改行を入れること。\
239239
命令句の後は、ヒント句が挿入できるように改行すること。
240240

241241
良い例:
@@ -257,7 +257,7 @@ ORDER BY
257257

258258
### WITH 句
259259

260-
WITH の前後に改行を挿入すること
260+
WITH の前後に改行を挿入すること\
261261
また、インデントは下記のように記述すること
262262

263263
良い例:
@@ -311,7 +311,7 @@ FETCH NEXT 5 ROWS ONLY
311311

312312
### HINT 句
313313

314-
HINT 句は独立した行で記載すること
314+
HINT 句は独立した行で記載すること\
315315
HINT 内容にはインデントを付けること
316316

317317
良い例:
@@ -332,8 +332,8 @@ WHERE
332332

333333
- 修正コメント
334334

335-
(修正コメントが必要な場合、)
336-
処理追加の際、追加行の 1 行目の前と最終行の次の行にコメントを入れる。単一行の場合は、同一行の最後にコメントをつける。
335+
(修正コメントが必要な場合、)\
336+
処理追加の際、追加行の 1 行目の前と最終行の次の行にコメントを入れる。単一行の場合は、同一行の最後にコメントをつける。
337337

338338
良い例:
339339

@@ -349,8 +349,8 @@ WHERE
349349

350350
- 複数行コメント
351351

352-
`/*` `*/` 」を使用する。下記に例を示す。
353-
なお、前述で触れたとおり、SQL ファイルの先頭にコメントを記述することは禁止とする。
352+
`/*` `*/` 」を使用する。下記に例を示す。\
353+
なお、前述で触れたとおり、SQL ファイルの先頭にコメントを記述することは禁止とする。
354354

355355
良い例:
356356

@@ -367,19 +367,19 @@ WHERE
367367

368368
- 複数行コメントアウト
369369

370-
複数行をコメントアウトする場合は、各行を「`--`」でコメントアウトする。
371-
`/*` `*/` 」を使用すると、その中に「 `/*` `*/` 」が存在した場合、コメントアウトが途中で切れてしまう恐れがあるため、
372-
使用しない。
370+
複数行をコメントアウトする場合は、各行を「`--`」でコメントアウトする。\
371+
`/*` `*/` 」を使用すると、その中に「 `/*` `*/` 」が存在した場合、コメントアウトが途中で切れてしまう恐れがあるため、\
372+
使用しない。
373373

374374
- 論理名の記載
375375

376-
`SELECT``INSERT``UPDATE``MERGE`のカラム名記述箇所には単数行コメントでカラムの論理名を記載する。
377-
`SELECT``INSERT``UPDATE``DELETE``MERGE`のテーブル名記述箇所には単数行コメントでテーブルの論理名を記載する。
378-
論理名は ERD 等で定義された論理名と必ず一致させること。
376+
`SELECT``INSERT``UPDATE``MERGE`のカラム名記述箇所には単数行コメントでカラムの論理名を記載する。\
377+
`SELECT``INSERT``UPDATE``DELETE``MERGE`のテーブル名記述箇所には単数行コメントでテーブルの論理名を記載する。\
378+
論理名は ERD 等で定義された論理名と必ず一致させること。
379379

380380
## 外部結合
381381

382-
結合方法は ANSI 形式(~`outer join` ~)ではなく Oracle 形式`(+)`を使用する。
382+
結合方法は ANSI 形式(~`outer join` ~)ではなく Oracle 形式`(+)`を使用する。\
383383
原則として`(+)`は条件文の右にくるカラムに付与する。
384384

385385
良い例:
@@ -408,8 +408,8 @@ T1.COL1 = T2.COL2(+)
408408

409409
## EXISTS 句
410410

411-
EXISTS 句を記載する際、サブクエリになる SELECT 句の指定は定数「`1`」とする。
412-
`*`」(ワイルドカード)や「`'X'`」は統一の観点から利用しない。
411+
EXISTS 句を記載する際、サブクエリになる SELECT 句の指定は定数「`1`」とする。\
412+
`*`」(ワイルドカード)や「`'X'`」は統一の観点から利用しない。\
413413
また「`*`」(ワイルドカード)についてはパフォーマンスの観点からも禁止とする。
414414

415415
良い例:
@@ -428,14 +428,14 @@ WHERE
428428

429429
## AS 句
430430

431-
トップレベルの SELECT 句には必ず`AS`句を記載し別名を付ける。
432-
同一の名前であっても AS 句を付与する。
431+
トップレベルの SELECT 句には必ず`AS`句を記載し別名を付ける。\
432+
同一の名前であっても AS 句を付与する。\
433433
また、「`AS`」は省略可能であるが、省略はしないこと。
434434

435435
## WHERE 句
436436

437-
- 論理名の記載
438-
WHERE 句でカラムと式を比較する際は左辺がカラムになるように記載すること。
437+
- 論理名の記載\
438+
WHERE 句でカラムと式を比較する際は左辺がカラムになるように記載すること。
439439

440440
良い例:
441441

@@ -445,9 +445,9 @@ WHERE
445445
AND TBL.AMOUNT2 > TBL.AMOUNT3 + TBL.AMOUNT4
446446
```
447447

448-
- 条件式の順序
449-
原則として、WHERE 句で条件式を列挙する際、下記の順序を守ること。
450-
1. テーブル単位にまとめて順番に記述する
448+
- 条件式の順序\
449+
原則として、WHERE 句で条件式を列挙する際、下記の順序を守ること。
450+
1. テーブル単位にまとめて順番に記述する\
451451
この際、テーブルの順序は FROM 句に記述した順序に準ずること。
452452
2. 1.のテーブル単位の中で絞り込み条件をまず記述し、その後結合条件を記述する。
453453

@@ -478,7 +478,7 @@ WHERE
478478

479479
## COUNT 文
480480

481-
レコード数を数える COUNT 文の記述は`COUNT(*)`と記述する。
481+
レコード数を数える COUNT 文の記述は`COUNT(*)`と記述する。\
482482
`COUNT(1)``COUNT('X')``COUNT(KEY1)`という記載は NG。
483483

484484
# SQL コーディング規約(パフォーマンス性)
@@ -492,8 +492,8 @@ WHERE
492492
- 中間一致、後方一致検索はインデックスを利用できないため避ける
493493
- 検索条件で`=`(等号)を使用できる場合は必ず使用する
494494

495-
`A=1 or A=2`とする方が`A>0 and A<3`などと記述するのよりパフォーマンス上優位な場合が多い。
496-
これは A にインデックスがある場合、`=`であれば、インデックスが有効に使われるためである。
495+
`A=1 or A=2`とする方が`A>0 and A<3`などと記述するのよりパフォーマンス上優位な場合が多い。\
496+
これは A にインデックスがある場合、`=`であれば、インデックスが有効に使われるためである。
497497

498498
- 可能な限り検索条件にパーティションキーの値を指定する
499499
- 全列ワイルドカード「`*`」の使用はせず、カラム名を明記する
@@ -549,8 +549,8 @@ WHERE
549549

550550
更新処理におけるコーディング規約を下記に示す。
551551

552-
- 主キーの値の UPDATE は原則行わない。外部キーがあればエラーになる。
553-
外部キーが無い場合でも、事実上、主キーの値を利用して、検索、更新する場合は、リンクが切れてしまう。
552+
- 主キーの値の UPDATE は原則行わない。外部キーがあればエラーになる。\
553+
外部キーが無い場合でも、事実上、主キーの値を利用して、検索、更新する場合は、リンクが切れてしまう。
554554
- パーティションキーの UPDATE は原則行わない。
555555
- VIEW を使用するデータ更新は禁止。更新は実表に対して行う。
556556

@@ -566,7 +566,7 @@ WITH 句の誤った使い方はパフォーマンスの劣化を招くため、
566566

567567
## DISTINCT 句
568568

569-
DISTINCT は、暗黙のソート処理が行われる可能性があるため性能劣化につながる。
569+
DISTINCT は、暗黙のソート処理が行われる可能性があるため性能劣化につながる。\
570570
EXISTS 句の使用・代替を検討すること。
571571

572572
悪い例:
@@ -604,13 +604,13 @@ WHERE
604604

605605
## IN 句
606606

607-
IN 句は最大 1000 個まで指定できるが、200 個程度でも ORA エラーが発生するケースがある。
608-
また IN 句の少しだけ異なる SQL が大量に発行されると CPU 高騰やメモリ枯渇を招く。
607+
IN 句は最大 1000 個まで指定できるが、200 個程度でも ORA エラーが発生するケースがある。\
608+
また IN 句の少しだけ異なる SQL が大量に発行されると CPU 高騰やメモリ枯渇を招く。\
609609
従って 100 を超えるような長い IN 句は使用せず、一時表を利用して `IN (SELECT ・・・ FROM 一時表)`のように書き換える。
610610

611611
## NOT IN 句
612612

613-
原則`NOT IN(SELECT~)`は使用せずに、`NOT EXISTS (SELECT~)`を使用する。
613+
原則`NOT IN(SELECT~)`は使用せずに、`NOT EXISTS (SELECT~)`を使用する。\
614614
`NOT IN`句は、内部的にソートマージの結合をすることでテーブルをフルスキャンする場合があるため、性能が悪化する可能性がある。
615615

616616
## UNION 句
@@ -623,10 +623,10 @@ IN 句は最大 1000 個まで指定できるが、200 個程度でも ORA エ
623623

624624
## SELECT FOR UPDATE
625625

626-
- `SELECT FOR UPDATE``NO WAIT`または「`WAIT`秒数指定」を必ず付ける。
627-
`WAIT`指定なしの場合はロックが解除されてもプログラムに制御が返らないことがある。
628-
※WAIT 秒数指定を行う際の秒数は各開発者で決めるのではなくプロジェクトで決定した方針に従うこと。
629-
また、SQL ライブラリを利用していて定数が記述できる場合は定数で記述すること。
626+
- `SELECT FOR UPDATE``NO WAIT`または「`WAIT`秒数指定」を必ず付ける。\
627+
`WAIT`指定なしの場合はロックが解除されてもプログラムに制御が返らないことがある。\
628+
※WAIT 秒数指定を行う際の秒数は各開発者で決めるのではなくプロジェクトで決定した方針に従うこと。\
629+
また、SQL ライブラリを利用していて定数が記述できる場合は定数で記述すること。
630630
- `SELECT FOR UPDATE`で複数行にロックをかける場合、同時実行されるとデットロックを起こす可能性があるため、1件のロックでない場合は`ORDER BY`を指定する。
631631

632632
## 分析関数

0 commit comments

Comments
 (0)