5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

 会社でプログラムを作る時、何か決まりとかある?

1 :仕様書無しさん:04/12/06 23:19:43
会社のプログラムを作るときになんか、決まりとかある?
おもしろいルールとかあったら是非書き込んでくださいな♪

ちなみにうちの会社は一番最初に作成者の生年月日をなぜか入れなければならない

2 :仕様書無しさん:04/12/06 23:20:33
2get

3 :仕様書無しさん:04/12/06 23:30:15
イースターエッグを入れなくてはいけない。

ネタを考えるのが大変。

4 :仕様書無しさん:04/12/06 23:37:18
ボケにはかならずツッコミをいれなくてはいけない。

ツッコミが甘いと顧客から怒られる。

5 :仕様書無しさん:04/12/06 23:55:49
会長の思いつきで、社外のソースをコピペした場合は引用元を
コメントに残すってことにしたんだけどすぐに破綻したw

6 :仕様書無しさん:04/12/07 00:49:58
4tab

7 :仕様書無しさん:04/12/07 00:54:05
プリフィックスを統一する。

8 :仕様書無しさん:04/12/07 01:03:00
エラーが出たら、ささいなことでも必ず例外処理を行うこと。
例外処理は専用のclass作って、一箇所にまとめる。

9 :8:04/12/07 01:04:38
必ずっていうのは、ifやswitchで逃げないってことね。

10 :仕様書無しさん:04/12/07 05:54:06
goto使用禁止
例外禁止
関数の戻り値は全てboolとする
各関数の最初で必ず引数チェックを行う
関数を呼び出し後、必ず戻り値をみて成功/失敗判定を行う

エラー情報を設定する独自の関数とかあって、関数に失敗したときの処理ってのが5-6行必要で、
それが使いにくいもんだから
エラーチェック専用の関数作ってその引数チェックしてさらにエラーチェック関数が成功したか判定して
簡単なプログラムのはずなのに、なんかすごいことになってます

11 :仕様書無しさん:04/12/07 09:27:48
>>10
でも、実際はテンプレの使い回しで、修正箇所は限られてますから。

12 :仕様書無しさん:04/12/08 01:38:37
命名規則はやめてホスィ。
基本が和名なんだが、音的に伸びる音は省略。

例)収入チェック → CheckSyunyu

しゃ しゅ しょ も漏れは sha shu sho 派なのに・・・・。
規則上 sya syu syo ・・・。

やりづれぇよ。

13 :仕様書無しさん:04/12/08 03:06:10
>>12
なぁ、そんなことよりもっと大事なことあるよな。
今更、手癖直せと言われてもなぁ。

14 :仕様書無しさん:04/12/08 07:11:07
「コーディング規約」という単語も思い浮かばなかった >1 の類友スレ。

15 :ほんたま:04/12/08 10:20:37
にーらよ、我が社では、仕事を受託したら、プログラミングを始める前に、伊勢神宮から神主を呼んで起工式を行う。
プログラミングが完成したら竣工式を行うのが決まりだ。
また完成したプログラミングを納品する前に、盛り塩をしてお払いし破魔弓と一緒に納品するのが習わしだ。

16 :仕様書無しさん:04/12/08 10:39:37
修正箇所にはコメント入れる。

// update 4649 suzuki start
if(a < 1) {
  // update 4649 suzuki old
  // if(a > 1) {
// update 4649 suzuki end
  b = 1;
}

修正が進むと膨大なコード量になって凄く仕事した気になれる。

17 :仕様書無しさん:04/12/08 11:03:17
>>16
普通だろう。修正日、修正した人間の名前も入れる。

18 :仕様書無しさん:04/12/08 12:52:01
>>17
普通じゃねぇよ。
バージョン管理ツールくらい使えよ。

19 :仕様書無しさん:04/12/08 13:55:42
>>18
おもしろいルールということで。。。

20 :仕様書無しさん:04/12/08 16:26:08
おやつ300円以内

21 :仕様書無しさん:04/12/08 17:04:09
袋とじ5ページ以内

22 :仕様書無しさん:04/12/08 17:44:00
社内オナ禁止

23 :仕様書無しさん:04/12/08 17:50:07
バグを作らない

24 :仕様書無しさん:04/12/08 17:59:52
何も作らない

25 :仕様書無しさん:04/12/08 18:05:12
無駄な時間を作る

26 :仕様書無しさん:04/12/08 18:55:53
コーディング規約チェックツールでエラー0である事。

27 :仕様書無しさん:04/12/08 19:01:43
#include <stdio.h>
//おまじない。

