コーディングのルールについて

[Ryohei Ueda]

garaemonです

コーディングに, ある程度のコンセンサスが無いと開発を始めるのが難しいと思うので,
いくつか提案したいと思います.

また, ここで決まった方針は, 厳守しろ!, というつもりはありませんが,
この方針にそっていないコードは, 適時修正するよ, というようなニュアンスです.

・目的は, pythonの標準ライブラリで提供するAPIと同じものをCLで提供すること.
これは, さすがに無理だろ...というものは議論しましょう

・クラス名は<>でくくる
例: <hoge>

・pythonの関数名等は適時, lispっぽくする
例: HogeFuga -> hoge-fuga

・グローバル変数は**でくくる
例: *hoge*

・定数は++でくくる
例: +hoge+

・横幅は, 可能なかぎり80に収める. 縦も1画面に収まるくらいが良い.
もちろん, reasonableな理由があれば, それをオーバーしてもOK

・ソフトタブを利用

・実装には, もちろん, 他のライブラリを利用してもOK.
asdf, clbuildやquicklispで入るものが望ましいが... 要議論

・documentation stringを書く(英語が望ましい)

ほかにありますか?

-- ryohei

[さくらんぼ]

lambda_sakuraです。

pythonには明くないのですが、__hoge__みたいな特殊な名前とかありますよね。

それの扱いなど気になりますね。

参考情報として、pythonの命名規則の載っている資料(PEP)です。

http://oldriver.org/python/pep-0008j.html

2010年12月3日2:59 Ryohei Ueda <gara...@gmail.com>:

[Ryohei Ueda]

garaemonです

__hoge__系はかなり厄介ですね.
というか, __hoge__系のものは, CL上で提供するのが難しい機能が多いと思っています.

例えば, メソッドの, __eq__とか__lt__を実装するのは微妙だと思ってます.
Pythonのオブジェクトシステムと同じものをCLOS上につくるのには懐疑的です.
CL的には, 高階関数で提供するところですが, これをどこまで実装すべきAPIとして理解
するかは, 議論しどころです

ですので, そういったものを利用する関数は, クラスに定義するよりは, 高階関数
にするのかなぁと思っています. まぁこれは要議論です

ほかには, __version__, __doc__, __name__がありますが, これはCL上でやるのは難しいですね.

pepによると, __hoge__系は勝手に増やすな!ということらしいので, それぞれ議論して
落とし所を探すのかなぁと思ってます.

ちなみに, __builtin__モジュールはclap-builtinパッケージとしました

-- ryohei

2010/12/3 さくらんぼ <lambda...@gmail.com>:

[CHIBA Masaomi]

g000001です

*foo*と+foo+はclでメジャーなところだと思うのですが、
<foo>はあまり馴染みがないかなあと思いました。

Dylan由来でScheme系(gauche等)で使われていると思うのですが、
http://www.opendylan.org/books/drm/Naming_Conventions

lisp1(Scheme/Dylan)だと、
(define-class <foo> () ())
<foo>
gosh> <foo>
#<class <foo>>
のように使い勝手が良いと思います。

しかし、lisp2だと
(defclass <foo> () ())
'<foo>
;=> <FOO>

(find-class '<foo>)
;=> #<STANDARD-CLASS <FOO>>

という風に、quoteを付けないといけないのが微妙だなあと思ったりしていました。

まあ、マクロ書けば良いといえば良いかもしれないですが…。

(defmacro defclass-clap (name direct-superclasses direct-slots &rest options)
`(progn
(defclass ,name ,direct-superclasses ,direct-slots ,@options)
(define-symbol-macro ,name (find-class ',name))
,name))

At Fri, 3 Dec 2010 15:08:30 +0900,

[Ryohei Ueda]

garaemonです

<>は最近はCLでも広く使われ始めているconventionなのかなぁとおもっていました
http://www.ros.org/doc/api/roslisp/html/index.html#types

CLでクォートが必要なのは, (defclass hoge ...)がhogeにクラスインスタンスを束縛しないのが
その理由ですよね?
他にクラスのテーブルがあって, そこからシンボルをキーに引いてくる...としていると,
しかたないかなぁと思います.
gosh> (define-class hoge () ())
hoge
gosh> hoge
#<class hoge>

もしも, hogeシンボルに値をいれてしまうと, (let ((hoge 1)) ...)みたいなコードがあると問題がある(?)から
こうなっているんでしょうか?
そういう意味では, define-symbol-macroは怖い気がします

しかし, 名前が衝突しないなら<>というnaming conventionも必要ないなぁとは思います.
たしかに, CLのbuiltinな型との対応をかんがえると, <>は無いほうがよいですよね.

結論として, このクラス名のnaming conventionは無しにしましょうか.

-- ryohei

2010/12/3 CHIBA Masaomi <chiba....@gmail.com>:

[Ryohei Ueda]

garaemonです

naming conventionに関して, CLikiに良い資料がありますね
http://www.cliki.net/naming%20conventions

<hoge>はOccasionally seenらしいのでそこまで一般的ではないのですね.

CLikiのOften seenあたりまでは利用したいなぁと思います

-- ryohei

2010/12/3 Ryohei Ueda <gara...@gmail.com>: