SSブログ

気がつくと複雑になってしまうコード [プログラミング]

いま、僕は複雑なコードに苦しめられている。主なところは

- 安直に例外投げすぎ問題
- リストの内包表記使いすぎ問題
- define 使いすぎ問題

例外は要するに大域ジャンプなので後で例外が起きた(起こした)ところの値を受け取りたくて苦労している。
python は例外を投げてもメモリリークしないけど、いっそのこと golang ならこんな苦労をしなくても済んだのかもと思う。

リストの内包表記使いすぎ問題は
def func_ab(values_list):
    def _set_ab(v):
        v.a = 'A'
        v.b = global_func_b(v.b)
    [_set_ab(v) for v in values_list]

↑こんなのがあって
def func_ab(values_list):
    for v in values_list:
        v.a = 'A'
        v.b = global_func_b(v.b)

↑これでよくない?と

define 使いすぎ問題は、C言語でいうところの
#define ONE 1
みたいなやつ。
一回しか使わないエラーメッセージみたいなのを一箇所に集めて
error_log(SOMETHING_WRONG_SITUATION)
みたいにしてるのも仲間かと。
エラーログの文字列から処理を探すのが大変。
そりゃ世の中にはメッセージカタログ使っているものもあるけど、時と場合によるだろうと思う。
そして define使いすぎの場面のほうが、使うべきなのに使ってない場合より多いのでは。

そういえば、随分昔の話 Visutal C++ で、ものすごく Fat な文字列クラスがあって、あれもひどかった。
ちょっと便利系のいろいろ機能(メソッド)が足されているけど、ちゃんとドキュメント化されてなくて、ところどころ不具合もあった。
文字列の後ろから特定の文字が何文字目かにあるか探すメソッドは、2 byte 文字の 2 byte 目問題に
当たっていたので、明らかに不具合があって、指摘したのだが書いた人は
「実績があるから」
といって聞き入れてくれなかった。

こういう複雑コードを書く人は経験を積んだら普通に書けるようになるんだろうか?
直らないものなのだろうか?
それとも経験を積んだ結果なんだろうか?
define 使いすぎ問題は、自分にも覚えがある
Fat な文字列クラスの人は、ベテランだったけど、あれが経験を積んだ結果なのか昔からずっとそうなのかは知らない
コメント(0)  トラックバック(0) 
共通テーマ:日記・雑感

コメント 0

コメントの受付は締め切りました

Facebook コメント

トラックバック 0