回答編集履歴
3
修正
answer
CHANGED
|
@@ -112,7 +112,7 @@
|
|
|
112
112
|
|
|
113
113
|
プログラムは組んだ通りにしか動きません。
|
|
114
114
|
導入されていない機能を忖度してうまいことやってくれるなんてことは絶対にありません。
|
|
115
|
-
「ここ！」というのを見極めて適切なコードを入れてください。
|
|
115
|
+
「ここ！」というのを見極めて適切な設計を行い、それにそった適切なコードを入れてください。
|
|
116
116
|
|
|
117
117
|
|
|
118
118
|
-----------
|
|
@@ -125,10 +125,8 @@
|
|
|
125
125
|
- <!DOCTYPE html>より前に空行はないほうがいい（ほぼ私見ですけど）
|
|
126
126
|
|
|
127
127
|
IDEに機能がないのでしたらWeb上のサービスを利用するのも有用です。
|
|
128
|
+
- [Another HTML-lint](http://www.htmllint.net/html-lint/htmllint.html)
|
|
128
129
|
|
|
129
|
-
- [ 0保存 共有する
|
|
130
|
-
Another HTML-lint](http://www.htmllint.net/html-lint/htmllint.html)
|
|
131
|
-
|
|
132
130
|
正しいhtmlを組まないと今後JavaScriptなど利用する際に正しく動かない要因になりますし、CSSも含めたレイアウトの際には問題の切り分けを困難にします。
|
|
133
131
|
|
|
134
132
|
|
2
修正 文章が変・・
answer
CHANGED
|
@@ -3,14 +3,14 @@
|
|
|
3
3
|
|
|
4
4
|
「課題だろうな」と回答者に印象付けた時点で有益なアドバイスを得らえる機会を失することにもなりかねません。
|
|
5
5
|
特に新人研修課題であれば上司なり先輩なりが本来の確認先です。
|
|
6
|
-
もし、「考え
|
|
6
|
+
もし、「考える力をつけさせるための課題」だとしたら、質問サイトでその課題を解決しようとする行為が良いかどうかは一考の必要があります。
|
|
7
7
|
|
|
8
|
-
「思考するエンジニアの為のQ&Aコミュニティ」「具体的にプログラミングで困っている質問」であって「宿題・課題代行サイト」ではないからです。
|
|
8
|
+
「思考するエンジニアの為のQ&Aコミュニティ」「具体的にプログラミングで困っている質問をする場所」であって「宿題・課題代行サイト」ではないからです。
|
|
9
9
|
- [推奨していない質問](https://teratail.com/help/avoid-asking)
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
もちろん、「宿題・課題について質問するな」というわけではありません。
|
|
13
|
-
サイトの大前提となる部分を理解したうえで、「課題代行依頼ではない」というところが
|
|
13
|
+
サイトの大前提となる部分を理解したうえで、「課題代行依頼ではない」というところが伝わるように気を付ける必要があります。
|
|
14
14
|
|
|
15
15
|
良い使い方は「９割できててあと１割がどうしても手が届かない」というときの１割を埋める使い方です。あくまで理想論なので参考まで。
|
|
16
16
|
（自身の質問の仕方を見直す指標になると思います）
|
1
修正
answer
CHANGED
|
@@ -20,6 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
おそらく本問題とは関係ないですが、actionに?は意味がないです。
|
|
22
22
|
「自身に送信」なのでしたらaction=""とするかaction属性自体なくても良いと思います。
|
|
23
|
+
|
|
23
24
|
ユーザー入力を画面出力時には[htmlエスケープ](https://www.php.net/manual/ja/function.htmlspecialchars.php)必須。
|
|
24
25
|
参考記事：[サニタイズ/入力値検証/エスケープの考え方](https://qiita.com/rana_kualu/items/11cd41de5f0364ba2ee8)
|
|
25
26
|
|
|
@@ -71,19 +72,19 @@
|
|
|
71
72
|
```
|
|
72
73
|
|
|
73
74
|
あと、特に機能改善のためであればリファクタリング兼ねてるようにも思いますので、
|
|
74
|
-
functionは外だししましょう。
|
|
75
|
+
functionは外だししましょう。別のphpに書いてincludeです。
|
|
76
|
+
※本来は[composer導入してnamespaceで管理すべき](https://qiita.com/tadsan/items/fb496e450fc27c8c4494#composer%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%82%8D)ですが、最初の段階として。
|
|
77
|
+
|
|
75
78
|
コード的な順序で後に書いてあるfunctionを使うような流れは私からするとちょっと違和感強いです。
|
|
76
79
|
「定義してあるものを使う」という流れにする必要がありますので、別ファイルにしないにしてもできればプログラムの冒頭に書きましょう。
|
|
77
80
|
|
|
78
|
-
別のphpに書いてincludeです。
|
|
79
|
-
※本来は[composer導入してnamespaceで管理すべき](https://qiita.com/tadsan/items/fb496e450fc27c8c4494#composer%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%82%8D)ですが、最初の段階として。
|
|
80
|
-
|
|
81
81
|
あと、[きちんとコメントを書くこと](https://qiita.com/tadsan/items/fb496e450fc27c8c4494#phpdoc%E3%81%AF%E5%BF%85%E3%81%9A%E6%9B%B8%E3%81%91)ですね。
|
|
82
82
|
|
|
83
83
|
|
|
84
84
|
もう１つ結構忘れられがちなのが「html”ソース”を確認すること」です。
|
|
85
85
|
「画面に出てるのでわかるだろ」って？思うかもしれませんが、そうではないです。
|
|
86
|
+
hiddenに設定している値が想定している値が入ってるかどうか、画面から分かりますか？
|
|
86
|
-
|
|
87
|
+
「デベロッパーツールから確認すればわかるだろ」って？思うかもしれませんが、そうではないです。
|
|
87
88
|
デベロッパーツールはブラウザ側が結構いい感じに補完してくれてます。
|
|
88
89
|
実際に出力されているコードとは異なり、ブラウザが勝手にstyle入れて微調整してくれていることもあります。
|
|
89
90
|
|
|
@@ -102,7 +103,8 @@
|
|
|
102
103
|
ではどこで演算子が不要となるでしょうか？
|
|
103
104
|
|
|
104
105
|
そこは「仕様」部分になります。
|
|
105
|
-
「こうなると不要となる」という条件はあくまで設計段階で決められるべきところです。
|
|
106
|
+
「こうなると不要となる」という条件はあくまで設計段階で決められるべきところです。
|
|
107
|
+
「どう書いたら演算子を消せるか」というコードベースで考えるのではなく「どこで演算子表示をなくすべきか」という設計ベースで考えましょう。
|
|
106
108
|
|
|
107
109
|
**演算子が不要となるタイミングはいつですか？**
|
|
108
110
|
|