これからコードを書く人に絶対やって欲しいこと★3

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2013/06/04(火) 22:43:46.92
もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
2013/06/10(月) 02:29:30.86
だいたい、この手の話を理解できない奴っていうのはテストをする能力がないか、めんどくさがってテストをやってないんだよな。
自分のケツは自分で拭く様にすれば、自然と複雑さと副作用の少ない設計になるはずなんだが。
2013/06/10(月) 02:30:45.97
>>126
循環的複雑度が低いという事は、テストケースが少ない。
つまり、バグ発生率が低い。
2013/06/10(月) 02:31:33.48
循環的複雑度を初めて知ってはしゃいでるのか
2013/06/10(月) 02:34:41.85
>>129
単語だけ知って、なんとなくすごい事を知った気分になってるけど、よく理解してないんだろう。
いつの時代も新しい考えが生まれると、この手の困ったちゃんが大暴れするんだよな。
2013/06/10(月) 02:36:08.46
>>125
テストファーストで書いてれば・・・ね。
2013/06/10(月) 02:36:58.82
>>129
ん？誰にいってんの？
はしゃいでるだけの人ってどれよ？
2013/06/10(月) 02:40:41.72
ハイ、この話もうやめー

スレタイ読もうね

スレタイ！

スレタイ読もう！！！
2013/06/10(月) 02:43:44.05
3回も言わんでも
2013/06/10(月) 02:45:36.65
>>134
前スレの流れみるとしつこく言わないと延々続くからｗｗｗ
2013/06/10(月) 02:46:15.55
>>133
じゃあスレタイに則って言うぞ

循環的複雑度を下げろ(笑)
2013/06/10(月) 02:54:12.52
コードを書く人に絶対やってほしいことってのは
一つじゃない。たくさんある。

循環的複雑度を下げろっていうのは
その中の一つとして、正しいことなのに
妙に突っかかってくる人がいるんだよね。

なんでだろ？
自分の知らないことを言われたのが
悔しいとかなのかな？
2013/06/10(月) 02:58:22.10
オブジェクト指向を使えと言われて
極端に反論する奴と同じたぐいの人間だろうな。
2013/06/10(月) 03:02:18.15
>>137
平均値がーとか、例外的に循環的複雑度が高いメソッドがーとか頑張る奴がいるから
この話が終わらないんだよ。
2013/06/10(月) 03:13:13.79
>>124
アサートや例外も確認するし、出力というか挙動と言ったほうが良くね？
2013/06/10(月) 03:22:30.20
>>139
循環的複雑度の平均値を出すことに意味はない。

循環的複雑度の値の傾向としては、一部のメソッドが
ずば抜けて高くなることが多い。

で終わりじゃないか。
2013/06/10(月) 03:25:48.16
悪いプロジェクトでは循環的複雑度が
・低い・・・それなりの数がある
・中ぐらい・・・結構ある。
・高い・・・結構ある。
・ひどい・・・いくつかある。

良いプロジェクトでは
・低い・・・ほとんど
・中ぐらい・・・いくつかある。
・高い・・・無いか、まれにある程度。
・ひどい・・・全くない。


悪いプロジェクトでも、循環的複雑度が低い関数の数は
たくさんあるので平均を取ると少なくなってしまうので意味が無い。
143仕様書無しさん
垢版 |
2013/06/10(月) 03:52:10.59
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。
プログラムのソースコードから、線形的に独立した経路の数を直接数える。

循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。
2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。

M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数
2013/06/10(月) 03:52:19.80
>>142
s/悪いプロジェクトでは/循環的複雑度で判断可能な悪いプロジェクトの一例では

良いプロジェクトとよく似た循環的複雑度の分布を持つクソプロジェクトとかもあるから、
その文脈で提示する悪いプロジェクトの悪さの種類と一例であることは明示したほうが良いかと。
その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。
2013/06/10(月) 03:52:58.04
ほう
2013/06/10(月) 03:54:54.08
無理やり下げようとすると「連結されたコンポーネントの数」を減らす方向に向かわなくてはならないが
個人情報のように分割すると管理しにくくなるだけのものはやっぱり残さないといけないよね。
2013/06/10(月) 03:55:15.96
>>144
> その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。

