Conversation
| } | ||
|
|
||
| ``` | ||
| - 短く，単純になった． |
| } | ||
|
|
||
| resultHead := &ListNode{Val: node.Val, Next: nil} | ||
| resultTail := resultHead |
There was a problem hiding this comment.
resultHead/Tailという変数名より、より入ってくる中身に注目した名前にするとよいように感じました。
自分なら、unique_nodes/_tailなどのように付けると思います。
There was a problem hiding this comment.
コメントありがとうございます
たしかにresultのような実質何も言ってない命名より良さそうに思いました 改善します
| resultTail := resultHead | ||
|
|
||
| for node != nil { | ||
| if node.Next != nil && node.Val != node.Next.Val { |
There was a problem hiding this comment.
常に隣同士を比べていると思います。
自分なら、5回目の考え方に少し似せて書くこともできるなと思いました。
Goには詳しくないので、間違っていたらすみません。雰囲気で書きます。unique_nodes(= resultHead)・unique_nodes_tail(= resultTail)を使いますね。
unique_nodes = head
unique_nodes_tail = head
unique_node = nil
for node != nil {
if unique_nodes_tail.Val != node.Val {
unique_nodes_tail.Next = node
unique_nodes_tail = unique_nodes_tail.Next;
}
node = node.next;
}
unique_nodes_tail.Next = nil
return unique_nodesThere was a problem hiding this comment.
コード例ありがとうございます
これも副作用がないパターンの 短く書ける例として良さそうでした
最後のnil代入で、headの末尾に近いところが破壊されることに自覚的であればこれも良さそうですね
ありがとうございます！
| } | ||
| ``` | ||
| - あまり綺麗にならなかった | ||
| - のでLLMにアドバイスもらって，「削除なんだからin-placeでやるのが自然だろ」と言われた．いや〜そうだね．ということで次． |
There was a problem hiding this comment.
メンタルモデルとコードの流れがそれなりに一致しているので、私は4回目の実装でも良いと思います。
5回目の実装は node.Nextをつなぎ替えることで入力リスト自体を更新する形になっています。入力を破壊する実装になるため、そのことを少し意識しておくことが必要かなと思いました。
There was a problem hiding this comment.
ありがとうございます
今回書き上げたタイミングでは破壊的な副作用への意識は薄かったので、そこを自覚的に選択できるようにしたほうが良かったですね
| resultTail := resultHead | ||
|
|
||
| prev := node | ||
| node = node.Next |
There was a problem hiding this comment.
2回目のprev==nilの中の処理が、このタイミングでfor文の外に出たところを見ると、プログラムを書く前にもう少し作業内容をイメージしてみてもいいのかなと思います。
以下を参考にしてみて下さい。
t0hsumi/leetcode#4 (comment)
There was a problem hiding this comment.
ありがとうございます
リンク先読みました。まだしっくりきてないのであとでもう一度読んでみます
4 participants
https://leetcode.com/problems/remove-duplicates-from-sorted-list/description/