コーディングルールはマジでしっかり決めろって話
どうも、フリーランスエンジニアの人です。 今まで関わったプロジェクトにおいてコーディングルールが曖昧だった環境で苦労したので、例に出しながら振り返ろうと思います。 ※ 本記事に登場するコード例は実際に存在するコードではありませんがヤバさは忠実に再現しました。 2022/11/5 追記 曖昧かつ実態のズレた変数名 変数の命名というものはエンジニアによって少々偏った傾向が見られますが、その変数が指し示す実態と命名に大きなズレがなく、主旨が伝わればエンジニアリングにおいて大きな問題はないはずです。 ですが、世の中には曖昧かつ実態と一致しない変数名が書かれたプロダクトコードが存在します。 以下のコードをご覧ください。 ※ 今回はJSを例に出します // ユーザーのデータを取得 export const getUserData = async (id) => { const res = await
JavaScript Standard Style
JavaScript Standard Style English • Español (Latinoamérica) • Français • Bahasa Indonesia • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin) これは、standardなJavaScriptのルールの概要です。 standardを学ぶための最も良い方法は、ただインストールしてあなたのコードで試してみることです。 ルール インデントには2個のスペースを使用する。 eslint: indent function hello (name) { console.log('hi', name) } エスケープ
C# CODING GUIDELINES - Qiita
目次 目次 このドキュメントについて 本書の目的 開発環境 Visual Studio 命名規則 サンプルコード 共通スタイルの説明 二文字の名前(※変更) 名前空間 アセンブリ リソース ファイル クラス フィールド(※変更) 静的フィールド(≒グローバル変数)(※追加) コントロールのフィールド(※変更) プロパティ メソッド(≒関数、サブルーチン、ファンクション) 非同期メソッド(※追加) パラメータ(≒引数) ローカル変数、ループ変数 コンパイル時定数、実行時定数 抽象クラス インターフェイス デリゲート(≒関数ポインタ) イベント 構造体 列挙体 コーディング規則 レイアウト規則 コメント規則 長い名前 多い引数 多い演算子 自動プロパティ(※変更) 空のコンストラクタ(※追加) イベント処理(※変更) イディオム タブとスペースではスペースを使う ifの中括弧の省略はしない 否
Python のコーディング規約 PEP8 に準拠する - Qiita
この Qiita の連載記事ではデータ分析のための主要言語として Python を利用してきました。ところでみなさんは Python のコーディング規約 PEP8 をご存知でしょうか。 ソースコードスタイルガイド PEP8 ソースコードは一般に「書かれる時間」よりも「読まれる時間」の方が長い、そのような事実に基づいて、「スタイルを統一し読みやすいコードを書こう」というアイデアのもとに作られたのがこのガイドです。 Style Guide for Python Code http://legacy.python.org/dev/peps/pep-0008/ 本家は当然ながら英語ですが有志の方が日本語に翻訳してくださっています。 PEP8 日本語訳 https://github.com/mumumu/pep8-ja どちらにせよ Python を利用する方は必ず一読するべきかと思います。 自動的
Javaではif (isAdmin == true)というコードを書いてはいけない - Qiita
はじめに 当たり前だと思うのですが、意外と守られていないことがあります。その1つの例として、条件分岐でのbooleanの扱いを挙げてみます。 ~~タイトルには「Javaでは」と書きましたが、おそらくどの言語でも同じです。~~JavaScriptなど他の言語では当てはまらないので取り消します1。 何がダメか 明確にコーディング規約で否定しているケースもありますが2、Javaでは以下のようなコードは書いてはいけません。 if (isAdmin == true) { // isAdminがtrueのとき } if (isAdmin == false) { // isAdminがfalseのとき }
Pythonのコーディング規約PEP8を要約してみる(2) - Qiita
ドキュメンテーション文字列(別名 “docstrings”) すべてのモジュールや関数、クラス、メソッドにはdocstringを書くべき. 命名規約 一番重要な原則 実装よりも使い方を反映した名前にする 実践されている命名方法 b (小文字1文字) B (大文字1文字) lowercase lower_case_with_underscores UPPERCASE UPPER_CASE_WITH_UNDERSCORES CapitalizedWords 守るべき命名規約 ・単一の文字 ‘l’ (小文字のエル)、’O’ (大文字のオー)、’I’(大文字のアイ) を変数として使ってはならない ・モジュールの名前は、全て小文字の短い名前にする ・クラスの名前にはCapWords方式(単語の頭文字を大文字にしてつなげる)を使う ・モジュール内限定グローバル変数は頭にアンダースコア(_)をつけて外部
こんなHTMLとCSSのコーディング規約で書きたい - Qiita
HTML と CSS のコーディングルールを作ろう HTML と CSS のコーディング規約を中心に、メンテナンス性の良い HTML や CSS をコーディングする際に重要だと思うポイントをまとめています。 誰に向けた記事か この記事には、HTML や CSS を書く人に役立ちそうな内容が書いてあります。 特に初級者から中級者の方で、HTML や CSS を一通り学習した方からの反応が良いです。 まだ HTML や CSS の学習を始めて間もないという方は、先に案件やプロジェクトをこなしコーディング経験を積むことをお勧めします。経験を積むとよりこの記事の内容への理解が深まるはずです。 HTML と CSS を書くときに大切なポイント2点 HTML と CSS を書くときに大切だと思うことを書きます。 1. HTML と CSS を書かない あなたがいま書いている HTML と CSS は、
C#コーディング規約の個人的なまとめ
コーディング規約は非常に色々なものが提案されているが、その色々なものを見て来た中で、かなり自分勝手な方向でまとめてみる。 はじめに コーディング規約というのは、さまざまな団体で独自に定められており、時にはそれが競合することもあろうかと思う。特にC++のプレフィックス関連が顕著だと思う。それに比べて、C#は割りと落ち着いたコーディング規約が根付いているのか、私の短いプログラミング人生の中で、そこまで読みにくいと思ったコードを見たことがない。これは、C#の言語構造やVisualStudioの自動整形も関係しているのかもしれないが。 というわけで、厳格なコーディング規約を設けずとも、それなりに読めてしまうC#でも、やはり規約を定めて、より読みやすく、統一性を持たせたコードを生産することは、非常に有意義なことだと考える。 代表的な記法 C#の命名規約についてを参考にしてほしい。一部を抜粋しておく。
C#の命名規約について
今後に向けて、ある程度統一しといたほうが身のためかと思い、C#のコーディング規約について勉強している。その中で、いろいろな規約が提案されているわけだけど、C#で書くなら、Microsoftさんの言いなりになろうかと思ってるわけだ。 近くに転がってたC#コーディング規約について言及した本を拾い読みしてみるものの、どうもしっくりこない。というより、.NETの標準に従ってないところが多かった。例えば、定数は全部大文字で、単語はアンダーバー（_）で区切るなど。 転がってた本（＝本） コーディングし疲れて深夜に帰る直前に偶然見つけた書。どうやら出版社が倒産して、絶版になっているらしい。全頁がカラーで大変読みやすいし、内容もわかりやすい構成だが、準拠している規約が公式ガイドラインじゃないので、今回の場合だと参考にならない面もある。 クラス ライブラリ開発者向けのデザイン ガイドライン（＝公式ガイドライ
.NET コーディング規則 - C#
コーディング規則は、開発チーム内でコードの読みやすさ、一貫性、コラボレーションを維持するために不可欠です。 業界のプラクティスと確立されたガイドラインに従っているコードは、理解、保守、拡張が容易です。 ほとんどのプロジェクトでは、コード規則を通じて一貫したスタイルが適用されます。 dotnet/docs プロジェクトと dotnet/samples プロジェクトも例外ではありません。 この一連の記事では、コーディング規則と、それらを適用するために使用するツールについて説明します。 規則をそのまま使用することも、チームのニーズに合わせて変更することもできます。 次のゴールに基づいて規則を選択しました。 正確性: サンプルがコピーされ、アプリケーションに貼り付けられます。 そのため、複数の編集を行った後でも、回復性と正確性を備えたコードを作成する必要があります。 教育: サンプルの目的は、.N
Rubyコーディング規約
はじめに 本文書は、Rubyによりコーディングを行う際の規約について述べる。 実際のプロジェクトに適用する際には、このコーディング規約をカスタ マイズして用いることを推奨する。 ソースコードの整形 インデント プログラムを読みやすくするため、インデントを適宜行う。インデント 幅は2とする。また、インデントにはスペースのみを使用し、タブは使用 しない。(環境によりタブ幅が異なるため。) 例: if x > 0 if y > 0 puts "x > 0 && y > 0" end end 一行の桁数 一行の桁数は最大80桁までとする。 空行 複数のクラスの区切には空行を挿入する。 例: class Foo ... end class Bar ... end 誤った例: class Foo ... end class Bar ... end また、クラス内の各構成要素の区切にも空行を挿入する。
PHPコーディング規約まとめ - Qiita
結論 いきなり結論 利用しているフレームワークの規約がないなら、 PSR-2（日本語） に従っておけば、間違いない! あとは、コマンドラインなり、エディタで自動整形する * PHPコードをコマンドで自動整形! Condig Standards Fixer と PHP_CodeSniffer - Qiita 日本語なら以下がお勧め! PHPのコーディング規約 PSR-0、PSR-1、PSR-2、PSR-3とは | 9ensanのLifeHack 以下、コーディング規約とツールまとめ 目的 個人向け: PHPの開発をする場合、どのコーディング規約に従うべきか? をサクッと知りたい チーム向け: チームでどれを使うか? を決めるための参考に 教育: この規約でやって!と一言で教えるための参考URL PHPコーディング規約の種類 PEARコーディング規約 や Zend Codig Starndar
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新標準PSRに学ぶきれいなPHP