そんなこと一言も言ってないし。
2013/06/10(月) 04:41:45.84
>>147
んなことは分かってるが、そう読めてしまうって事だよ。
>>55の下二行を見落とした>>58(56)とか居たわけだけど、>>142はそれ以上に誤解を招きやすいと思うが？
2013/06/10(月) 04:54:29.73
読解力無いんじゃね？
2013/06/10(月) 07:39:24.05
PNG仕様書読んでるが、心が折れそうです
そんな時は？
2013/06/10(月) 08:50:25.20
>>143
それwikiの丸々コピペじゃねえかｗ
2013/06/10(月) 09:00:57.23
>>150
GIFの仕様書を読んで気分転換
153仕様書無しさん
垢版 |
2013/06/10(月) 09:21:10.96
>>151
ああ、Wikipediaって入れるの忘れてた。

唐突に説明入れること自体に突込みが入るかと思ったけど入らなかったな。
「つかそれみんな知ってるから」みたいなの。
154仕様書無しさん
垢版 |
2013/06/10(月) 09:54:56.10
勉強すること自体を目的にしないで欲しい
別に具体的に何かを作る目標を持たなくても良いけど
勉強とアウトプットはセットで
今の自分の能力より少し難しい物を作ることにチャレンジしよう！
今作れるのが電卓や、トランプまででも全然恥ずかしくない
（最初からグランツーリスモを作れる人などいないし、
複雑なプログラムも実は単純な小さなプログラムの組み合わせだ）

綺麗なコードとか、デザインパターンとか吹聴する奴らは
本当に複雑なプログラムを作ることから逃げ出してる弱虫な
糞野郎なので勧誘に乗らないように！
彼らがぞれにはまるのは、自分の頭を使うことから逃げ出したいから
何かにすがりついてるだけで自信の無さの証明でしかない
ネットワークビジネスとかネズミ講みたいな物で、
それはあなたの才能をみるみる腐らせていく毒薬である

実は複雑なプログラムはアルゴリズムや、プログラム構造の設計手法を学んだだけでは
組むことが出来ない。
複雑なプログラムのロジックを頭の中で辻褄が合うように組み立てる事と
それを実際のプログラムコードに落とし込む訓練が必要なんだ
これは本を読んだだけでは絶対に身につかない
本ばかり読んでもオリンピック選手になる為には成れないように、
プログラムも実践によって、脳の特定の部位を訓練する必要がある
この訓練の差が、人によってコーディング速度に（誇張無しで）100倍の差が出る理由だ
2013/06/10(月) 10:32:09.12
もうやめようと思ったけど、いい例が出てるので書いておく

>>142
> 悪いプロジェクトでは循環的複雑度が
> ・低い・・・それなりの数がある
> ・中ぐらい・・・結構ある。
> ・高い・・・結構ある。
> ・ひどい・・・いくつかある。
>
> 良いプロジェクトでは
> ・低い・・・ほとんど
> ・中ぐらい・・・いくつかある。
> ・高い・・・無いか、まれにある程度。
> ・ひどい・・・全くない。

この悪いケースは、俺が平均的に高いと言ってるケース。
複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、
最悪よけいに分かりにくいコードが出来あがる。
低い、中も含めて全体的に設計をみなおすべきケースだな。
きっと俺の言うことが理解出来ない連中は、ここの認識が違うんだろうけど、
何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。

良いケースでは複雑度が高く出ているものは、単純に並列の分岐数が多いなどの理由で
実際は複雑ではないから、テストが書きにくいという事もないし、リファクタリングも必要ない。
こういうケースでは高いメソッドを含めて平均値を出しても、ほとんどその影響は出ない。
2013/06/10(月) 11:20:01.04
は？
if分の分岐とかまさにリファクタリングの対象だろ。
2013/06/10(月) 11:26:05.80
>>155
お前は原因と結果が全部逆なんだよ。

