プログラミング言語のPython や MicroPython でコードを書くときの 基本ルール や 日本語対応 について、わかりやすくまとめます。

Picoのプログラミング言語は、WindowsでMicroPythonで記述していきます。
MicroPythonはPythonの軽量版になります。
他にも、Picoで使用できる言語は、C/C++、CircuitPythonがありますがここでは使用しません。

基本的な記述ルール（文法）

項目Python / MicroPython 共通ルール
インデントスペース4つが基本（タブ不可）→ インデントでブロックを示す（C言語の {} の代わり）
文末のセミコロン不要（つけても動くが推奨されない）
変数名アルファベット（英語）＋数字 + アンダースコア _例：temperature, led_state
コメント# を先頭に書く（日本語OK）例：# 温度を読み取る
関数定義def 関数名():例：def read_sensor():
文字列'文字' または "文字" で囲む
比較演算子==, !=, <, >, <=, >=
ブール値True, False（先頭大文字）
None（空の値）None（nullの代わり）

MicroPython特有の注意点

特徴説明
ライブラリ制限time, os, random などの一部標準ライブラリが 簡易版または未実装
モジュール制限pandas, matplotlib など 大型ライブラリは使用不可
メモリ制約非常に小さいため、コードはコンパクトに（100行以上の処理は注意）
ファイル名半角英数字、拡張子 .py
ストレージスクリプトファイルは Flash メモリに保存される（機種により数十KB〜）

「100行以上は注意」とは

100行を超えても「整理されていて読みやすい」なら問題ありません。
むしろ「短くても読みにくいコード」の方が問題です。

状況判断基準
✅ 100行未満コンパクトで理想的。読みやすさを意識
⚠️ 100行超そのままでも良いが、分割・整理を検討
❌ 300行以上保守性・可読性に問題がある可能性あり。構造を見直す価値あり
理由説明
🔍 可読性が落ちやすい1つのファイル・関数に情報が詰まりすぎて、読みづらくなる
🛠 保守性が下がる修正時に副作用やバグを生みやすい
🧪 テストしづらい関数が長いと、テストケースも複雑になりがち
♻️ 再利用が難しい小分けされていないと、再利用や他への転用が難しくなる

100行を超えるときのチェックリスト

チェック項目内容
✅ 関数が長すぎないか？1つの関数はできれば20〜30行以内が理想（超えたら分割検討）
✅ 同じ処理を繰り返していないか？似た処理は関数化 or ループ化
✅ コメントで構造が見えるか？セクションごとに**# コメント**で区切って整理
✅ ファイル分割できないか？大規模になったらモジュール分割を検討（ファイル単位）
✅ クラスや関数名は明確か？処理が多いほど命名が重要に

おすすめの対処方法

方法内容
🔹 関数化処理単位を小さな関数に分けて整理
🔹 クラス化状態＋処理がまとまっている場合、クラスで構造化
🔹 モジュール分割複数のファイルに処理を分離して再構成
🔹 コメントとDocstringセクションや関数に説明を入れて、流れを明確に

実例：センサーデータ処理が150行ある場合

今は、何を言われているのかよくわからなくてもOKです。その場面になった時にご説明します。

・各センサー処理をread_temp(), read_humidity()などに関数化
・通信系処理はnetwork.pyに分離
・データ保存処理はstorage.pyに分離
・main.pyには流れだけ書いておく

main.pyとは、パソコンからPicoを切り離して(USB結線を抜いて)、Pico単独で起動して処理すを実行するための実行ファイルです。

日本語の使用について

変数名や関数名に日本語は？

Python / MicroPython日本語名推奨されるか？
変数名・関数名温度 = 25 や def 表示():❌ 非推奨（エラーにはならないが混乱を招く）
コメント# 湿度を読み取る✅ OK（開発者向けの説明として使える）
文字列（表示用）print("温度は25度です")✅ OK（画面出力やUI表示に問題なし）

日本語を使う際の注意点

  • 日本語ファイルを保存する場合は UTF-8 エンコーディングが必要（通常は自動）
  • ファイル冒頭に以下を書くと安心：

