アカウント名:
パスワード:
実際に数100人規模のプロジェクトを経験してみると分かりますが,現場のプログラマで継承の概念を理解しているなんてのは数%もいれば多いぐらいです.その数%でさえ有効に継承が使えるかと言えば極めて怪しい.言語の機能としての継承は使えても,システム設計として継承が使えないという場合が非常に多いです.
そのため極少数(数人程度)の共通技術チームのみが制限なしでコードを取り扱えるようにして,残りは制限をかけるという方式のほうが,まだましな物ができます.とは言っても,この方式が通用するのも100人前後の質の高いメンバーが揃ったプロジェクトまでですけどね.それ以上の規模になると,常識では想像できないような腐れコードが機械的に量産されてきます.
ルールに則ったからと言って理解しやすいコードとは限らない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
ルールを無視したコード (スコア:1)
ルールを無視したコードを書いたプログラマに対する罰則規定を明文化するってのはどうなんでしょう。システム開発において、コーディングに関するルールは社則扱いでも構わない気がするんですよね。ちゃんとしたルールであれば、それに従わないと後で会社に損害をもたらす可能性がある訳ですから。
どうでしょう?
Re:ルールを無視したコード (スコア:2, 参考になる)
Re:ルールを無視したコード (スコア:1, すばらしい洞察)
# 笑えないのでAC
Re:ルールを無視したコード (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:ルールを無視したコード (スコア:1)
それに、今はまっとうなルールでも状況が変化すれば糞になりうるんだし、ル
ールでなくマナーをソースコードレビューでも繰り返して醸成するしかないん
じゃね?
Re:ルールを無視したコード (スコア:3, 参考になる)
実際に数100人規模のプロジェクトを経験してみると分かりますが,現場のプログラマで継承の概念を理解しているなんてのは数%もいれば多いぐらいです.その数%でさえ有効に継承が使えるかと言えば極めて怪しい.言語の機能としての継承は使えても,システム設計として継承が使えないという場合が非常に多いです.
そのため極少数(数人程度)の共通技術チームのみが制限なしでコードを取り扱えるようにして,残りは制限をかけるという方式のほうが,まだましな物ができます.とは言っても,この方式が通用するのも100人前後の質の高いメンバーが揃ったプロジェクトまでですけどね.それ以上の規模になると,常識では想像できないような腐れコードが機械的に量産されてきます.
Re:ルールを無視したコード (スコア:0)
> 現場のプログラマで継承の概念を理解しているなんてのは数%もいれば多いぐらいです.
> その数%でさえ有効に継承が使えるかと言えば極めて怪しい.言語の機能としての継承は使えても,
> システム設計として継承が使えないという場合が非常に多いです.
こういう話はかなり良く聞くけど、こういうのを聞く度に難しい概念の普及に失敗している
言語というのは如何なものか?と思いますね。作った人間は自分が分かるから
教えることに熱心ではない→したが
Re:ルールを無視したコード (スコア:1, 興味深い)
一. 継承の概念は複雑度が上がり、引継に問題があるので使用しない事
という感じのを実際に目にしました。
その会社の人はまったく無視していましたが。
これを守るとするとなにも書いてはいけない事になって、、、
「、、、してはいけない」とか「、、、しなくてはいけない」
ってコーディング規約はめちゃくちゃなのが多い。
Re:ルールを無視したコード (スコア:0)
標準ライブラリーや有名どころのライブラリーも
その否定の対象になってしまう。
主義を変えないなら「その言語を使わない」という選択肢が無難なところだろうな
Re:ルールを無視したコード (スコア:1)
つーか,そうは無いよね。
Re:ルールを無視したコード (スコア:0)
こういう態度の人間ばっかりだとよくなる余地は無いよ。
Re:ルールを無視したコード (スコア:0)
最近では再利用性は重視しない傾向にありますね。
>一. 継承の概念は複雑度が上がり、引継に問題があるので使用しない事
継承よりも委譲、コンポジットが推奨されるなら意味がありますね。
Re:ルールを無視したコード (スコア:1)
(I can't get no) satisfaction
Re:ルールを無視したコード (スコア:1)
ルールに則ったからと言って理解しやすいコードとは限らない。
-- pyon
Re:ルールを無視したコード (スコア:0)
Re:ルールを無視したコード (スコア:1)
止めたほうが良ろしいかと。
詳しくはトム デマルコ [amazon.co.jp] の本をどうぞ。
プログラマ同士でソースコードを交換して、
お互いプレゼンしあう環境が欲しいですね。
他人が見ると思うと、きれいに書く習慣が身につくと思います。
きちんとデザインができていれば、
実装は、それなりでも良いものになりますよ。
なぜこんなことを言い出したかというと (スコア:1)
Re:ルールを無視したコード (スコア:0)
Re:ルールを無視したコード (スコア:0)
それって大手、中小でどれぐらいの割合がいるのでしょう・・・・。
1000人 社員が居て”問題の無い”ルールが作れる人って
1,2名ぐらい?
実は居ないとか言うオチもあるかも・・。
Re:ルールを無視したコード (スコア:2, すばらしい洞察)
俺としては、そういう場合は[*]自作せずに、
巷から良い奴探すのがいいと思います。
Javaとかだと「コーディング 規約(あるいは標準?)」とかでググったら
得られるものが幾つかあるようです。
Java以外を使ってる場合でも、それなりに参考にすれば(合わないところだけアレンジすれば)いいかなと。
[*]注:
「そういう場合」を事故判定出来るかどうか自体が、能力に依存します(笑)ので、
実際には、「そういう場合」だという自覚があろうがなかろうが、まずは巷を探すのがお勧めです。
…そうやって「目を肥やす」ことができることをお祈りします。
もっとも、良いものに出会ったとき、それを良いものだと判断するにも能力が必要ですが(^^;。
つまり「王道は無い」んだよね。
Re:ルールを無視したコード (スコア:0)
ないので質問です。
以前関わってた会社のC言語に関するコーディングルールで
・関数なら関数名にfuncをつける
・プロシージャなら関数名にprocをつける
というものがありました
Re:ルールを無視したコード (スコア:1)
値を返す/返さないで分けているなら、関数プロトタイプ宣言でわかるから無意味。
なにか意味があるにしても、もっとましな命名ルールが考えられるはず。
例えば副作用の有無で分けるなら、「プロシージャにはprocをつけて、
関数にはなにもつけない」のほうがまだまし(たいがいは関数だろうから)。
でもまずは、こんなルールを作った人に聞いてみるのが一番。
どうせろくな理由じゃないとは思うが。
Re:ルールを無視したコード (スコア:0)
そんなことしないで済むための命名規則でしょ。
Re:ルールを無視したコード (スコア:1)
逆に、そんな考え方をしないで済むために、
ctagsやGLOBAL、あるいはVC++でもEclipseでもなんでもいいが、とにかくそういう文明の利器を使って、
その関数の定義を一瞬で見に行けて、しかも一瞬でまたもとの場所に戻る ことが出来る環境を、用意しとくべきです。
#メモ書きのテキストとソースとを、同一のエディタで扱っていると、
#メモ書きから関数名でタグジャンプできるようになるので、なかなか快適です。
#Mail書きながら行って戻ってが出来るんだもんなあ。
なお(GLOBALとかの)HTML出力については、「戻る」機能は、それこそwebブラウザの「戻る」の機能が有効です。
変なブラウザで無い限り、スクロール位置も含めてもとの位置に戻れるでしょうから。
そういやIEって、Ver4だか5だかからは「カーソル位置」まで復帰するようになったんで、だいぶ使いやすくなりました。
あと、そういったタグジャンプに参加することが出来ないようなツールに、
ドキュメントとかいう名目でソースの断片(特に関数名を含む文字列)をコピペすると、
結果的に生産性を損ねますので、控えるのをお勧めします。
いや、つまりMS Officeとかの話なんですが(笑)。
関数名一覧をExcelで作るなんてのは愚の骨頂。わざわざ死んだ情報を作ってどうする?
Re:ルールを無視したコード (スコア:1)
# 全部に procfunc とつければ万事解決ではないか?
-- 哀れな日本人専用(sorry Japanese only) --
Re:ルールを無視したコード (スコア:0)
> ・関数なら関数名にfuncをつける
> ・プロシージャなら関数名にprocをつける
> というものがありました。そもそも関数とプロシージャの
> 区別さえ曖昧なものなので自分では全く不必要なルール
> だと思うのですが、どうでしょうか?
このようなルールがあったもいいんじゃない?
プロシージャってのは、bool型か、void型でコー
Re:ルールを無視したコード (スコア:1)
getterみたいな考え方をするのが良いと思います。
つまり「getXXXX」という関数名にする。
これなら、名前としても「自然」なので。
もし、値が返るかどうかでスッキリ区別できないなら、
proc/funcという区別も同じくらいスッキリしないはずなので、
proc/funcという書き方を導入する価値もまた、無い。
それだけのことです。
>プロシージャってのは、bool型か、void型でコードが長々としたもので、
>関数ってのは、コードがすっきりとしていて値が返ってくるもの。
「コードがすっきり」かどうかで区別するのは、やめたほうがいいと思う。
それは、すっきりしてない関数は、単に全て駆逐するのが正しい道だからです(笑)。存在価値なし。
あー。冗談だと思いたいです。
「すっきり」ってのはつまり、それこそgetterみたいに、
属性みたいなものを単に得るだけ、のものを意図なさってますか?
まあそうだとしたら、それこそsetXXXXって名にすると良さそう。
そんなわけで、
> (char *) funcGetName(int id)
既に「Get」と書いてあるんだから、「func」は蛇足でしかないと俺は思います。
つまり「getName」という名にすればいい。
Re:ルールを無視したコード (スコア:0)
Re:ルールを無視したコード (スコア:0)
# 別の言語の流儀を持ち込んでもロクなことにはならないのにね。
Re:ルールを無視したコード (スコア:0)
Re:ルールを無視したコード (スコア:0)
プロシージャって何ぞや?
値を替えさない関数のことか?
特に返す値が無いと思っても、成功や不成功ぐらいは返した方が良いよ。
コーディングルールの変更を提案してみよう。
もし、提案が無視されたら、そんな会社は見きってしまえ。
Re:ルールを無視したコード (スコア:0)
1箇所から1回しか呼ばれない関数よく作ります。
そういうのは手続きといって良いのでは。
もしくは副作用がメインなのが手続きで値がメインなのが関数とか、副作用の有無で分けてるのかもしれません。>元コメント
Re:ルールを無視したコード (スコア:0)
やっぱり必要性は?、ですね。
みなさんありがとうございました。
Re:ルールを無視したコード (スコア:0)
少なくともルールを決めた人は何らかの必要性を感じてたのでしょうから、それが正しいものかどうかを評価するためには、外野の憶測などは気にせずに大本に確認する必要があるでしょう。
Re:ルールを無視したコード (スコア:0)
メールを送ってきてくれますよね。
皆、気づいてないんでしょうか。
どうにかしてくんないかなぁ。
Re:ルールを無視したコード (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:ルールを無視したコード (スコア:0)
Re:ルールを無視したコード (スコア:1)
新しい技術は先ずRFCを書いて提案して、実際に動く実装例を示して、、、 という経過を経て標準扱いになってきています。
Re:ルールを無視したコード (スコア:0)
de facto standard がそのまま RFC になった例はたくさんありますよ。
例えば RFC 1945 (HTTP/1.0) がリリースされた時点 (1996年5月)
では web site はすでに 100 万以上あったはずです。
Re:ルールを無視したコード (スコア:0)
RFCが出来てからそれを破るのでは意味が違うのでは。
某M$のように自社の都合に全部強引にあわせるところもありますが・・・。
あれはヤクザです。