中括弧は自分の行に表示する必要がありますか？
中括弧は独自の行にあるべきか？あなたはそれについてどう思いますか？
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
それとも
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
あるいは
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
建設的になってください！理由を説明し、経験を共有し、事実と参照でそれをバックアップします。
学生時代は同じ行に中括弧を付けていたため、行が少なくなり、コードが印刷されるページが少なくなりました。行の中で唯一のものとして印刷された単一のブラケット文字を見るのは面倒です。 （環境、紙の無駄）
しかし、大規模なアプリケーションをコーディングする場合、中括弧のみを含む一部の行を許可することは、それが与える「グループ化」の感覚を考慮すると手頃な価格です。
どちらのスタイルを選択する場合もconsistentにすることで、自分の頭脳が関連するコードで複数のスタイルを処理するオーバーヘッドにならないようにします。 （上記のような）さまざまなシナリオでは、さまざまなスタイルを使用してもかまわないと思います。高レベルで「コンテキストを切り替える」方が簡単です。
番目の方法は絶対に実行しないでください。
ブレースを省くと、最初は数回のキーストロークを節約できますが、次のコーダーは、ブロックが欠落していることに気付かずにelse句に何かを追加します。
他の人のためにコードを書いてください。
長い間、私はそれらが同等の価値があると主張しました同等に非常に近い正しい選択をすることによって可能な利益ははるかにはるかに議論のコストそれについて。
一貫性が重要ですです。だから、コインを投げてコードを書き始めましょうと言いました。
以前プログラマーがこのような変化に抵抗するのを見てきました。乗り越えろ！私は私のキャリアの中で何度も切り替えました。 C＃でもPowerShellとは異なるスタイルを使用しています。
数年前、私はチーム（約20人の開発者）で作業していて、入力を求め、それから決定を下し、それをすべてのコードベースに適用することにしました。決定するのに1週間あります。
たくさんのうめき声と目が回転しています。多くの「私は自分のやり方が好きです、それがより良いので」、実質はありません。
私たちは質問のより細かい点を研究していたので、誰かがこの問題を同じ線のスタイルで対処する方法を尋ねました：
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
パラメータリストがどこで終わり、本文が始まるかはすぐにはわかりません。と比較：
void MyFunction(
int parameterOne,
int parameterTwo)
{
int localOne,
int localTwo
}
世界中の人々がこの問題にどのように対処したかについていくつか読んだところ、開き括弧の後に空白行を追加するパターンが見つかりました。
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
あなたが視覚的な休憩をするつもりなら、あなたはブレースでそれをすることもできます。次に、視覚的な中断も一貫します。
編集：K＆Rを使用する場合の「余分な空白行」ソリューションの2つの選択肢：
1 /関数本体とは異なる関数引数のインデント
2 /最初の引数を関数名と同じ行に置き、新しい行の追加の引数をその最初の引数に揃えます
例：
1 /
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
2 /
void MyFunction(int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
/編集
一貫性は他の考慮事項よりも重要であると私はまだ主張しますが、確立された前例がない場合は、brace-on-next-lineが適しています。
基本的なルールは次のとおりです。
- プロジェクトの既存のコーディング標準に従ってください。
- コーディング標準がなく、他の誰かが所有している既存のコードベースを編集している場合-どれだけ好きでも嫌いでも、既存のコードのスタイルと一致している必要があります。
- グリーンフィールドプロジェクトに取り組んでいる場合-他のチームメンバーと話し合い、公式または非公式のコーディング標準について合意に達してください。
- 唯一の開発者としてグリーンフィールドプロジェクトに取り組んでいる場合-自分の考えを作り、それから冷酷に一貫しているになります。
外部に制約がない場合でも（IMO）は、既存の（広く使用されている）コーディング標準またはスタイルのガイドラインを探し、それに従うことをお勧めします。自分のスタイルを出したら、あと数年で後悔することになるだろう。
最後に、既存のスタイルチェッカーとコードフォーマッタを使用して実装/実装可能なスタイルは、手動で「強制」する必要があるスタイルよりも優れています。
最初の方法の利点は、縦方向にコンパクトになるため、画面により多くのコードを配置できることです。そのため、私はそれを好みます。 2番目の方法を支持して聞いた唯一の議論は、開始ブラケットと終了ブラケットをペアにするのが簡単になるということですが、ほとんどのIDEにはそのためのキーボードショートカットがあり、それは実際には誤ったステートメントです-開始ブラケットと終了ブラケットをペアにするのではありません括弧閉じ括弧を同じインデントレベルの「ブロックの開始」式（if、else、for、while）とペアにすることができるため、ブロックの開始位置を簡単に判別できます。
前のfor/while/if構文がすでに視覚的にブロックの開始を示している場合、ブラケットだけで行全体を無駄にする理由はありません。
とは言っても、ブロックの終わりとそのインデント構造を目に見える形で示すために何かが必要であるため、閉じ括弧はそれ自体の行にあるべきだと私は確信しています。
私は好む
_if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
_以上
_if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
_you.postAnswer();という行は、一見すると読みやすく、見つけやすいためです。 2番目の方法では、それはその上の行（you.hasAnswer()）と調和し、それを読むために目をもっと集中する必要があります。
私は最初の方法を好みます。ブレースは完全に別の行の価値はありません。
ブレースは重要ではないということです。それらは単なる構文上のゴミです。これは、コードの目的、コードの目的、およびコードの実装方法を理解する上でまったく必要ありません。これらは、使用可能な画面スペースが少ないために演算子を視覚的にグループ化することができなかった古いスタイルのCのような言語への賛辞にすぎません。
中括弧がなくても問題ない言語（Python、Haskell、Ruby）があります。これは、ブレースがゴミであることを確認するだけであり、可能な場合はいつでもそれらの行に値するべきではありません。
if (you.hasAnswer()){
you.postAnswer();
}else{
you.doSomething();
}
Pythonを使用し、引数を完全に回避します。
中括弧の位置は
メタデータ
プログラマーはIDE=で構成できます。このように、作成者に関係なく、すべてのコードの厄介な中括弧は同じに見えます。
この例では間違いを見つけるのが難しいので、私は最初の方を好みます。
if (value > maximum);
{
dosomething();
}
この例よりも
if (value > maximum); {
dosomething();
}
; {は、;で終わる行よりも私にとっては見た目が悪いので、気付く可能性が高くなります。
場合によります。
JavascriptまたはjQueryでコーディングしている場合、最初の形式を使用します。
jQuery(function($) {
if ($ instanceOf jQuery) {
alert("$ is the jQuery object!");
}
});
ただし、C＃でコーディングしている場合は、2番目の形式を使用します。これは、C＃で行うための標準的な方法だからです。
public int CalculateAge(DateTime birthDate, DateTime now)
{
int age = now.Year - birthDate.Year;
if (now.Month < birthDate.Month
|| (now.Month == birthDate.Month && now.Day < birthDate.Day))
age--;
return age;
}
あなたの例は書くことができることに注意してください
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
c＃で。
私は1）のわずかな変形を好む
if (you.hasAnswer()) {
you.postAnswer();
} // note the break here
else {
you.doSomething();
}
どうして？
always中括弧を1行に置くと、読みやすさが低下すると思います。画面に表示できるソースコードの量は限られています。ブラケットスタイル2）は、多くのネストされたループと条件文を含むヒーブアルゴリズムを非常に長くします。
ただし、
elseとifは視覚的には一緒に属しているため、elseを新しい行から開始する必要があります。elseの前にブラケットがある場合、何が何に属しているかを見つけるのははるかに困難です。3）失格する。括弧を省略してそれを忘れた場合、私たちは皆、何が悪いことが起こり得るかを知っています。
私はどこかの本の著者がこのようにフォーマットされた彼らのコードを望んでいたことをどこかで読みました：
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
しかし、出版社のスペースの制約により、これを使用する必要がありました。
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
今はそれが真実かどうかはわかりませんが（これ以上見付からないため）、後者のスタイルは本で非常に一般的です。
個人レベルでは、次のように別の行に角かっこを使用します。
a）新しいスコープを示す
b）不一致があった場合に見つけやすくなります（ただし、IDEではエラーが強調表示されるため、これは問題ではありません）。
ああ、 One True Brace Style 。
それは聖なる道に必要なすべてを持っています-預言者（リチャード「私の道または高速道路」ストールマン）ですら。
男は多くのことについて非常に間違っていましたが、GNU=は中かっこに関しては注目されています。
[更新]私は光を見てきました、そして今崇拝します Allman
簡単な答え：何がデバッグしやすいですか？
// Case 1:
void dummyFunction() {
for (i = 0; i != 10; ++i) {
if (i <= 10)
std::cout << "i is: " << i << "\n";
std::cout << 10 - i << " steps remaining\n";
// Some hard work here
// which is really hard
// and does take some screen estate
}
else
std::cout << "We'll never get there";
}
} // COMPILER ERROR HERE
// Case 2:
void dummyFunction()
{
for (i = 0; i != 10; ++i)
if (i <= 10)
{
std::cout << "i is: " << i << "\n";
std::cout << 10 - i << " steps remaining\n";
// Some hard work here
// which is really hard
// and does take some screen estate
}
else
std::cout << "We'll never get there\n";
}
} // COMPILER ERROR HERE
どの場合、最初に問題を診断しましたか？
私は個人的な好みをあまり気にしません（whitesmithやalを含む他の多くのスタイルがあります）そして、私はあまり気にしません...コードを読む能力を妨げない限りデバッグそれ。
「無駄なスペース」の議論については、私はそれを購入しません。プログラムをより明確にするために、論理グループの間に空白行を追加する傾向があります...
2番目の例では、私は読みやすさを非常に重視しています。他の方法でブロックされているかどうかを見ているのが我慢できない=（
誰も気づかないでしょうが、これがブレースが条件付き（と同じ行）に属している理由です（非常に長い条件文を除くが、これはEdgeの場合です）。 ：
Cでは、これは有効な構成です。
while（true）;
{
char c;
getchar（）; //入力を待つ
}
早く！このコードは何をしますか？ 「入力を求める無限ループ」と答えた場合、あなたは間違っています！入力も受け取れません。 while(true)で捕捉されます。最後のセミコロンに注意してください。このパターンは実際にはより一般的であり、本来あるべきように見えます。 Cでは、ブロックの先頭で変数を宣言する必要があるため、新しい変数が開始されました。
コードの行は考えです。ブレースは、条件またはループを含む思考の一部です。したがって、それらは同じ行に属します。
私は最初の方法が好きです。それはすっきりしたIMOのようであり、それは私が好きなよりコンパクトです。
編集：ああ、3番目。私はそれがさらに小さくてすっきりしているので、可能な限りそれが一番好きです。
あなたはそれを書くことができます：
you.hasAnswer() ? you.postAnswer() : you.doSomething();
質問に答えるために;私は自分の行で中括弧を好んで使用していましたが、ブラウザーでのセミコロンの自動挿入によるバグを考える必要がないように、JavaScriptにエジプトのスタイルを使用し始めました。 EclipseでJava=をコーディングするときは、デフォルトのブレーススタイルとの戦い（または構成）には関心がなかったので、その場合もエジプト語を使用しました。今は両方とも問題ありません。
ここでのほぼすべての応答は、「何をするにせよ、1つまたは2つに固執する」のバリエーションを示しています。
それで私はそれについてしばらく考えました、そして私はそれをそれほど重要ではないと見ていることを認めざるを得ませんでした。誰かが次のことは従うのが難しいと正直に言うことができますか？
int foo(int a, Bar b) {
int c = 0;
while(a != c)
{
if(b.value[a] == c) {
c = CONST_A;
}
c++;
}
return c;
}
他の誰かについてはよくわかりません...でも、精神的にスタイルを切り替えたりする問題はまったくありません。コードの動作を理解するのに少し時間がかかりましたが、これはCのような構文をランダムに入力した結果です。 :)
私の控えめな意見では、左中かっこはコードの可読性とはほぼ完全に無関係です。上記のコーナーケースにはいくつかのケースがあり、どちらかのスタイルで違いが生じますが、ほとんどの場合、空白行を慎重に使用することでそれが解消されます。
FWIW、私たちのコーディングスタイルは、やや構造化されたフォーム1と変更されたフォーム3を使用しています（C++）
// blank line is required here
if (x) {
//This blank line is required
y = z;
}
// blank line is required here too, unless this line is only another '}'
if (x) y = z; //allowed
if (x)
y = z; // forbidden
空白行がより強い視覚的分離を与えるという理由だけで、フォーム2を強く好む人がフォーム1のこのバージョンをよりよく見つけるかどうか私は興味があります。
これがまだ上げられていないことに驚いています。ブロックをより簡単に選択できるため、2番目の方法を使用します。
中かっこが同じ列と独自の行で開始および終了する場合、マージンから選択するか、カーソルを列0で選択できます。これは、通常、マウス選択でより広い領域、またはキーボード選択でより少ないキーストロークになります。
私はもともと条件と同じ行で中括弧を使用して作業していましたが、切り替えたときに作業の速度が加速されることがわかりました。もちろん、昼と夜ではありませんが、条件の隣で中括弧を使用すると、作業が少し遅くなります。
私の個人的な好みは最初の方法です。おそらくそれが私が最初にPHPを学んだ方法だからです。
単一行のifステートメントの場合は、
if (you.hasAnswer()) you.postAnswer();
you.postAnswer();ではなく、もっと長いもの、たとえばyou.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);の場合、おそらく最初のタイプに戻します。
if (you.hasAnswer) {
you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}
改行は使用しません。また、elseステートメントがある場合は、このメソッドを使用しません。
if (you.hasAnswer()) you.postAnswer();
else you.doSomething()
理論的な可能性ですが、私が使用することはありません。これはに変える必要があります
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
私は個人的に2番目の方法が好きです。
しかし、私が実証する方法は、最高の仕事の安全性をもたらすため、私の意見では最良です。私の大学の同僚の学生が宿題について助けを求めてきました。これが彼のコードの様子です。プログラム全体は1つのブロックのように見えました。興味深いのは、彼が作成したプログラムのバグの95％が不一致のブレースに起因するということです。中括弧が一致すると、残りの5％は明らかでした。
while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
if(i%1==0){
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
puts(input);
彼らはすべきではありません。私にとって最初の方法。
2番目の行を見ると、未使用の行（最後の右中かっこ以外に中かっこのみが含まれている）があるため、コードの連続性が損なわれているように感じます。コードの目的またはこのようなものの分離を意味する空の行に特別な注意を払う必要があるため、速く読むことができませんが、「この行は中括弧に属します」（意味を繰り返すだけです）インデント）。
とにかく、テキストを書くときのように...段落の先頭にインデントを追加することは、その前に空白行がある場合は不要です（段落の変更の二重符号）。中括弧の行を無駄にする必要はありません。適切にインデント。
さらに、すでに述べたように、画面により多くのコードを収めることができます。そうしないと、少し逆効果になります。
プラットフォーム/言語/規約に依存します
Javaの場合：
void someMethod() {
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
}
C＃で
void someMethod()
{
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
}
C：
void someMethod()
{
if (you_hasAnswer()) {
you.postAnswer();
} else {
you_doSomething();
}
}
Java人がC＃コードで自分のスタイルを使用するとき、またはその逆の場合は嫌です。
最初の方法を使用するのは、それがよりコンパクトで、画面上により多くのコードを許可するからです。私自身は中括弧のペアリングに問題がありませんでした（条件を追加する前に、常にifステートメントと一緒にそれらを書き出します。ほとんどの環境では、一致する中括弧にジャンプできます）。
did括弧を視覚的にペアにする必要がある場合は、2番目の方法を使用します。ただし、一度に少ないコードを使用できるため、さらにスクロールする必要があります。そして、それは、少なくとも私にとっては、括弧をきちんと揃えているよりもコードの読み取りに大きな影響を与えます。私はスクロールが嫌いです。次に、1つのifステートメントをスクロールする必要がある場合は、大きすぎる可能性が高く、リファクタリングが必要です。
だが;すべての中で最も重要なことは一貫性です。どちらか一方を使用してください-両方を使用しないでください！
私が言えることは、あなたが方法＃3のファンなら、地球上のすべてのIDE code-formatterによって迫害されることになるということです。
ブレースを整列させたままスペースを無駄にしない4番目のオプションがあります。
if (you.hasAnswer())
{ you.postAnswer();
i.readAnswer();
}
else
{ you.doSomething();
}
唯一の問題は、ほとんどのIDEのオートフォーマッタがこれで窒息することです。
最初に12歳でプログラミングを学んだとき、Microsoftのコーディングチュートリアルはそのようなものなので、次の行に中かっこを付けました。そのときも4スペースTABSでインデントしました。
数年後、JavaとJavaScriptを学び、同じ行に中かっこが追加されたコードを見たので変更しました。2スペースのスペースでインデントし始めました。