Indentation is not a requirement of most programming languages, where it is used as secondary notation. Rather, programmers indent to better convey the structure of their programs to human readers. In particular, indentation is used to show the relationship between control flow constructs such as conditions or loops and code contained within...
// чего вдавлен внутрь кусок кода - в котором кода нет и выделять там нечего while ( TradingServerNotAvailable() ) { }
// каждый отступ вправо ассоциируется с новым уровнем вложенности, а здесь визуально ТРИ уровня! while ( TradingServerNotAvailable() ) // первый уровень { // второй уровень Sleep(1000); // третий уровень }
そして、もし、GNUにインスパイアされた文章で、ただのドロドロになったとしても、です。
if ( TradingServerNotAvailable() ) { .... }else{ // вот тут в одной строке ТРИ элемента разных блоков: закрытие предыдущего, разделитель, начало следующего :((( .... }
Indentation is not a requirement of most programming languages, where it is used as secondary notation. Rather, programmers indent to better convey the structure of their programs to human readers. In particular, indentation is used to show the relationship between control flow constructs such as conditions or loops and code contained within...
皆さん、コードは誰のために書かれているのでしょうか?
他のプログラマー向けなのは間違いない。他の人の書式なしコードを読むのは、彼らにとっては非常に不愉快なことなのです。
まさにこの問題を解決するために、ビルトインのスタイラス機能を作りました。もし、他の人(あなたではなく、他の人)にあなたのコードに目を通したいと思うなら、できるだけシンプルで曖昧さのないものにした方がいいでしょう。そして、ここでのキーワードは「あなた」ではなく「人」です。
レナートスタイラーは 誰に向けて書かれたのですか?
他のユーザー向けに書かれたものであることは間違いないのですが。しかし、他の人のスタイルでフォーマットされたコードを読むのは、彼らにとっては非常に不愉快なことなのです。
この問題を解決するために、通常のスタイラーの機能を拡張することを提案します。もし、他の人(あなたではなく、他の人)にスタイリストを使いたいと思ってもらいたいなら、できるだけ便利でカスタマイズ可能なものにしたほうがいいでしょう。そして、ここでのキーワードは「あなた」ではなく「人」です。
プログラマーは自分のためにコードを書いていると勘違いしているが、自分のために書いているのではない。わかってるんでしょう?
ps: CodeBaseの言い訳は無茶苦茶です。エディタに埋め込まれたスタイラスがどう関係するのでしょうか?
ps: CodeBaseについての言い訳は無茶苦茶ですね、組み込み用スタイラスは何の関係があるのでしょうか...?
自分でCode Baseを構築し、メンテナンスし、お金を払うとなると、その疑問は一気に解消されるでしょう。それとも、周りはすべてタダでやっているとでも思っているのでしょうか。
今は、「カスタマイズできないだけで悪い」という原則的なスタンスの話ばかりです。
具体的なポイントに移りましょう。どのポイントで、なぜスタイリストが 正しくできていないのか、指摘してください。
今は「チューニングできないから悪いだけだ」という原則的なスタンスの話ばかりです。
私はそうは思いません。
例えば私は、「今あるものは、一般的に認められているコーディング基準に合致していないからダメだ」という立場です。結果を満足させるための手段は問わない」。
この問題に限らず、あなたには原則的な立場があります。
そして、他人の主張が極めて合理的かつ理性的であるにもかかわらず、断固として耳を貸そうとしないのです。
具体的なポイントに移りましょう。どのポイントで、なぜスタイリストが間違ったことをするのか、指摘してください。
私はそうは思いません。
例えば、私の場合は、「一般に認められたコーディングの基準に達していないため、満足できないものは使用しない。結果を満足させるための手段は問わない」。
この問題に限らず、あなたは原則的な立場を持っています。
そして、他人の主張が極めて合理的かつ理性的であるにもかかわらず、断固として耳を貸そうとしないのです。
Stylerはすべてを正しく実行します。しかし、その結果は、あなたが望むもの(許容範囲)ではない。+1.すべてにおいて。
スタンダードなスタイルに戻すのは、たった一度の決断でいいのです。過去に一度、曲がったスタイルを採用したことの過ちを認めたくないだけなのだ。
+1.すべてにおいて。
スタンダードなスタイルに戻すのは、たった一度の決断でいいのです。ただ、過去に曲がったスタイルを採用したことの間違いを認めたくないだけなのだ。
湾曲」に納得がいかない。
彼らにとっては「よりおいしく」「より明るい」味なのだから...。議論しないでください。
そして、カスタマイズについて、彼らはこう言っています。
;)
湾曲」に納得がいかない。
彼らにとっては「よりおいしく」「より明るい」味なのだから...。議論しないでください。
そして、セッティングについては、「後で話を聞いてください。
;)
納得いかないってどういうこと?反対できないデファクトスタンダードがあるのだから、それに従えばいいだけだ。サブバージョンで独自のHTMLでレポートを作成することは思いつかず、標準のものできっちりと作成した。それは、スタイルも同じです。プログラミングは世界的な産業であり、スタイルも決まっている。メタクォーツはそのような「革新」で大衆に逆らうことはできないのだ。
どの項目で、なぜスタイリストが 正しくできていないのか、具体的に教えてください。
できれば、フォーマットされたコード片のデモがあることが望ましい。
どの項目で、なぜスタイリストが正しくできていないのか、具体的に教えてください。
できれば、フォーマットされたコード片のデモがあること。
https://www.mql5.com/ru/forum/122145、 そこだけタブが小さい--2文字だが、通常の3〜4文字であるため、それほど重要ではない。
デモは最初の投稿にあります。コンマがないので、この文のようにする必要があります。
本気なら、当社のコーポレートスタイル契約書から抜粋して引用しますよ。
どの項目で、なぜそれがスタイリストによって間違って行われるのかを明記してください。
フォーマット化されたコードフラグメントのデモがあると望ましい。
レナート、これはもうスポーツマンシップに反するよ;)
MQLはあなたの言語であり、そのための標準は存在しないので、あなたにはあなたの標準を設定する権利があります。そして、私たちはあなたに何も証明しません。
しかし、MQLはC言語ライクな言語です。そして、Cには一般に認められたいくつかの規格があります。こちらです。https://en.wikipedia.org/wiki/Indent_style。
個人的にはAllmanスタイル(Emacsのbsd)が好きです。
このスタイルでは、制御文に関連する波括弧は次の行に置かれ、制御文と同じ高さにインデントされます。 波括弧内の文は次の高さにインデントされます。
自分の主張を守るための問題は、絶対に遠回しに言っているような気がします。このように整形されたテキストを見たい方は、ご自由にどうぞ。しかし、別のフォーマットにしてほしいという人もいます。これらの人々(本体にアクセスできない)は、彼らのニーズを考慮し、あなたの方法と彼らの方法の両方でフォーマットできるようにフォーマットを調整することを求めているのです。これができるのは、開発者であるあなただけです。今回の依頼は、このような思いで回しています。私たちの期待に半分応えるのか、それとも私たち全員をあなたの基準に戻すのか。選択肢を選んで発表してください。
この質問が重要だと思う理由と、Allmanスタイル(Emacsのbsd)が正しいと思う理由を、2、3段落だけ付け加えます。誰が何に使うかはしばらく忘れて、裸の論理に訴えよう。
なぜテキストをフォーマットする必要があるのですか?その中で、個々の論理 ブロックを分離・分割するために、まさにこのフォーマットを使って います。
では、普通の "間 "を見てみましょう。ループの「ヘッダー」と「ループ本体」という、論理的に分離された2つのブロックがあります。混同しないように、別々の線に配置する必要があるのです。そのため、whileと同じ行で括弧を開くと(個人的には)モヤモヤします(男が半身で部屋に入るようなもので、全身は部屋の中にあるのに、頭はまだドアの向こうに「残って」いるようなものです)。
さて、2つ目の問題は、ブラケットを押し込むかどうかです。原則として、括弧はヘッダを直接参照せず、むしろループの本体の一部となる。ただし、内部には実行可能なコマンドのみ、つまりそれ自体が独立したロジックを持つもののみを押し込む必要があります。しかし、少なくとも1つだけ、ボディを持たないループの賢明な例がある。
トレードサーバーが利用できない間は、単に何もすることがない - だから何もせず、ボディサイクルは空っぽなのです。この場合、内側に押された括弧は、(私の目から見ると)少し奇妙に見えます:右シフトし、空白が強調されています。
ループにボディがある場合、ボディは右側に移動し、左側のスペースは閉じ括弧のペアを見つけるために使用できるようになります。
ループのヘッダーと同じ行に開始括弧を置くべきでないもう一つの理由は、閉じる括弧を探すときに見つけにくいからです。私のバージョンでは、この位置に括弧があり、別の行にそのカウンターパートがあるが、同じ位置にあることがはっきりわかる。さらに、1つの括弧の付いた行は(コメントなしでも!)、視覚的な要素として、内部ブロックと外部ブロックを強調し、分離する役割を果たします。
ご覧の通り、個人的な感想はありません。ただ、テキストを視覚的に認識するための論理です
そして、その論理の観点から(個人の好みや習慣ではなく)、現在のスタイラスフォーマットのテキストは、私にとって理解不能なのです。
そして、もし、GNUにインスパイアされた文章で、ただのドロドロになったとしても、です。
と、開き括弧をなくしたり、閉じ括弧を余計に入れたりしていないかどうか、どうやって見分けるのでしょうか?こんな感じです。
もう一度言いますが、これは私の個人的な癖でも何でもなく、文章を視覚的に認識するための論理なのです