元スレ【PHP】PHPフレームワーク総合スレ15
php覧 / PC版 / みんなの評価 : △
前へ
751 = :
PHP初心者じゃなくてFW初心者ってことなら
とりあえず情報量の多いCakePHPからやるのが無難だろうな。
まわりに詳しい人がいたらその人が使ってるFWでも良いと思う。
752 = :
地力の無い奴がフレームワークに手を出すと大抵コードが腐る。
まず大半の初級者は Model = DBテーブル と刷り込まれて、
正しいMVC分けが出来なくなり、Controllerが糞みたいに肥大化する。
普通に考えれば、別途ライブラリ(真の意味でモデルに該当するモノ)を構築すれば良いのだが、
それが出来ない。全部コントローラに記述しちゃう。
また大半のフレームワークではメソッドやコントローラアクションに関する粒度が規定されていない為、
1メソッドが糞みたいに長かったり、1コントローラに全ロジックが書かれたりする。
素人は一度は自作FWを作る経験をすべき。
753 = :
一度でいいけどな
モデルを理解したうえであらためてCake使うと
「ファーーーｗｗｗｗ よう考えられとんねーー」
と思うこと請け合い
754 = :
え？
cakeがよく考えられてることとはネタですか
755 = :
笑ってるから、馬鹿にしてるんでしょ
実際は笑えないことが多いんだけど
756 = :
cake激安レンタル鯖に入れたら重すぎて使う気起きなかったよｗ
757 = :
cakeなんか使うからｗ
758 = :
で、何がお勧めなの？
出来ればそれを選ぶメリットも一緒に
759 = :
ケースバイケースとしか言いようが無い。
FWのせいで効率が落ちる＆保守性が落ちるのは本末転倒なので好きなの選べばいい。
Cakeは開発グダグダだし、独自方言大杉で他FWに移行し辛いし、一緒に心中する覚悟が必要かな
最近だとIDEとの親和性も大事だね
760 = :
fuelPHPとか最近よく聞くけどどうなんだろう
761 = :
FuelPHP
CodeIgniter のライセンスの問題で話題になっただけで、
他と比べて特別何か優れてるわけでは無い
762 = :
＞IDEとの親和性も大事だね
俺もそう思う。
763 = :
もうこれほとんど生PHPだろ・・・ 超便利だけど・・・
というようなフレームワークってある？
764 = :
文句は出るがお勧めはないってのがさすがphp
765 = :
>>763
生PHP＝独自設定ファイルが不要という意味ならば、
Zendとかじゃね？フレームワークとしては微妙だけど、ライブラリとしてはまぁまぁ便利
>>764
どのFWも一長一短な上、無駄に種類が多いからね･･････
767 = :
>>759 >>762
IDEと親和性が高いフレームワークでオススメってある？
phpStorm使い始めたんだけど、コード補完が効かないと耐えられない体になってしまったよ
769 = :
CakePHPはプラグインあるよ
他もあると思うけど使わないから知らない
770 = :
NetBeansにCakeのプラグインあって入れたけど
結局素のPHPの部分しか、解釈してくれないようだ
コンポーネントの関数とかまで見つけてサジェストしてくれたら、最高なんだが
771 = :
ウェブ系って静的解析が難しい言語ばかりだからね。
実際に実行される直前になるまで
変数に入っている型がわからないなら
補完できなくて当然なわけで。
772 = :
>>771
＞実際に実行される直前になるまで
＞変数に入っている型がわからないなら
＞補完できなくて当然なわけで。
そう思っていた時期が俺にもありました。
が、最近のIDEはコードとコードコメントから中身を推察して、凄い精度で補完してくれるんだよ。
ただし、マジックメソッドを多用してたり、PHPコードでは無く文字列や設定ファイルを多用してると、流石に無理でCakeは相性が悪い。
773 = :
コメントから中身を推察ってすげえな。本当にできるの？
775 = :
>>773
出来るどころか、その逆、コードを解析してコメント入力の補完までしてくれるよ。
以下のメソッドがあるとする。
function getHoge($a = 1) {
return new Hoge($a)
}
1. コードから型を推察する
$a = getHoge(); // $a はHogeインスタンスとして認識される
$a->xxxxx; // $a-> と入力すると xxxxx が補完される
2. コードからコメントを補完
/** と打つと、以下のコメントひな形を自動入力してくれる。
この @return にメソッドが返すべき型を指定すると、IDEはそれを認識する。
(@returnが無くても上記のコード推察機能は動く)
/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)
776 = :
言語の欠陥をコメントで補ってる系
777 = :
>>776
アノテーションってご存じですか？
778 = :
間違いなく言語の欠陥
779 = :
型付けが無いメリットとデメリットのうち、デメリットだけをアノテーションで解決出来るとかどこの神言語だよ
780 = :
変数の型をコメントで指定するぐらいなら、
普通に変数に型を書いたほうが
見やすいと思うよｗ
783 = :
DRYの原則からすると、
/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)
$aを二回書くのは無駄でしか無いね。
もっと言えば@paramも無駄だし@returnも無駄。
こんな感じでコメントを書く場所が厳密に決まっていて
同じ事を二回書かなくて済む言語出来ないかねぇ。
// 関数と戻り値のコメントを書く。
function Hoge getHoge(
int value, // ここに引数のコメントを書く
string str, // ここに引数のコメントを書く
) {
・・・
}
valueが@paramなのは自明だし型も自明
784 = :
アノテーションがどういう物か判ってて書いてるんだろか
DRYが何か判ってて書いてるんだろか
読んでるこっちが恥ずかしくなるわ
785 = :
そう言葉を残すだけで
反論はできないのであった
完でいい？
786 = :
>>780
変数に対する型指定アノテーションも存在するよ
厳密に型指定したいならPHP以外を使えば良いんじゃね？
>>783
コメントは別に「型」を記載する為だけのものじゃないからね。
あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ
＞コメントを書く場所が厳密に決まっていて
うん。それがphpdocだ。
C～C#、Javaあたりのソース読んでみ同じような事してるよ
787 = :
> あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ
長文になる時は別の書き方を用意すればいいだけの話。
// 関数と戻り値のコメントを書く。
// [*1] : 長いコメント
// [*2] : 長いコメント
function Hoge getHoge(
int value, // 短いコメント [*1]
string str, // 短いコメント [*2]
) {
・・・
}
重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
コードとドキュメントの整合性が取れなくなるのは、これが理由。
788 = :
>>786
> 変数に対する型指定アノテーションも存在するよ
いや、だから型指定アノテーション＝型指定でしょ？
789 = :
>>787
君が言いたい事はわかるが、とうの昔に多言語で実装されている。
・MS系(VB/C/C#)のドキュメントコメント
・Java系のjavadoc
・ECMAScript(JS/AS/etc)のコメント
phpdocはそれに倣っただけだ。
あとアノテーションについて学べ。まずはそこからだ。
＞重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
IDEが自動で変えてくれる。
＞コードとドキュメントの整合性が取れなくなるのは、これが理由。
整合性がとれなくなるのは、開発者が無知だからであって、言語のせいでは無いよ。
＞長文になる時は別の書き方を用意すればいいだけの話。
長いコメントと短いコメントの記載場所が2箇所に別れちゃうんだｗ
で、長いコメント書く場合の改行やパラメータの区切りはどうすんの？ @param とか明示的な文法が必要じゃね？
790 = :
>>789
ドキュメントコメントってこれ？
http://msdn.microsoft.com/ja-jp/library/8cw818w8(v=vs.90).aspx
俺の方法では不要なparamが使われている。
Int1という名前が二回出てきている。
javadoc もECMAScriptのコメントも同じ。
> IDEが自動で変えてくれる。
IDE使わないときはどうすんの？
791 = :
> 長いコメントと短いコメントの記載場所が2箇所に別れちゃうんだｗ
> で、長いコメント書く場合の改行やパラメータの区切りはどうすんの？ @param とか明示的な文法が必要じゃね？
短い時に短くかけるのがメリット。
たいていは短いのだから
多くのものを短く出来るのはいいことだ。
792 = :
>>788
＞型指定アノテーション＝型指定
違う。「言語」としての型指定では無い、所詮はただのコメント文。
コメントにルールと意味を含める事で、言語を拡張するイメージだよ。
最近ならAndroid系のソースコード読めばアノテーションの存在意義が理解しやすいよ。
ピュアなJavaコードなんだけど、Android独自文法を実現している。
793 = :
>>791
＞たいていは短いのだから、多くのものを短く出来るのはいいことだ。
答えになっていない。
長いコメントの区切りはどうするの？
パラメータの順番が変わったらどうするの？
お前、まともにとリファレンスコメント書いた事ないだろ。
＞IDE使わないときはどうすんの？
IDEの為にアノテーション使おうって話なんだが？
794 = :
僕の考えた最強のコメントルールってやつだな･･････ｗ
独自フレームワークより害悪だわ
796 = :
>>793
> 長いコメントの区切りはどうするの？
[*1]って書いてるじゃんｗ
> パラメータの順番が変わったらどうするの？
変わってなにか困るの？
797 = :
>>796
[*1]とか[*2]は無いｗｗ
@param $var の方が良いわｗ
＞＞パラメータの順番が変わったらどうするの？
＞変わってなにか困るの？
>> 787 で
＞重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
[*1] だと数字を全て書き換える必要があるよね？
(書き換えないのであれば、相当可読性落ちる)
何より長文と短文を紐付ける [*1] が人的管理とかねぇわｗ
試しにそのコメント処理パーサ実装してみ？
798 = :
引数と戻り値の言及ばかりで、
@see / @author / @todo / @throw あたりを考慮してない時点で察してやれよ･･････
コメント文をまともに書いた事も、ドキュメントを作成した事も無いんだよ･･････
799 = :
>>783 で
＞ $aを二回書くのは無駄でしか無いね。
と言っているのに >>787 では
$aの代わりに [*1] を二回書いているというねｗ
800 = :
> [*1] だと数字を全て書き換える必要があるよね？
> (書き換えないのであれば、相当可読性落ちる)
書き換えなきゃいいじゃんｗ
可読性？ 落ちない落ちないｗ
> 試しにそのコメント処理パーサ実装してみ？
なんか難しいの？ｗ
http://kojika17.com/2013/01/starting-markdown.html
> I get 10 times more traffic from [Google] [1] than from
> [Yahoo] [2] or [MSN] [3].
>
> [1]:http://google.com/ "Google"
> [2]:http://search.yahoo.com/ "Yahoo Search"
> [3]:http://search.msn.com/ "MSN Search"
みんなの評価 : △
php一覧へ類似してるかもしれないスレッド
- 【PHP】PHPフレームワーク総合スレ14 (1001) - [97%] - 2010/12/11 10:32
- 【PHP】フレームワークPharonスレ (306) - [75%] - 2022/10/10 20:00
- 【PHP】フレームワークMapleに舌鼓 (470) - [62%] - 2017/12/31 9:31
- 【PHP】フレームワーク Akelos (129) - [59%] - 2019/5/9 7:46
- 2ch有志がPHPフレームワークを作るスレ (81) - [55%] - 2019/5/9 7:46
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [53%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [53%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [53%] - 2022/6/6 19:30
トップメニューへ / →のくす牧場書庫について