良い設計なら、循環的複雑度が大抵低い。
テストが書きやすいメソッドは、大抵循環的複雑度が低い。
これは正しい。

だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。
2013/06/10(月) 11:36:55.48
>>155
> 複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
> 結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、

なんで、「小手先のテクニックで無理矢理分割するだけになる」とか決めつけてるの？
「複雑度が高い、ひどい部分」を、正しいテクニックでリファクタリングすればいいでしょ。
2013/06/10(月) 12:08:46.96
>>157
お前のレスは明後日の方向ばかり向いていて、正直もう、どう反応していいか分からんｗ
2013/06/10(月) 12:42:00.39
このスレはけっこう大したことないな
言ってる割にメチャクチャ
2013/06/10(月) 12:46:29.54
>>159
そっくりそのままお返しします。
2013/06/10(月) 12:51:18.46
>>158
どうやらリファクタリングをいまだに小手先と言っちゃう輩が居るらしい
2013/06/10(月) 12:52:44.64
>>155
> 何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。
そこだけ改善すれば全ての問題が解決するかどうかはわからないが、まずそこの問題を解決することが
重要だよね。決して無駄な努力ではない。
2013/06/10(月) 12:55:10.01
>>155
> 単純に並列の分岐数が多い
のなら、そこをリファクタリングすればいいじゃない。
2013/06/10(月) 13:08:17.44
複雑なことをやろうとしたら、勝手に複雑度も高くならね？ｗ
2013/06/10(月) 13:12:39.79
>>128
テストケースの多寡じゃなくて、テストし易さの話をしてるんだけど。
2013/06/10(月) 13:14:32.65
そんな遠いアンカーに言われましても
2013/06/10(月) 13:42:07.26
まだ平均値とか言ってる馬鹿がいるのか
2013/06/10(月) 14:52:49.15
理牌（リーパイ）
2013/06/10(月) 20:49:18.81
うむ。今日は見方がたくさんで
俺がレスする必要がないなｗ
2013/06/10(月) 21:56:34.06
>>155みてて思ったのだけど、「平均」って単語を、数学的な意味での平均値としてじゃなく
「俺がこう感じたから平均的(?)にこうだ」っていう、間違った言葉の使い方をしているんじゃないかって気分になった

あと、重箱の隅だけどさ、
> 小手先テクニックで無理やり分割
具体例に紐づくような情報が少なくて、脳内想定が見えてこず、どういう作業を指しているのか読み取り辛い。
おそらく、リファクタリングでなんとか出来る状態じゃないコードが、大量に生み出されてしまったプロジェクトを想定し、
メソッド分割してもその場しのぎで意味が無い、って考えてるのではないかと推測してみているけれど、あってる？

でもそもそも、循環的複雑度やリファクタリング、ユニットテストの話は、全部火事の予防策であって、
炎上したり焼け焦げて残った失敗プロジェクトの、消化や立て直しを行うためのものではないよ。

> 全体的に設計をみなおすべきケースだな。
コードの循環的複雑度を調べるような段階で設計レベルの見直しは、現実的に不可能だと思う。
個人で開発してるならともかく、納期があるような仕事でやるのはコスト的に無理だろう。

もう既に>>157で簡潔にまとめてあるけれど、
設計が糞なのは、循環的複雑度が高いことで起きているのではなく、
メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。

そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
本来の使い方ができない値の平均なんて出しても、特に意味はないと思う。
2013/06/10(月) 22:00:17.92
前の方にテストファーストの話がちらっとでてたけど、
テストファーストでコーディングするには、ある程度実装経験がないと難しいと思う。
どういう機能を実装していくかのある程度の目安がたってないと、テストが書けない。
だから、これからコードを書く人にいきなり要求するのは、結構きついんじゃないかなーと。

