プログラマ専用SNS ミクプラ

当たり前と言えば当たり前なんですが

for( j=-3;j<4;j++ )float Angle=atan2( Player.y-EnemyShot.y , Player.x-EnemyShot.x ),EnemyShot.Angle=atan2( sin(EnemyShot.Angle)+sin(Angle)/10 , cos(EnemyShot.Angle)+cos(Angle)/10  );

のような処理を書くと

定数式が必要
宣言の構文エラー

と言うようなエラーが出ます
何行かに分ければ大丈夫なんですが
一行にまとめた方が見栄えが良いので
なんとか一行にまとめられないでしょうか？

環境はＤＸライブラリです

for( j=-3;j<4;j++ ){float Angle=atan2( Player.y-EnemyShot.y,Player.x-EnemyShot.x);EnemyShot.Angle=atan2(sin(EnemyShot.Angle)+sin(Angle)/10,cos(EnemyShot.Angle)+cos(Angle)/10);}

こんな感じでできませんか？

一行に納めたいなら改行しなければ良いです。

おそらくですけど、分けたほうが管理はしやすいですよ＾＾；

ループの制御変数「 j 」に無関係な計算を、
ループの中で毎回繰り返す必要があるのでしょうか？

それと複数行に書いたほうが見栄えは良いと思う。
1行200文字というのは恥ずかしくて人に見せられないレベルというか。

>>こんな感じでできませんか？

できました、どうもありがとうございます。

>>おそらくですけど、分けたほうが管理はしやすいですよ＾＾；

確かに一行の内容は見にくくなるんですけど
こう言う式がズラーっと並んでいるので
一行にまとめた方が全体が見やすくなる気がしたんです
一回書いたら多分いじらないと思うし・・

>>ループの制御変数「 j 」に無関係な計算を、

すいませんアレは例えばの話です・・

>> 1行200文字というのは恥ずかしくて人に見せられないレベルというか。

200文字はさすがに無いですけど、描画系関数で疑問演算子を乱用して
凄まじい長さになっている場所がいくつかあるので
一行が長くなるのにあまり抵抗がないんです・・

> >>ループの制御変数「 j 」に無関係な計算を、
>
> すいませんアレは例えばの話です・・

例えばの話ではなく、現実に書いたコードと
現実に起きたエラーとを突き合わせる必要があります。

あなたのところで「正確に」何が起きているかを説明できるのは、
あなたご自身「だけ」です。

え～とfor文　変数宣言　関数を一行にまとめた式をこれから色々作ろうと思ったので
まとめる方法が知りたかったんです

何が起きているかと言うと、まだ何も起きていません・・
これから何か起きないように前提知識を得たかったんです・・

すいません

> 200文字はさすがに無いですけど、描画系関数で疑問演算子を乱用して
> 凄まじい長さになっている場所がいくつかあるので
> 一行が長くなるのにあまり抵抗がないんです・・

先のソースコードは197文字あり、forの前に1つでもインデントがあれば
200文字を超えています。これも例えばの話だったのでしょうか。
疑問演算子は三項演算子のことかな？乱用も良くないですよね。

長すぎる関数、長すぎる行というのは、一般に管理が困難です。
「一行にまとめた方が見栄えが良い」というのに引っかかり、
つい書きましたが、これ以上は不毛でしょうね。
プログラムの全体を見ないと何とも言えないし、
個人で好きで書いているのならば文句もないですので。

あ～意外に200文字ぐらいあるんですね・・
コピー＆ペーストばっかりだから感覚がマヒしていました・・

気になったのでプログラム全体で一番長い行の文字数を数えてみると623文字ありました・・
長いので10文字ぐらいは誤差があると思いますが、それ以外にも
カウントには入れていませんが前にタブが4回あり後に注釈が8文字あります・・

まあDrawFormatString関数の引数で長くなってるだけですから管理は楽ですけど・・

長い行は平均して200文字ぐらいですが
分けたら縦に長くなるので
縦と横なら横かな～と思ったんですが・・

疑問演算子はカウンタでフェードイン、通常描画、フェードアウト
という処理を一行にまとめる時などに使っています

623文字はすごいですね。
一般的と思われる目安を書くと、縦横共にスクロールしなくても
関数全体が見れるのが理想です。
このため、一昔前は一行の文字数は80文字までとかいう目安もありました。
（Delphiの古いバージョンには、80文字目に線が引いてあったり）

画面の解像度が上がるとスクロールせずに表示できる行数・桁数は当然増えますが、
その分ソースコード以外の情報を表示するほうが開発しやすいかなーと
個人的には思っています。マルチモニタとか使わせてもらえないので。

一般的なプログラムは書いたらお終いではなく、デバッグしたり、
数年後に変更したりしますので、常識的な行数・桁数で書くのが無難です。
横を短くしたら縦が長すぎるというのは、そもそも1つの関数に詰め込みすぎでしょう。
関数の機能を少なくすることで、関数の再利用もしやすくなりコピペも減るでしょう。
安易なコピペもやってはいけないことなのですが、知ってますか？

チルチルさんは趣味で書いているのだと思いますので、
好きなように書いて良いわけですが、先人の知恵を学ぶのも無駄にならないと思います。
あえて学ばないんだー、というのもご自由ですが。

最後に、正しい用語を使いましょう。
疑問演算子じゃないってば。

C++でテンプレートを使いだすと、どうしても横長になりますけどね。
例えば、

template <class C, class Traits = std::char_traits<C>, class Allocator = std::allocator<C>, class F>
inline std::basic_ostream<C, Traits>& function_name(std::basic_ostream<C, Traits>& stream, std::basic_string<C, Traits, Allocator> const& str, F filter)
{
  ...
}

のような感じで...

> 最後に、正しい用語を使いましょう。
> 疑問演算子じゃないってば。

? : のことであれば、正しくは「条件演算子」ですね。

私への突っ込みですよね、きっと。
Cで唯一の三項演算子が条件演算子ですよね。
そのためか三項演算子と言う（書く）癖がついてしまってます。
チルチルさんに偉そうに言えないな。気をつけます。

そうですね、条件演算子ですね・・
って言うか疑問演算子ってどこにも書いて無かったと思うのに
何でそう呼んでるんだろう・・

う～ん最近、何でもかんでも一つの関数にまとめる癖がついてしまって・・
他の関数ならともかくDrawFormatString関数なので分けると間が統一しにくくて・・

長くなる関数は何かを登録する関数ですね・・
構造体だから引数が多くなるし
引数が条件演算子を多用した式になる場合が多いし・・

やっぱり関数は再利用しやすい方が良いんでしょうかね・・
私の場合は関数の独立性が皆無になってますからね・・