28 :仕様書無しさん:04/12/08 20:48:59
main()
{
  //うらない。
  switch ( rand() % 3 )
  {
  case 0:
   printf("大吉。プログラムは実行されるでしょう。")
   break;
  case 1:
   printf("吉。プログラムは実行されますが、バグがあるでしょう。")
   break;
  case 2:
   printf("大凶。プログラムは実行されません。")
   return;
   break;
  }

  //初期化処理




29 :仕様書無しさん:04/12/08 22:48:02
ループカウンタで「j」は「i」と見間違えやすいから使わない。

30 :仕様書無しさん:04/12/09 08:23:07
可変幅フォントなんて使わないよ。

31 :仕様書無しさん:04/12/09 17:48:58
>30
それはお前の開発環境の問題だろ?

32 :半透明アヒル ◆FDe1.0QRac :04/12/10 10:17:42
>31
え、使っているんですか?
人それぞれだからいいのですが…

使いづらくないかな〜と思いますた。

33 :仕様書無しさん:04/12/11 00:50:54
>>32
騙されるな。
そんなもんウケ狙い以外で使うPG居ないよ。

34 :仕様書無しさん:04/12/11 09:34:11
可変幅フォント使ったらiとjが見づらくて困るじゃないか。

35 :仕様書無しさん:04/12/11 12:52:20
>32 ??
>30は、このすれはコーディング規約とか約束事の話しで、
もまえの環境で可変幅使おうがしったこっちゃない。ってことだろ?

上と話しは違うけど、外人は可変幅つかってるんじゃねーの?

36 :仕様書無しさん:04/12/13 09:24:58
>>16
すげーアホだな

37 :半透明アヒル ◆FDe1.0QRac :04/12/13 10:40:33
>36
前にいたところで実際にやってました。
結構あると思いますよ、そういう会社。


38 :仕様書無しさん:04/12/13 11:29:01
>>36
バージョン管理ソフトの使い方の知らない会社なんていくらでもあるんだよ。

39 :仕様書無しさん:04/12/14 10:11:58
30マン人規模のユーザーを想定しているわりには決まりはない。
プログラマに押し付け。
すごいアバウト。
いいのかよこんなんで。


40 :仕様書無しさん:04/12/14 15:26:17
>>39
きっと「決まりを作るのがマンドクセ」なんだろ。
全く決まりが無いという事実が、他のリスク管理も極めて貧弱であるだろうと想像出来るけどw

41 :仕様書無しさん:04/12/14 20:28:56
>>39
決まりは無いけど、バグの責任は取らされるんじゃない。

42 :仕様書無しさん:04/12/14 21:59:22
プログラムの動作そのものには関係ない部分(ローマ字の綴り方とか)で
自分の、あるいは世間一般のやり方と違う妙な趣味を押しつけられるのは
非常にストレスフルですな。

43 :仕様書無しさん:04/12/14 22:23:27
コード書くときは必ず vi を使わないといけない所があった・・

まぁおかげさまでデスマったわけだが

44 :仕様書無しさん:04/12/14 22:27:05
>>42
まあ、コーディング規約のように、目に見えるものは、アフォでも分かるからな。
なぜそこまで得意満面で自分の趣味を押し付けられるか不思議でしょうがないがな。

本質は、プログラムが仕様通り動作するかどうかなので、設計やテストで締めてお
けば、コーディング規約なんかで締めつける必要は無いはずなんだがな。
多人数でやる時は、命名規約ぐらいかあったほうが便利と思う時があるが。

45 :仕様書無しさん:04/12/14 22:51:21
>>43
え?vi使わないで何使うの?って会社に居たことがあります。

46 :仕様書無しさん:04/12/15 02:53:33
コード書くときはBSDカーネルコードと同じインデントで書けってのが今の会社でも院でも使ってた方式だなぁ。

変更した箇所にはCVSで戻れるように変更時刻をコメントに入れるってのもそうだ。

っていうかバージョン管理ソフトを使わずにプロジェクトを始めようという神経そのものがわからない。PM刺してでも使えとか言いたくなるんだが、いるんだろうなぁー、CVSが何の略だかわからんようなPMとか。

47 :仕様書無しさん:04/12/15 12:21:55
>>43
viを強制するのはちょっとアレだが、そのお陰でデスマって・・・。
あんなの二日もありゃ自然に覚えるだろ

48 :仕様書無しさん:04/12/15 14:01:30
そうそう、上司でいたよ、変な癖おしつけるの。
 if (flag) {
ってとこを、
 if (flag != FALSE) {
みたいに、はっきりわかるように書けと。
まあ、分からん事も無いけど(1%くらいは)
そんぐらい、見ただけでわかるだろ!

49 :仕様書無しさん:04/12/15 15:39:26
VB6だけど
定数との比較は代入と間違わないように
if(2=var)
って書けって・・・orz

50 :仕様書無しさん:04/12/15 19:23:01
>>49
それCでやる事があるよな。
VBだと If 6 = ver Then だろ?

51 :仕様書無しさん:04/12/15 20:05:53
>>48
あんた以外にPGがいないならいいんだよ
でも馬鹿な組み方する奴ってのは必ずいるわけで

一律それ駄目って決めとくと、管理する側はやりやすいんだよね




52 :仕様書無しさん:04/12/15 20:23:43
if(a)をif(a!=0)と書け、というような処理上意味のないことでも、
ソース量が膨大になってくると書式が統一されているかどうかは可読性に関わってくるから、
複数人での仕事ならそういう規約を作るのはそれなりに意味がある。
ってかその程度で五月蝿く言うPGは度量が狭い。



malloc不可ってどういうことだよ('A`)

53 :仕様書無しさん:04/12/15 20:43:34
>>50
最近の親切なCコンパイラはif文に=が一個少ないと警告文出してくれるのもある。

>>52
>malloc不可
規則作った奴がコボラーかVB厨だろ、きっと。

54 :仕様書無しさん:04/12/15 20:55:25
>>52
分かるよ。俺はキミとか48の上司の方が正しいと思う。
何でも自分ルールで短くすればかっこいいと思ってる馬鹿がいると困る。
やりすぎってのも困るけどある程度は必要だね。

55 :仕様書無しさん:04/12/15 21:08:32
malloc使った事がない。

56 :非48:04/12/15 21:09:09
じゃあ
if( flag == TRUE )

if( flag )
ではどちらなのかなあ。
「はっきりわかるように」ならば俺の目には後者に軍配があがるのだが

>>54
「自分ルール」ではない。言語仕様さ

57 :仕様書無しさん:04/12/15 21:11:21
>>56
>if( flag == TRUE )
どちらも糞も、頭が悪いとしか思えない。

58 :仕様書無しさん:04/12/15 21:14:38
mallocなぞ使わなくても vectorで十分代用可能

59 :仕様書無しさん:04/12/15 22:17:48
int と bool 同一視するのが気持ち悪くてしょうがない俺はjava厨。

60 :56:04/12/15 22:28:36
>>57
そうだね
if( flag == TRUE )
は確かに「頭が悪い書き方」だよ。そして
if (flag != FALSE)
も同じだ。と言いたいわけだよw

61 :仕様書無しさん:04/12/15 23:29:57
>>55,58
malloc,memset,memcpy使った事無い。
先輩のソースで
memset(strbuf,0,256);
とかやられるとかなり鬱な気分になる。

62 :仕様書無しさん:04/12/15 23:39:19
>60
正気ですか?

63 :仕様書無しさん:04/12/16 00:10:19
大文字で書いているところからして、C++ではなくCで

#define FALSE 0
#define TRUE 1

とかやってるんだろう。そいつは頭悪いと言われても仕方ない。

64 :仕様書無しさん:04/12/16 01:05:09
コードの可読性がとかほざいてる奴は、途中で人が抜けるような、過酷な環境で働いてるのか?
それとも、再利用とか夢見てるのか?
または、コードレビューのような、非効率的な事をやれるぐらい暇なのか?

まあ、他人のソースを見ないといけないなんて、こ苦労なこった。

65 :仕様書無しさん:04/12/16 01:42:30
>>64
君は保守をした事がないのか?

66 :仕様書無しさん:04/12/16 01:43:54
少なくとも相当恵まれた環境だな、>>64の仕事場は。

67 :仕様書無しさん:04/12/16 02:00:27
>if( flag == TRUE ) 
flag が論理型のつもりならば、それを定数と比較しようとする行為が
  if (a == b)

  if ((a == b) == TRUE)
と書くくらい間抜けだな、と。

まあ世の中には戻り値が BOOL 型 (一応、論理型のつもりらしい) で
TRUE, FALSE, -1 の3値を返すという、「更に上を行く莫迦」なAPIも存在するんだがな。

68 :仕様書無しさん:04/12/16 02:14:33
わかってないやつが見ることを考慮して
わかってて書く場合があるから一絡げに間抜けとはいえない<a==TRUE

わかってないやつが居なくなるのがもちろん理想だが、
理想に過ぎないと気付かないやつはそれこそ現実をわかってない

69 :仕様書無しさん:04/12/16 03:31:15
とりあえず、わかんないヤシが見ても、なんとなく分かった気になれるのが理想だろ?
でも、それも規約によって実現しないのが現実だろ?
VB6んときは、MSDNにのっとってた希ガス。

70 :仕様書無しさん:04/12/16 23:34:40
>>68
言い訳はいいから教育くらいしろよ。

71 :64:04/12/17 00:33:50
>>65
保守?
現在動いてる物にケチつけて、新規開発の案件を取ってくる営業活動のことか。
いい仕事だな、俺も誘ってくれ。

72 :仕様書無しさん:04/12/17 01:18:27
デジタル土方とデジタル貴族が喧嘩するスレはここですか?

73 :仕様書無しさん:04/12/17 01:24:25
「では、おれが引剥をしようと恨むまいな。おれもそうしなければ、飢え死にをする体なのだ」

「パンが無ければケーキを食べればいいのに」


話がかみ合うわけが無いな。

74 :仕様書無しさん:04/12/17 08:53:36
噛み合わないのは >>64 が素人或いはゲーム屋だからだろう。

75 :64:04/12/18 03:08:41
>>73
変な例えで納得しようなんて、やればできる子だと思ってたのに残念でなりません。
ただ、73(=65?)殿が保守という仕事を分かりやすく説明し、いかにコードの可読性が
大事か、ご提示して頂けると、まだまだ期待しているわけですよ。
74殿の指摘も十分考慮し、素人やゲーム屋にも分かるご回答をお願いしますね。

76 :65!=73:04/12/19 00:03:52
保守は大半の場合、顧客側から提起される。
新規システムである場合、「使ってみて本当に欲しいものが判明する」ことはとても多い。
フリーソフトの世界においても人気のあるソフトほどバージョンアップが止まらないという事実を思い起こされたい。
バージョンアップがないソフトは死んだソフトなのだ。
可読性はあるのが当然。動作単位の構造まで容易に読み取れるのが望ましい。
この様に書くのは最高難度なのだけれど。
とりとめのない記述をして申し訳ない。

77 :仕様書無しさん:04/12/21 04:17:03
保守を繰り返して行くとさ、日付付きのコメントが溜まりまくってゴミの山にならない?

78 :仕様書無しさん:05/01/02 07:53:25
>77

そうか、あれはゴミだったのか、、ありがとうございます。
こんなものでもきっと何か必要なものなのだろうと思ってました・・・

誰も参照しないもんなぁ。しかも、他も同等の記録が山ほどあるし・・・

79 :仕様書無しさん:05/01/02 18:09:35
いや、同等の記録があればいいんだけど、日付付きコメントって「仕様書に書かれなかった
コードの歴史」みたいなものだからね。ある時期には意味があったわけよ。それでなかなか
ばっさりやる勇気が出ない。

80 :仕様書無しさん:05/01/03 05:23:40
>>79
勇気の問題ではないような。
「ばっさりやる」結果の、メリット/デメリットを正しく判断すれば、どうすべきかは決定可能だ。
おそらくコードが寿命を終えるまでの、コスト(+精神衛生?)で判断すべきなのだろう。
#ちなみに私はいつも「ばっさりやって」いるw
「開発/保守のプロセス/過程を記録したい」という希望は尊重するが、
それはコードに残すべきものなのかどうか

81 :仕様書無しさん:05/01/15 02:29:55
コーディング規約を守らないこと.
バイトは何かを作っている途中に辞めること.
バイトは辞めるとき,消息不明,連絡不通になること

Cppなんだけど
入ったとき,先輩の続きから作らされて,
classのメンバを
VSのテンプレートみたいにm_hogeでやってる
次は別の人の続きで
hoge_って後に"_"付けてる
混在してて,困った

82 :仕様書無しさん:05/01/15 02:43:15
いいかげん名前変更だけで良いから
まともなリファクタリングブラウザを作ってほしい物だ。
コンパイラメーカーならそんなに難しくないだろ。

83 :仕様書無しさん:05/01/15 21:10:01
・抽象化しない
・staticメソッドを使う。インスタンスメソッドは必要なときだけ定義する。
・オーバーライドしない
・オーバーロードしない
・インナークラスはできるだけ使わない

。。。なんのためにJavaでコーディングするのかと。

84 :仕様書無しさん:05/01/15 21:14:14
DBの命名規則

テーブル名は6文字
先頭の2文字はマスターか、スレーブかを表す
残りの4文字でテーブルの意味を表す

カラム名は8文字
先頭の4文字はテーブル名の後ろ4文字をそのまま持ってくる
残りの4文字でカラムの意味を表す

85 :仕様書無しさん:05/01/15 22:21:30
>>83
ありえねぇ・・・・
悲惨すぎるぞそれ

86 :仕様書無しさん:05/01/15 22:38:19
>>85
つーか>>83って虚だろ。
いくらなんでもそれはありえない。

87 :仕様書無しさん:05/01/15 22:55:20
>>86
だよな! 
嘘だと信じたい・・・

88 :仕様書無しさん:05/01/15 23:44:03
「誰が見てもわかるようなコメントを書け」
常識のようで意外に難しい。

89 :仕様書無しさん:05/01/15 23:50:54
>>83
もしホントならポインタを使えないC言語に近いものが歩きがする

90 :仕様書無しさん:05/01/16 00:07:50
>> 83
非常に納得がいく。

91 :仕様書無しさん:05/01/16 00:41:31
>>89
日本語がおかしいニダ

92 :仕様書無しさん:05/01/16 04:31:20
トイレの男女別標識じゃないんだから、「誰が見てもわかる」なんてありえね〜よね。
「いちおう大卒で、プログラミングの訓練を受けたSEなら読める程度のコメントを書け」
程度に理解しておけばいいよ。

93 :仕様書無しさん:05/01/16 08:57:28
>「いちおう大卒で、プログラミングの訓練を受けたSEなら読める程度のコメントを書け」
こういうコメント嫌い。

94 :仕様書無しさん:05/01/16 13:41:14
知り合いのところだと逆に、
「開発陣にのみ通じる言葉でコメントを書け」だそうだ。
これはこれで大変そうだな。

95 :仕様書無しさん:05/01/16 17:49:23
「のみ通じる」・・・凄い隠語で書かなきゃいけなそう。
「誰にでも読める」=2歳児とか幼稚園児とか、課長とか、部長とか、・・・にも読めるコメントかよ?

96 :仕様書無しさん:05/01/16 23:44:10
どっちも極端すぎると困ると言う見本。
「使うやつにわかれば良い」で良いんだよ。
コメントなんて。

と言いたいけど言えない小心者の俺です。 orz...

97 :仕様書無しさん:05/01/17 02:02:06
コメントを書かない

98 :仕様書無しさん:05/01/17 05:49:53
日本の組織はまず認めないだろうけど、それも一つのポリシーなんだよね。
ワインバーグが、「右側のコメント領域を紙で隠して読む」とか、ある本で書いてたことあるし。
コーディングがトッチラでコメントだけ尤もらしいよりは、コーディングだけで読めるコード
のほうがずっとまし。

99 :仕様書無しさん:05/01/23 18:41:16
>>86、87、89
実話だっちゅうねん。予想はしていたものの(笑)、しばらく見てないうちに
疑問の声があがっていたか。。。
どこのどういう案件(現場)かは教えられないが、N○Cのアホな中堅社員が作った
ルールらしい。まだ、オブジェクト指向が浸透していなかった時代に開発が
始まった(もっとも、日本の現状を診ると今でも浸透していないか?)
システムらしくて「協力会社にはどうせオブジェクト指向わからないから
禁止しよう」ということになったらしい。。。(じゃあ、教えろよ。。。)
俺がその職場に来た頃にはすでにそのルールにのっとって作られた悲惨な
コードが山盛りですよ。(うっぷ。お腹がもういっぱい)
唯一の救いはサーバサイトJavaじゃないこと。。。サーブレットやEJBの
世界でこんなことやられてたまるか、と。
元々、マルチベンダ系のPJだったんだけど、他社の都合でJavaを使っていた
せいもあり、N○Cにもjavaがわかっている奴がいなかったせいもあるらしい。


100 :仕様書無しさん:05/01/23 18:45:46
まあ、付け加えるならば他社から提供されているフレームワークを基底クラス
として使うのでオーバーライドはまったくしないわけではない。。。
しかし、それにしたって抽象化の禁止を歌われた時点で色々と。。。
もういいや。(涙)どうせ、強く主張しても誰も信用してくれないんだろ
うなと思ったけどさ。。。

101 :仕様書無しさん:05/01/23 21:33:16
まぁ・・倒れぬ程度にガンバレ・・・。

22 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)