まぁ、それでもテストは実装後に、みたいなアホなことだけは極力やめてほしい。
この考えのままの人間が大量に居る業界だけど、これからコードを書く人は
そういう間違った手法を、引きずり続けないようにしてほしい。

メソッドを実装するときは、そのテストケースの実装も考えながら、進めてほしい。
173仕様書無しさん
垢版 |
2013/06/10(月) 22:11:24.46
俺、循環的複雑度とか使った事ないけど
平均とか意味がないと思う。

どれくらい平易に書かれているかということなので
複雑度×行数で工数が出てくるって事だろ。

だけどよくできているかどうかはバグがない、出にくいことと
性能試験で期待できる性能が出てるかどうかまで見ないといけないかな。
2013/06/10(月) 22:16:06.18
俺も循環的複雑度使った事が無いので今測定したら
平均６ほどだったが、３０以上が所々にあった
これはズルいなｗ
2013/06/10(月) 23:53:41.45
問題点を知るために、他とは特出して悪いコードを探すのが
循環的複雑度を図る目的なのに、
それを平均化して何がわかるというのか？
2013/06/10(月) 23:59:39.05
>>171
> メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。
>
> そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
メンバー全体のレベルが低いからこそ、
第三者が考えた方法で計測するんだよ。

レベルが低い奴は、レベルが低いということすら自覚できない。
メンバー全員がそうなのに、どうやって悪いということを自覚するのさ？
自分らでは出来ないから、そういうメンバーにこそ
現実をつきつけなきゃいけない。

と言っても俺がつきつけることは出来ないからな。
循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。
2013/06/11(火) 00:13:41.42
自称できる奴の面白い所は
「周りがみんなバカで忙しい」
と言いながら、なんの改善案も提示出来ない所だな。

本当に忙しいなら環境を改善する。
改善出来ない理由は、自分でも何が悪いのかがよくわかっていない事と、自分が有能だと思いこみたいから。
2013/06/11(火) 00:16:24.35
他のスレでボロ出して赤っ恥かいてた循環的複雑度マンセーバカが消えたと思ったら
今度はこのスレで暴れてたのかｗ

たぶん噛み合ってないと思うから気づいてると思うけど
そいつ、まともに物作れないよ
開発経験も限りなく少ない
2013/06/11(火) 00:22:33.49
>>178
俺も見た記憶があるんだが、どのスレだっけ？

最近覚えた単語らしく、よく理解してないのに絶賛してたのが笑えたんだよな。
2013/06/11(火) 00:24:16.50
技術力が低い会社にありがちなこと
http://kohada.2ch.net/test/read.cgi/prog/1344190799/

自己解決した
2013/06/11(火) 00:50:17.29
>>178
君が循環的複雑度マンセーバーカだと思う人を
論破して見せたら？

現時点では、どう見ても、お前が負け犬にしか見えないから
2013/06/11(火) 01:01:55.93
循環的複雑度を否定している人が、何ひとつ根拠を示ていない件について
2013/06/11(火) 01:40:15.49
誰がいつから否定したんだよｗ
2013/06/11(火) 04:36:33.17
>>182
循環的複雑度を誤解してる奴と誤解を否定してる奴しか居ないな。
誤解が正しいと思ってる奴が誤解の否定を循環的複雑度自体への
否定として受け取りだすと話がこじれるから一遍否定している人のレスを読みなおしてみ。
2013/06/11(火) 06:10:44.14
否定のレスのおかげで弁証論的に循環的複雑度の理解は深まった
そんでレビューのネタ探す程度には使えるってのはわかった
ついでに循環的複雑度が使えるって言ってる奴がとことん使えない奴ってのもわかった
2013/06/11(火) 07:51:10.63
今気付いたが、循環的複雑度ってオイラーの多面体定理の公式にそっくりだね
2013/06/11(火) 08:44:01.08
循環的複雑度がソフトウェアメトリクスにおける銀の弾だと思っちゃったんだろうね。
2013/06/11(火) 10:04:22.68
品質評価の手法だから、コードを書く時に使おうとしてもあまり意味がない物だけど
普段理論武装してる奴が過剰な拒否反応を示すのは痛々しいな。
2013/06/11(火) 10:26:32.45
過剰な拒否反応？どのレス？
みんな、頓珍漢な俺理論を見逃せなかっただけ。
2013/06/11(火) 10:33:49.76
おかしな持論を曲げない奴が頑張るとスレが無駄にのびる。
おじゃばとか。
2013/06/11(火) 10:35:44.66
>>157が真理だと思うぞ
コードを書く時に意識するとか平均とか意味不明な事言ってるから突っ込まれる
2013/06/11(火) 21:19:29.46
だいたいいつもこんな流れ

