回答編集履歴
6
推敲
test
CHANGED
@@ -18,7 +18,7 @@
|
|
18
18
|
|
19
19
|
|
20
20
|
|
21
|
-
if文が視野の範囲内で
|
21
|
+
if文が視野の範囲内で完結していないと、理解もし辛いです。
|
22
22
|
|
23
23
|
ページスクロールしないと全体が見れないようなコードかどうかを処理分割の目安にしています。
|
24
24
|
|
5
追記
test
CHANGED
@@ -23,3 +23,9 @@
|
|
23
23
|
ページスクロールしないと全体が見れないようなコードかどうかを処理分割の目安にしています。
|
24
24
|
|
25
25
|
制御がなく単純編集みたいなものは考えることは必要ないので、気にしませんが。
|
26
|
+
|
27
|
+
|
28
|
+
|
29
|
+
_を使用するのはスクロールしないと駄目なくらい横に長くなった時だけですね。
|
30
|
+
|
31
|
+
全体が見えることを優先し、行数が増えるのは極力避けます。
|
4
推敲
test
CHANGED
@@ -18,7 +18,7 @@
|
|
18
18
|
|
19
19
|
|
20
20
|
|
21
|
-
if文が視
|
21
|
+
if文が視野の範囲内で条件が完結していないと、理解もし辛いです。
|
22
22
|
|
23
23
|
ページスクロールしないと全体が見れないようなコードかどうかを処理分割の目安にしています。
|
24
24
|
|
3
追記
test
CHANGED
@@ -15,3 +15,11 @@
|
|
15
15
|
また、単独の項目で判定可能なら、select case を利用するとスッキリします。
|
16
16
|
|
17
17
|
それでも条件が複雑なら、関数化して集約したステータスを返却するようにして、その返却値で分岐するなどすれば、制御自体が見やすくなります。
|
18
|
+
|
19
|
+
|
20
|
+
|
21
|
+
if文が視覚の範囲内で条件が完結していないと、理解もし辛いです。
|
22
|
+
|
23
|
+
ページスクロールしないと全体が見れないようなコードかどうかを処理分割の目安にしています。
|
24
|
+
|
25
|
+
制御がなく単純編集みたいなものは考えることは必要ないので、気にしませんが。
|
2
追記
test
CHANGED
@@ -3,3 +3,15 @@
|
|
3
3
|
画面層とデータ層などの境界線により構造を分け、共通化を図っていけば再利用し易くなります。
|
4
4
|
|
5
5
|
※例えば、データ層ではコントロールを直接参照するのではなく、パラメータで受け取るなどによって画面層との分離ができます。
|
6
|
+
|
7
|
+
|
8
|
+
|
9
|
+
追記
|
10
|
+
|
11
|
+
--
|
12
|
+
|
13
|
+
ifの場合はelseifが可能な場合を単独のif文よりend ifが少なく少しコンパクトになります。
|
14
|
+
|
15
|
+
また、単独の項目で判定可能なら、select case を利用するとスッキリします。
|
16
|
+
|
17
|
+
それでも条件が複雑なら、関数化して集約したステータスを返却するようにして、その返却値で分岐するなどすれば、制御自体が見やすくなります。
|
1
推敲
test
CHANGED
@@ -1,5 +1,5 @@
|
|
1
1
|
再利用がしにくいというのはif文の書き方によるものではなく、プログラムの構造設計がなされてないからです。
|
2
2
|
|
3
|
-
画面層とデータ層に構造を分け、共通化を図っていけば再利用し易くなります。
|
3
|
+
画面層とデータ層などの境界線により構造を分け、共通化を図っていけば再利用し易くなります。
|
4
4
|
|
5
|
-
※データ層ではコントロールを直接参照するのではなく、パラメータで受け取るなどによって画面層との分離ができます。
|
5
|
+
※例えば、データ層ではコントロールを直接参照するのではなく、パラメータで受け取るなどによって画面層との分離ができます。
|