# -*- coding: utf-8 -*-

  • エラーメッセージやパスに全角文字が含まれていると、MicroPythonでは文字化けすることもあります

日本語表示（LCDなど）

日本語フォントは？

  • 小型液晶ディスプレイで日本語を表示したい場合、日本語ビットマップフォントを別途用意する必要があります。
  • フォントデータ（例：12x12のドットマトリクス）を読み込んで描画処理する。

おすすめの書き方

項目推奨方法
変数・関数名英語 + アンダースコア（例：read_temp_sensor）
コメント日本語OK。わかりやすい補足を添える
文字列日本語使用OK。LCD表示やログ出力で活用
開発時の注意エディタは VSCode や Thonny など UTF-8 対応のものを使用
ファイル名半角英数字（例：main.py）に限定すること

PEP 8とは？

PEP 8 は「Pythonらしいコード（Pythonic）」を書くためのスタイルガイドです。
可読性を最優先し、チーム開発でも誰が書いても読みやすいコードになるよう定められています。

🧭 PEP 8の主なルール（抜粋）

カテゴリ内容例
✅ インデントスペース4つ（タブ不可）____if x == 1:
✅ 行の長さ最大79文字まで（長すぎる行は改行）-
✅ 空行クラスや関数の間には2行の空白行をdef func1():\n\n\ndef func2():
✅ 変数・関数名スネークケース（小文字+_）user_name, get_temp()
✅ クラス名パスカルケース（先頭大文字＋単語連結）class SensorReader:
✅ 定数名全大文字＋アンダースコアMAX_RETRY = 3
✅ コメント日本語OK。コードの意図を補足する# 温度センサーを初期化
✅ インポート順序標準→サードパーティ→自作モジュール（空行で区切る）import os\nimport requests\nimport mymodule
✅ 比較==, != を使う。 is はID比較（None の時はOK）if x is None:
✅ 余分なスペース式の前後に不必要なスペースは使わない❌ x = 1 → ✅ x = 1
スペース4つ（タブ不可）

公式（PEP 8）による記述

Spaces are the preferred indentation method.
Tabs should be used solely to remain consistent with code that is already indented with tabs.

つまり：
・新しく書くコードでは スペース4つを使うべき
・既存コードがタブで書かれていれば「そのまま維持」も許されるが、原則スペース推奨

❌ タブキーで「タブ文字」を使うのは非推奨（PEP 8違反になる可能性あり）
✅ タブキーを押しても「スペース4つ」になるように設定すればOK
✅ インデントはコードの構造を示すため非常に重要。混在するとバグやエラーの原因になります

理由説明
🔁 環境差異を避けるためエディタやツールによって「タブの表示幅」が違うため、見た目がズレる
💥 混在するとエラーの元Pythonでは**スペースとタブが混ざるとIndentationError**になりやすい
👥 チーム開発の標準化多人数での開発でもコードが統一されて読みやすくなる

✅ 実際のコーディング時は？

操作方法
エディタで Tab を押す「スペース4つ」に変換する設定にする（※後述）
VS CodeTab を押したら自動でスペース4つに設定可能（設定名：Insert Spaces: true, Tab Size: 4）
Thonny など初心者向けIDE初期設定でスペース4つになっていることが多い

✅ VS Code (Visual Studio Code) の設定例

統合開発環境(IDE)のThonnyではなく、VS Codeを使用する場合もあるかも知れないので掲載しておきます。

  1. 設定（Ctrl + ,）を開く
  2. 以下の設定を変更：
    • Insert Spaces → ✅ 有効にする
    • Tab Size → 4
    • Detect Indentation → ❌ 無効にする（統一したい場合）

余分なスペース

❌ 悪い例
def add ( a , b ):
return a + b

✅ 良い例
def add(a, b):
return a + b

🔧 チェックツール（PEP8違反を検出）

ツール名説明
flake8スタイルチェック＋エラーも検出
black自動整形ツール（PEP 8ベース）
pylintPEP 8＋構文・設計・命名規則までチェック