回答編集履歴

2 typo

Chironian

Chironian score 20494

2015/11/07 11:55  投稿

こんにちは。楽しいテーマをありがとう。
自分自身としては、(発展途上ですが)下記ルールでコーディングしています。(もちろん決められた規約がある時はそれに従ってます。チーム開発時、私が規約を決める時はもう少し異なる視点で緩やかに決めます。)
> ①if の条件式で定数は右辺?左辺?
私はコンパイラの警告に頼って左辺です。もちろん、コンパイラの警告は全て消す主義です。
私はコンパイラの警告に頼って右辺です。もちろん、コンパイラの警告は全て消す主義です。
> ②if, for, switch, whileの中括弧はifと同じ行?次の行??
両方やってみたのですが、今は、中括弧の中身が少ない場合は同じ行、多い場合は次の行にすると使い勝手が良いと感じてます。
高々2~3行の時に{で1行消費すると却って見難くなります。数十行ある時に同じ行にしているとブロックの開始位置がパッと見で見つかりにくくなるからです。
> ③インデントはタブ派?スペース派?
ソースは他の人へ渡す可能性が高いのでエディタの機能でスペースへ変換してます。
秀丸を使っているのですが、保存して再度開いた時に初めてスペースに変わるので、なかなか使い勝手が良いです。
**④論理的な区切りをコメントで目立たせてます**
大きな区切りほど目立つコメントとしてます。
論理的な構造を強調して視覚化することで、頭に入って来やすいように心がけてます。
**⑤識別子の長さ**
なるべく単語の一部を略さないようにしています。でも、似たような処理の微妙に異なる変数名は異様に長くなりやすいです。
長過ぎる識別子の目立たない一部が異なると可読性が極端に落ちるし、タイプミスしやすくなるので、そのような時は諦めて省略しています。
識別子の長さが20文字を超えてくるとつらいです。
**⑥行の長さ**
Google Styleで80文字を推奨しているので、なるべく80文字を超えないようにしてます。
でも、改行せずに並べた方が見やすいケースがあります。(例えば、switch-caseで各case文が1行でほとんど同じことをしているような時等)
そのような時は、A4縦印刷できる上限を限度に1行に入れた方が良いかもと最近感じているところです。
**⑦変数の宣言形式**
良く言われるのがポインタの*をどちらに付けるかですね。
```C++
char*  p;
char  *p;
```
意味としては前者の方が理解しやすい(char*型の変数p)ので、前者としています。
最近は、char* p, q;問題ではコンパイラがエラーや警告してくれるので酷いことにはならない筈です。
むしろ、CやC++言語は型の修飾子がどの順序で付くのか非常に分かり難いので、それを少しでも把握しやすいように心がけるよう努力してます。
---
気にしている人は少ないと思いますが、下記の選択もありますね。
```C++
const char* p;
char const* p;
```
今まで前者で書いていたのですが、どうも意味的には後者の方がすっきりすることに最近気が付きました。
const, volatile, *, &, []は型の修飾子であり、[]を除き、修飾子は型の右側から修飾すると考えるのです。
つまり、より左側にある修飾子の方が元の型と密に結びついてます。
「char型←それはconst←そこへのポインタ」って感じです。
日本語的にはconstなchar型へのポインタなのでconst char*は妥当なのですが、constな「char型へのポインタ」(char* const p;)と混同しやすいです。
「char型←そこへのポインタ←それはconst」の方が分かりやすいように感じてます。
ただ、[]をこのルールに当てはめることができないので残念です。
int[5] data;って書けないし、int data[10][5];は、data[10]が5個あるのではなく、data[5]が10個ですし。
1 typo

Chironian

Chironian score 20494

2015/11/07 11:54  投稿

こんにちは。楽しいテーマをありがとう。
自分自身としては、(発展途上ですが)下記ルールでコーディングしています。(もちろん決められた規約がある時はそれに従ってます。チープ開発時、私が規約を決める時はもう少し異なる視点で緩やかに決めます。)
自分自身としては、(発展途上ですが)下記ルールでコーディングしています。(もちろん決められた規約がある時はそれに従ってます。チーム開発時、私が規約を決める時はもう少し異なる視点で緩やかに決めます。)
> ①if の条件式で定数は右辺?左辺?
私はコンパイラの警告に頼って左辺です。もちろん、コンパイラの警告は全て消す主義です。
> ②if, for, switch, whileの中括弧はifと同じ行?次の行??
両方やってみたのですが、今は、中括弧の中身が少ない場合は同じ行、多い場合は次の行にすると使い勝手が良いと感じてます。
高々2~3行の時に{で1行消費すると却って見難くなります。数十行ある時に同じ行にしているとブロックの開始位置がパッと見で見つかりにくくなるからです。
> ③インデントはタブ派?スペース派?
ソースは他の人へ渡す可能性が高いのでエディタの機能でスペースへ変換してます。
秀丸を使っているのですが、保存して再度開いた時に初めてスペースに変わるので、なかなか使い勝手が良いです。
**④論理的な区切りをコメントで目立たせてます**
大きな区切りほど目立つコメントとしてます。
論理的な構造を強調して視覚化することで、頭に入って来やすいように心がけてます。
**⑤識別子の長さ**
なるべく単語の一部を略さないようにしています。でも、似たような処理の微妙に異なる変数名は異様に長くなりやすいです。
長過ぎる識別子の目立たない一部が異なると可読性が極端に落ちるし、タイプミスしやすくなるので、そのような時は諦めて省略しています。
識別子の長さが20文字を超えてくるとつらいです。
**⑥行の長さ**
Google Styleで80文字を推奨しているので、なるべく80文字を超えないようにしてます。
でも、改行せずに並べた方が見やすいケースがあります。(例えば、switch-caseで各case文が1行でほとんど同じことをしているような時等)
そのような時は、A4縦印刷できる上限を限度に1行に入れた方が良いかもと最近感じているところです。
**⑦変数の宣言形式**
良く言われるのがポインタの*をどちらに付けるかですね。
```C++
char*  p;
char  *p;
```
意味としては前者の方が理解しやすい(char*型の変数p)ので、前者としています。
最近は、char* p, q;問題ではコンパイラがエラーや警告してくれるので酷いことにはならない筈です。
むしろ、CやC++言語は型の修飾子がどの順序で付くのか非常に分かり難いので、それを少しでも把握しやすいように心がけるよう努力してます。
---
気にしている人は少ないと思いますが、下記の選択もありますね。
```C++
const char* p;
char const* p;
```
今まで前者で書いていたのですが、どうも意味的には後者の方がすっきりすることに最近気が付きました。
const, volatile, *, &, []は型の修飾子であり、[]を除き、修飾子は型の右側から修飾すると考えるのです。
つまり、より左側にある修飾子の方が元の型と密に結びついてます。
「char型←それはconst←そこへのポインタ」って感じです。
日本語的にはconstなchar型へのポインタなのでconst char*は妥当なのですが、constな「char型へのポインタ」(char* const p;)と混同しやすいです。
「char型←そこへのポインタ←それはconst」の方が分かりやすいように感じてます。
ただ、[]をこのルールに当てはめることができないので残念です。
int[5] data;って書けないし、int data[10][5];は、data[10]が5個あるのではなく、data[5]が10個ですし。

思考するエンジニアのためのQ&Aサイト「teratail」について詳しく知る