coding-standards
プロジェクト横断的なコーディング規約として、命名規則・可読性・イミュータビリティ・コード品質レビューの基準を定めます。フレームワーク固有のパターンには、フロントエンドまたはバックエンド向けの詳細スキルを併用してください。
description の原文を見る
Baseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns.
SKILL.md 本文
コーディング標準 & ベストプラクティス
プロジェクト横断で適用可能なベースラインコーディング規約です。
このスキルは共有の最低限の基準であり、詳細なフレームワーク・プレイブックではありません。
- React、state、フォーム、レンダリング、UI アーキテクチャについては
frontend-patternsを使用してください。 - リポジトリ・サービスレイヤー、エンドポイント設計、検証、サーバー固有の関心事については
backend-patternsまたはapi-designを使用してください。 - 完全なスキル解説の代わりに最短で再利用可能なルールレイヤーが必要な場合は
rules/common/coding-style.mdを使用してください。
アクティベーションのタイミング
- 新しいプロジェクトまたはモジュールを開始するとき
- コード品質と保守性のためにコードレビューを行うとき
- 既存コードをリファクタリングして規約に従わせるとき
- 命名、フォーマット、または構造の一貫性を強制するとき
- linting、フォーマット、または型チェックルールをセットアップするとき
- 新しい貢献者にコーディング規約をオンボーディングするとき
スコープ境界
このスキルをアクティベートする対象:
- 説明的な命名
- イミュータビリティのデフォルト
- 可読性、KISS、DRY、YAGNI の強制
- エラーハンドリングの期待値とコードスメルのレビュー
このスキルを主要なソースとして使用しない対象:
- React のコンポジション、フック、またはレンダリングパターン
- バックエンド アーキテクチャ、API 設計、またはデータベースレイヤリング
- より狭い ECC スキルが既に存在する場合のドメイン固有のフレームワークガイダンス
コード品質の原則
1. 可読性を最優先
- コードは書かれるよりも読まれる
- 明確な変数名と関数名
- コメントよりも自己ドキュメント化されたコード
- 一貫したフォーマット
2. KISS (Keep It Simple, Stupid)
- 機能する最もシンプルなソリューション
- 過度なエンジニアリングを避ける
- 早すぎる最適化なし
- 理解しやすさ > クレバーなコード
3. DRY (Don't Repeat Yourself)
- 共通ロジックを関数に抽出する
- 再利用可能なコンポーネントを作成する
- モジュール全体でユーティリティを共有する
- コピー・ペーストプログラミングを避ける
4. YAGNI (You Aren't Gonna Need It)
- 必要になるまで機能を構築しない
- 投機的な汎用化を避ける
- 必要な場合にのみ複雑さを追加する
- シンプルに始めて、必要に応じてリファクタリングする
TypeScript/JavaScript 標準
変数命名
// PASS: GOOD: 説明的な名前
const marketSearchQuery = 'election'
const isUserAuthenticated = true
const totalRevenue = 1000
// FAIL: BAD: 不明確な名前
const q = 'election'
const flag = true
const x = 1000
関数命名
// PASS: GOOD: 動詞-名詞パターン
async function fetchMarketData(marketId: string) { }
function calculateSimilarity(a: number[], b: number[]) { }
function isValidEmail(email: string): boolean { }
// FAIL: BAD: 不明確または名詞のみ
async function market(id: string) { }
function similarity(a, b) { }
function email(e) { }
イミュータビリティパターン (重要)
// PASS: スプレッド演算子を常に使用する
const updatedUser = {
...user,
name: 'New Name'
}
const updatedArray = [...items, newItem]
// FAIL: 直接変更してはいけない
user.name = 'New Name' // BAD
items.push(newItem) // BAD
エラーハンドリング
// PASS: GOOD: 包括的なエラーハンドリング
async function fetchData(url: string) {
try {
const response = await fetch(url)
if (!response.ok) {
throw new Error(`HTTP ${response.status}: ${response.statusText}`)
}
return await response.json()
} catch (error) {
console.error('Fetch failed:', error)
throw new Error('Failed to fetch data')
}
}
// FAIL: BAD: エラーハンドリングなし
async function fetchData(url) {
const response = await fetch(url)
return response.json()
}
Async/Await のベストプラクティス
// PASS: GOOD: 可能な場合は並列実行
const [users, markets, stats] = await Promise.all([
fetchUsers(),
fetchMarkets(),
fetchStats()
])
// FAIL: BAD: 不要な順序実行
const users = await fetchUsers()
const markets = await fetchMarkets()
const stats = await fetchStats()
型安全性
// PASS: GOOD: 適切な型
interface Market {
id: string
name: string
status: 'active' | 'resolved' | 'closed'
created_at: Date
}
function getMarket(id: string): Promise<Market> {
// Implementation
}
// FAIL: BAD: 'any' を使用
function getMarket(id: any): Promise<any> {
// Implementation
}
React のベストプラクティス
コンポーネント構造
// PASS: GOOD: 型を持つ関数型コンポーネント
interface ButtonProps {
children: React.ReactNode
onClick: () => void
disabled?: boolean
variant?: 'primary' | 'secondary'
}
export function Button({
children,
onClick,
disabled = false,
variant = 'primary'
}: ButtonProps) {
return (
<button
onClick={onClick}
disabled={disabled}
className={`btn btn-${variant}`}
>
{children}
</button>
)
}
// FAIL: BAD: 型なし、構造が不明確
export function Button(props) {
return <button onClick={props.onClick}>{props.children}</button>
}
カスタムフック
// PASS: GOOD: 再利用可能なカスタムフック
export function useDebounce<T>(value: T, delay: number): T {
const [debouncedValue, setDebouncedValue] = useState<T>(value)
useEffect(() => {
const handler = setTimeout(() => {
setDebouncedValue(value)
}, delay)
return () => clearTimeout(handler)
}, [value, delay])
return debouncedValue
}
// 使用方法
const debouncedQuery = useDebounce(searchQuery, 500)
State Management
// PASS: GOOD: 適切な state 更新
const [count, setCount] = useState(0)
// 前の state に基づいた state 更新のための関数形式
setCount(prev => prev + 1)
// FAIL: BAD: 直接 state 参照
setCount(count + 1) // 非同期シナリオで古くなる可能性がある
条件付きレンダリング
// PASS: GOOD: 明確な条件付きレンダリング
{isLoading && <Spinner />}
{error && <ErrorMessage error={error} />}
{data && <DataDisplay data={data} />}
// FAIL: BAD: 三項演算子地獄
{isLoading ? <Spinner /> : error ? <ErrorMessage error={error} /> : data ? <DataDisplay data={data} /> : null}
API 設計標準
REST API 規約
GET /api/markets # すべてのマーケットをリストアップ
GET /api/markets/:id # 特定のマーケットを取得
POST /api/markets # 新しいマーケットを作成
PUT /api/markets/:id # マーケットを更新 (完全)
PATCH /api/markets/:id # マーケットを更新 (部分)
DELETE /api/markets/:id # マーケットを削除
# フィルタリング用クエリパラメータ
GET /api/markets?status=active&limit=10&offset=0
レスポンスフォーマット
// PASS: GOOD: 一貫したレスポンス構造
interface ApiResponse<T> {
success: boolean
data?: T
error?: string
meta?: {
total: number
page: number
limit: number
}
}
// 成功レスポンス
return NextResponse.json({
success: true,
data: markets,
meta: { total: 100, page: 1, limit: 10 }
})
// エラーレスポンス
return NextResponse.json({
success: false,
error: 'Invalid request'
}, { status: 400 })
入力検証
import { z } from 'zod'
// PASS: GOOD: スキーマ検証
const CreateMarketSchema = z.object({
name: z.string().min(1).max(200),
description: z.string().min(1).max(2000),
endDate: z.string().datetime(),
categories: z.array(z.string()).min(1)
})
export async function POST(request: Request) {
const body = await request.json()
try {
const validated = CreateMarketSchema.parse(body)
// 検証済みデータで処理を続行
} catch (error) {
if (error instanceof z.ZodError) {
return NextResponse.json({
success: false,
error: 'Validation failed',
details: error.errors
}, { status: 400 })
}
}
}
ファイル構成
プロジェクト構造
src/
├── app/ # Next.js App Router
│ ├── api/ # API ルート
│ ├── markets/ # マーケットページ
│ └── (auth)/ # Auth ページ (ルートグループ)
├── components/ # React コンポーネント
│ ├── ui/ # 汎用 UI コンポーネント
│ ├── forms/ # フォームコンポーネント
│ └── layouts/ # レイアウトコンポーネント
├── hooks/ # カスタム React フック
├── lib/ # ユーティリティとコンフィグ
│ ├── api/ # API クライアント
│ ├── utils/ # ヘルパー関数
│ └── constants/ # 定数
├── types/ # TypeScript 型
└── styles/ # グローバルスタイル
ファイル命名
components/Button.tsx # コンポーネント用 PascalCase
hooks/useAuth.ts # 'use' プレフィックス付き camelCase
lib/formatDate.ts # ユーティリティ用 camelCase
types/market.types.ts # .types サフィックス付き camelCase
コメント & ドキュメント
コメントのタイミング
// PASS: GOOD: WHY を説明し、WHAT ではない
// 停止時に API を圧倒しないため指数バックオフを使用
const delay = Math.min(1000 * Math.pow(2, retryCount), 30000)
// 大きな配列でのパフォーマンスのため意図的に変更を使用
items.push(newItem)
// FAIL: BAD: 明白なことを述べている
// カウンタを 1 ずつ増加させる
count++
// 名前をユーザーの名前に設定する
name = user.name
パブリック API 用 JSDoc
/**
* セマンティック類似性を使用してマーケットを検索します。
*
* @param query - 自然言語検索クエリ
* @param limit - 結果の最大数 (デフォルト: 10)
* @returns 類似度スコアでソートされたマーケット配列
* @throws {Error} OpenAI API が失敗するか、Redis が利用不可の場合
*
* @example
* ```typescript
* const results = await searchMarkets('election', 5)
* console.log(results[0].name) // "Trump vs Biden"
* ```
*/
export async function searchMarkets(
query: string,
limit: number = 10
): Promise<Market[]> {
// Implementation
}
パフォーマンスのベストプラクティス
メモ化
import { useMemo, useCallback } from 'react'
// PASS: GOOD: 計算コストの高い処理をメモ化
const sortedMarkets = useMemo(() => {
return markets.sort((a, b) => b.volume - a.volume)
}, [markets])
// PASS: GOOD: コールバックをメモ化
const handleSearch = useCallback((query: string) => {
setSearchQuery(query)
}, [])
レイジーローディング
import { lazy, Suspense } from 'react'
// PASS: GOOD: 重いコンポーネントをレイジーロード
const HeavyChart = lazy(() => import('./HeavyChart'))
export function Dashboard() {
return (
<Suspense fallback={<Spinner />}>
<HeavyChart />
</Suspense>
)
}
データベースクエリ
// PASS: GOOD: 必要なカラムのみ選択
const { data } = await supabase
.from('markets')
.select('id, name, status')
.limit(10)
// FAIL: BAD: すべてを選択
const { data } = await supabase
.from('markets')
.select('*')
テスト標準
テスト構造 (AAA パターン)
test('calculates similarity correctly', () => {
// Arrange
const vector1 = [1, 0, 0]
const vector2 = [0, 1, 0]
// Act
const similarity = calculateCosineSimilarity(vector1, vector2)
// Assert
expect(similarity).toBe(0)
})
テスト命名
// PASS: GOOD: 説明的なテスト名
test('returns empty array when no markets match query', () => { })
test('throws error when OpenAI API key is missing', () => { })
test('falls back to substring search when Redis unavailable', () => { })
// FAIL: BAD: あいまいなテスト名
test('works', () => { })
test('test search', () => { })
コードスメル検出
これらのアンチパターンに注意してください:
1. 長い関数
// FAIL: BAD: 50 行以上の関数
function processMarketData() {
// 100 行のコード
}
// PASS: GOOD: より小さな関数に分割
function processMarketData() {
const validated = validateData()
const transformed = transformData(validated)
return saveData(transformed)
}
2. 深いネスト
// FAIL: BAD: 5 レベル以上のネスト
if (user) {
if (user.isAdmin) {
if (market) {
if (market.isActive) {
if (hasPermission) {
// 何かをする
}
}
}
}
}
// PASS: GOOD: 早期リターン
if (!user) return
if (!user.isAdmin) return
if (!market) return
if (!market.isActive) return
if (!hasPermission) return
// 何かをする
3. マジックナンバー
// FAIL: BAD: 説明のない数字
if (retryCount > 3) { }
setTimeout(callback, 500)
// PASS: GOOD: 名前付き定数
const MAX_RETRIES = 3
const DEBOUNCE_DELAY_MS = 500
if (retryCount > MAX_RETRIES) { }
setTimeout(callback, DEBOUNCE_DELAY_MS)
覚えておいてください: コード品質は妥協の余地がありません。明確で保守性の高いコードは、迅速な開発と自信を持ったリファクタリングを可能にします。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- affaan-m
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/affaan-m/everything-claude-code / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。