前の書き込みで、Cametanさんからリスト（一般には配列）にも10行のように代入できると
教えてもらいました。自分は、何か勘違いをしていたようです。
10行目の書き方は、スマートですが、14行から16行でも良いでしょう、でやってみました。
短く書けるものは短く書くのが、Cametanさん流のようです。
何しろ自分はデバッグを楽しむ派ですので
一旦は長く書く、出来上がったら、短く置き換える派なんです。（笑）
知っている範囲でですが。（笑、笑）
最新の画像［もっと見る］
-
3/9昨日は良い天気でした。200mmと200mm x 1.4ちょっと比較してみました！
2日前
-
3/9昨日は良い天気でした。200mmと200mm x 1.4ちょっと比較してみました！
2日前
-
3/9昨日は良い天気でした。200mmと200mm x 1.4ちょっと比較してみました！
2日前
-
3/9昨日は良い天気でした。200mmと200mm x 1.4ちょっと比較してみました！
2日前
-
DaVinci Resolve 19、面白い。タイムライン上のクリップの削除。ブレード編集モード。
5日前
-
DaVinci Resolve 19、面白い。タイムライン上のクリップの削除。ブレード編集モード。
5日前
-
DaVinci Resolve 19、面白い。タイムライン上のクリップの削除。ブレード編集モード。
5日前
-
DaVinci Resolve 19、面白い！カウントアップしてみました。
6日前
-
DaVinci Resolve 19、面白い！カウントアップしてみました。
6日前
-
DaVinci Resolve 19、面白い！カウントアップしてみました。
6日前
「Python」カテゴリの最新記事
自分がモタモタしているうちに、cametanさんが完璧に説明してくれました！
cametanさんが説明していることとは、少し違うかもしれません？REPLとは何じゃあ！
コップ本の例題にRationalクラス（分数クラス）あったので、やってみました。5回目...
コップ本の例題から、Rationalクラス（分数クラス）その4回目。
コップ本の例題から、Rationalクラス、その3回目かな？
コップ本の例題から、分数クラス（Rational)をやってみる。その2。by python3
コップ本の例題から、分数クラスを試してみる。by python3
暫く放おって置きました。python reduce lambdaと少し前の写真。
混乱してました！pythonでの+、リスト内の+とリスト同士の+
チョット理解できないreduce,lambda,でも手掛かりは有ったかも？
アクセス
トータル
ランキング
と言うより、関数型プログラミングを意識すると皆そうなっちゃう(笑)。
大体、あんま代入せんですからね。代入がまた行数が増える原因だ(笑)。
また好んで破壊的変更もしない。
ary2 = []
ary2.append(lambda x, y: x + y)
ary2.append(lambda x, y: x * y)
これは破壊的にary2を変更してる。これも「ワザと」避けてます。
だから関数プログラミング書法的には
> 10行目の書き方は、スマートですが、14行から16行でも良いでしょう、でやってみました。
「良いでしょう」にはならない(笑)。こういうのは相当意図して慎重にやらないとバグの原因になる。
(関数内でメモリ効率を考えて・・・の時は有効ですが、これは「しないようにする」のが練習としては第一、です)
また、例えば
for i in ary2:
print(reduce(i, lst))
とするよか、本当は、
>>> [print(reduce(i, lst)) for i in [lambda x, y: x + y, lambda x, y: x * y]]
55
3628800
[None, None]
の方がいいかもしんないし、それこそprintも副作用なんで、一旦
>>> res = [reduce(i, lst) for i in [lambda x, y: x + y, lambda x, y: x * y]]
でもしておいて、「後で」「別に」printした方がいいかもしんない・・・そうしないのはVSCodeのせいかな?多分。
> 何しろ自分はデバッグを楽しむ派ですので
>
> 一旦は長く書く、出来上がったら、短く置き換える派なんです。（笑）
リファクタリング主義はそれはそれでいいんじゃないですか?
だから多分ブログで前に書いたけど、「ユニットテスト」の方法論の方が合ってるかも。
テスト駆動開発:
https://blog.goo.ne.jp/cametan_42/e/68a41bb61aabd288d4298755948f9b69
とにかくテストファーストで行く、と。
Pythonだとそれこそ「Dive into Python」で書かれてますね。
ユニットテスト:
https://diveintopython3tojp.blogspot.com/2016/07/09-01.html
ガンガンテストをまず書いて、そこを通ってからリファクタリングに入る、って方が向いてるのかも。
Visual Basicにもそういうツールがないんですかね?
分かりそうなところ、興味を持ったところへ移りたいと思います。その前に一度、ユニットテストを見てみたいと思います。
いや、テスト駆動開発自体は簡単ですよ。
最初にテストを書く(笑)。それだけ。
つまり、結果が分かってるなら、
関数(引数) == 結果
を最初に書いておいてから関数を書き始める、って事です。
ただ、ユニットテストのモジュールなり道具なり、ってのはそれを簡単にやるためのツール、ってだけですね。
assert構文とかが有名かな?
いずれにせよ、「ユニットテストモジュールの使い方」で悩む事はあるかもしんないけど、テスト駆動開発自体のアイディアは大した事がありません。
自分の場合は、とにかく答えを出して、合っているのか居ないのか？調べてました。正確さを要求されることもないので。
はい。関係ないです。
あくまで「開発プロセス」っつーか「開発法」の一つです。
おそらく、Javaで有名になったやり方なんじゃないかな。
> 自分の場合は、とにかく答えを出して、合っているのか居ないのか？調べてました。正確さを要求されることもないので。
う〜ん、正確さを要求されるかどうか、がこれまでの趣旨ではないんですよね。
isamさんが「デバッグ好き」で「リファクタリングの方が相性がいい」って言ってたんで、こっちの「開発手法」の方が相性がいいだろう、と。
「テスト駆動開発」のキモは「間違ってても汚くてもいいから取り敢えずテストをパスするコードを書く」んですよ。「上手く動いてから」コードをキレイにしていく、と。
だからisamさん向きだ、と。
仮に、
> 一旦は長く書く、出来上がったら、短く置き換える派なんです。（笑）
で、
> とにかく答えを出して、合っているのか居ないのか？調べてました。
答えが合ってて終わり、特に実は短く書き換えてません、と言うのならテスト駆動開発には向かないでしょう。
もしそうなら、最初から短く書く練習にトライした方がいいですね。わざわざコードを長く書くメリットは最初からないですから。
テスト駆動開発をもう一度読んでみます。短く書くのが、得意でないので。