ある手法が登場
↓
馬鹿：その手法は完璧じゃない！と否定する
↓
そもそも「ある手法」は完璧なんて誰も言っていない。
↓
馬鹿：完璧じゃないから、全く使えないと極論言い出す
↓
この手法がどういう時に使えて、どういう時に使えないのか説明する
↓
馬鹿：聞く耳持たない。
2013/06/11(火) 21:31:51.86
今回は逆パターンだけどね

馬鹿：ある手法をゴリ押し
↓
皆が間違ってるところを指摘。
↓
馬鹿：俺の理論は絶対なんだよ！指標にすべし！とゴリ押し継続
↓
誰も完全に否定してるわけじゃない。だがおかしなところもある。
といって説明する。
↓
馬鹿：否定する根拠を示せと言って人の説明をガン無視、聞く耳を持たない
2013/06/11(火) 21:58:29.83
>>193
逆じゃんｗ
結局間違ってなかったわけだから。
2013/06/11(火) 22:03:49.90
↓
分析する馬鹿が現れる
↓
それを煽る俺が現れる
2013/06/11(火) 22:11:13.27
否定していないというだけで、まるで全肯定でもしてるかのように
脳内変換されてしまう>>194の脳がとっても心配
2013/06/11(火) 22:26:01.86
もうその話題飽きたお
2013/06/11(火) 22:36:27.95
スレタイに相応しいことでも書くか。
シングルトンクラスのgetInstanceメソッドに引数をつけない。
2013/06/11(火) 22:47:53.12
職場でBGMはいいが歌は流すな
2013/06/11(火) 22:53:47.51
循環的複雑度を計測せよ
2013/06/11(火) 23:10:00.17
省力可能な引数作るな
関数名みたら使い方がわかる様に作れ
2013/06/11(火) 23:20:46.96
平均値馬鹿はいい加減あきらめろ
2013/06/11(火) 23:21:16.05
>>192-194
複合だろ。
1，有用性を認める奴
2，疑問視をしてる奴
3，全肯定してる馬鹿
4，全否定してる馬鹿
1や2だけなら多少野暮なツッコミや誤解もあるが概ね妥当な所に話が落ち着くのに、
3と4が発言すると全員に袋叩きにされ叩いてる3や4が次のネタ提供して無限ループになってる。

