100g未満で航空法の対象外のドローンを飛ばしていたら通報されて警察がきた→ガバガバ計測で警察署に行くことになった話 - Togetter [トゥギャッター] https://togetter.com/li/2561719
100g以上用の秤で、100g以下か量る警察・・・＞＜
orange
さんがブースト
いちおう訊いた限りはできなくはなさそうなんだけど，想定しているチュートリアルを作ろうとすると，たぶん変更指示を表すDSL的なフォーマットをもったコメントをソースコードのあちこちに埋め込む必要が出てきて，かつ一つの変更箇所にあとからさらに変更が生じるケースで破綻するかなぁ，という予感がします．
いずれにしても，その変更指示付きのソースコードはかなりメンテナンスしにくいものになりそうかなと．
通常は、コード上のわかりきった事をコメントに書くのは誤りだけど、
逆に言うとわかってない事とか理解が難しかったり、あとでなんでそうなってるのか忘れちゃいそうな事はコメントに書いていい・・・って考えからすれば、よくわかってない学習中の人は、そういう部分にコメントを書く方がよさそう＞＜
orange
さんがブースト
各ステップのリード文中でそれを書くってことでしょうか．
...それはちょっとうちの学生には無理がある．
その場合は、引数のみ書き換えるのであれば、その通りに指示すればいいのでは・・・＞＜
たとえばあんまりよくないスタイルのコメントだけど
//hogeをする関数
ってコメントをつけておけば、hogeをする関数の引数をfugaからpiyoに変えてみましょうみたいな指示はできそう＞＜
orange
さんがブースト
単純な例として，
```
int main() {
// 1:
// some_func(ENUM1);
return 0;
}
```
で1ステップ目でこのコメントを解除するとして，この some_func() の取りうる値が ENUM2, ENUM3, ENUM4 とあって，それぞれの引数のの結果を確かめていきましょう，みたいなことを表現しようとしたらその方法どうなる想定でしょうか．
うーん＞＜；
orange
さんがブースト
それは一貫したコードを書くときはそうだと思うんですが，チュートリアルの目的は多くの場合は「こう変更するとこういう結果が得られる」なんですよ．最終状態だけを目指して書くわけじゃないんです．
ただ単に上から順番に追記をしていくわけじゃないから複雑になるんです．
変更が想定されていない場所で変更が起きるのは設計ミスと言うか想定ミスかも＞＜
なにかが変更されるかもしれないのであれば、イカの耳を作っておくべきかも＞＜
イカの耳参考＞＜
高速道路の「イカの耳」はなぜ存在するのか？ | 自動車情報・ニュース WEB CARTOP https://www.webcartop.jp/2022/09/952809/
基本的にはなにかを設計する時にはあらかじめ計画し、変更できる箇所は変更できるように書いておけば必然的に変更箇所は定まるので、変更したら変更によって生じた新たな変更可能箇所にもちゃんとコメントを書いておけば、バグ修正以外では、コメントが書かれてる変更が想定されてる箇所以外では変更が生じないのが正しい設計かも＞＜(ちょっとトートロジーだけど)
orange
さんがブースト
うーん...
それだと変更箇所が行を行ったり来たりするとひどいことにならない？コメントに適用順序を書いておくにしても...
たとえば
//追加リストを記述できる位置
とか＞＜
10行目に相当するところにあらかじめ計画した内容をコメントとして書いておく感じ＞＜
orange
さんがブースト
いやわからん．たとえば「10行目にリストxxを追記せよ」みたいのはそれだとどう表現するの？
Mistral Small 3に聞いたら「スケルトンじゃなくアウトラインじゃね？」って言われた＞＜
スケルトンって言うのかも？＞＜
たとえばでHelloWorld的なので言うと
//初期化します
//表示する文字列を用意します
//表示します
//終了処理をします
とか、文書でなら、
//概要
//導入
//・・・？＞＜；
みたいなの＞＜；
あらかじめ必要になるものを列挙しておいて、コメントに最初に書くってすればいいんでは感＞＜
(コメント書くかは別とすると)作業設計の手順としてはその方が正しいわけだし＞＜
orange
さんがブースト
ただこの方法だと，diff─つまり行ベースの一致で変更を指示するカタチになるので，構造に基づいた変更指示(たとえばHTMLのような)が出しにくくなるというのも懸念している．
- ＠orange_in_space
2017年 4月に登録