この手の議論こそIDがあれば1と3や2と4を混同した馬鹿な流れや3や4を無視して話ができるんだが…まぁ導入は無理なんだろうなぁ…
2013/06/11(火) 23:26:24.53
おじゃばの話題が終わった後は、全否定で突っ張る奴なんかいないだろ。
全否定されたと勘違いでもしてるのか？
2013/06/11(火) 23:29:11.44
循環的複雑度はもちろん効果はあるけど、
平均値をとっても意味は無い。
2013/06/11(火) 23:32:59.24
おかしな俺理論で誤りを認めない、そこそこアクティブな奴が全ての原因。
何日にも渡って表現を微妙に変えつつ同じことを何度も言う。
2013/06/11(火) 23:33:29.77
初めて来たんだけど、おじゃばって何？
聞くのやめといた方がいい話なら聞かないけど。
2013/06/12(水) 00:09:31.90
>>207
糞コテ。このスレ的には、スレでオナニーJava講義をおっぱじめてた馬鹿。
やってほしいことは俺の講義でを学ぶこと→ここに書くべきは俺のJava講義。
講義内容は…偉そうな勘違いJava土方の自慰行為と言った感じ。
講義の全部が全部間違ってるわけではないが、まじめに聞く価値はないだろうな。
2013/06/12(水) 00:54:24.24
>>198
それ最悪だなｗただのグローバル変数
2013/06/12(水) 01:15:28.87
オブジェクト指向の基礎も理解していないのに、
DIコンテナだのデザインパターンだの
言っている人がいたから、
ソースコード付きで基礎を教えて
あげたんだよ。
2013/06/12(水) 01:43:41.91
循環的複雑度をリファクタリングの
目安にすると言っているのか？
素人考えだな。
行が増えたから関数分割すると
いうのと変わらない。
初心者のうちは仕方ないが、
オブジェクト指向なら、複数の機能
（オブジェクト要素）が混じって
いないかで判断するべきだ。
2013/06/12(水) 01:52:42.10
久しぶりだなハゲ！
基礎できてないのに応用を覚えろって言うのはバカだけど、あの時はお前も結構会話かみ合ってなくて酷かったぞｗｗｗ

複雑度高いと多機能な関数になってること多いから、あながい間違いでもないと思うんだが。
数値下げるために分割したら目的見失ってるけどな。
2013/06/12(水) 01:57:28.89
>>208
サンクス。どのスレにも持論押しつけるバカはいるもんだな。
2013/06/12(水) 02:01:01.59
あ気付かなかった、この人かｗ
オナニーJavaであだ名がおじゃばかと思ったらそのものコテなのか。
ホント悪い、聞くのやめといた方が良かったみたいだ。
2013/06/12(水) 02:47:14.88
どうせ遅かれ早かれ湧いたんじゃねぇかな
ここまでレスしてなかった(コテつけ忘れてた)事が不思議な位
2013/06/12(水) 03:19:16.48
NG推奨
2013/06/12(水) 08:32:24.63
オナニーJavawww
2013/06/12(水) 10:26:59.50
呼んでないのに来ちゃったー
他のスレ散々荒らしてんだからそこで満足してくれよorz
2013/06/12(水) 10:29:22.66
おじゃばの話は何故か最後まで読んでしまう
1行目にトンチンカンなことが書いてなかったりするから

ただ最後まで読むと「で！？」ってなる
2013/06/12(水) 10:34:28.90
コード打つ時はオーケストラを流す
2013/06/12(水) 11:08:10.77
循環的複雑度を計測するソフトの導入が現実的ではない
循環的複雑度が低くなるように処理が分割された詳細設計書は
これじゃ全体的な動きがよくわからんで却下されるし
当然コーダーの裁量で仕様書にない関数を作るのもありえない
2013/06/12(水) 12:02:22.50
>>221
そういう環境にいる人は人間コードジェネレータなんだから
品質とか余計なことは考えなくていいんだよ
だから循環的複雑度の導入を検討する必要はないし、興味をもつ必要もない
プログラマじゃないんだからマ板に書き込むのも板違い
2013/06/12(水) 13:52:52.23
そういう完全にコーディングだけ！って人は黙って社畜になれよ
自分で設計してコーディングする開発者も増えてるんだから
2013/06/12(水) 14:45:24.16
くだらない数値測って悦に浸ってないで
最初から疎結合にしてドキュメントに書け糞コーダ―
2013/06/12(水) 20:30:29.25
>>209
それで内部の状態変わるんだよ。
いまどきシングルスレッドなんてそんなに無いからさ……
2013/06/12(水) 21:23:49.34
>>221
> 循環的複雑度を計測するソフトの導入が現実的ではない

なんで？ Perl、Ruby、JavaScriptは
それぞれその言語用のパッケージシステムから
普通にインストールするだけ。perlだったらcpan。

それだけでコマンドが使えるようになる。

Javaの場合はEclipseのプラグインを入れるだけ。
NetBeansを使ってるなら知らないが。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況