私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】下らねぇ質問はID出して書き込みやがれ 139
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
検証したコードも出さずに勝手な妄想垂れてる馬鹿には関わらなくていいよ
defined()を使う
issetは使えないし、下手に値を見て識別……とかしたら、お約束どおりにその名前の変数と解釈してその後文字列値と解釈して……となる
issetは使えないし、下手に値を見て識別……とかしたら、お約束どおりにその名前の変数と解釈してその後文字列値と解釈して……となる
APCや共有メモリ関数ができるけど
どちらかというとファイル操作を共有メモリ操作に置き換えたかたちであって
fpmの同一のプロセスでもしくは別々のプロセスで配列やオブジェクトを保持し続ける感じのものではない
f(ast)cgiまわりやphp-fpmあたりではそういった機能は提供してない、だと思う
元々fastcgi等の目的はメモリの維持ではなくプロセス起動やコンパイルのオーバーヘッドを減らす・無くすこと
どちらかというとファイル操作を共有メモリ操作に置き換えたかたちであって
fpmの同一のプロセスでもしくは別々のプロセスで配列やオブジェクトを保持し続ける感じのものではない
f(ast)cgiまわりやphp-fpmあたりではそういった機能は提供してない、だと思う
元々fastcgi等の目的はメモリの維持ではなくプロセス起動やコンパイルのオーバーヘッドを減らす・無くすこと
1か2でいいんじゃね
!!HOGE === FALSEとかならまだわかるけど3はおかしい
!!HOGE === FALSEとかならまだわかるけど3はおかしい
HOGEを間違えて定数ではなく文字列'HOGE'と書いてしまった場合
HOGEを間違えて定数ではなく変数$HOGEと書いてしまった場合
またHOGEをHAGEと書いてしまった場合(※Noticeが出る)、さらに、$HAGEと書いてしまった場合
この辺を考えて、どういう動作を期待してるのか考慮のうえで選べば良いんじゃないかな
とりあえず[1]はちょっと危ない、設定値を考えると[2]辺りが妥当(あとからソースみたときに設定値との比較で理解もしやすい)、
[3]は……型変換が入ってfalseになってしまって欲しいか否か、個人的にはおすすめしない
HOGEを間違えて定数ではなく変数$HOGEと書いてしまった場合
またHOGEをHAGEと書いてしまった場合(※Noticeが出る)、さらに、$HAGEと書いてしまった場合
この辺を考えて、どういう動作を期待してるのか考慮のうえで選べば良いんじゃないかな
とりあえず[1]はちょっと危ない、設定値を考えると[2]辺りが妥当(あとからソースみたときに設定値との比較で理解もしやすい)、
[3]は……型変換が入ってfalseになってしまって欲しいか否か、個人的にはおすすめしない
なお、間違えて 0 を O と書いてしまう場合もあるから(実際にたまに見る)
2値でいいならそもそも定義自体をtrue / falseにするほうがいいとは思う
2値でいいならそもそも定義自体をtrue / falseにするほうがいいとは思う
>>771
テスト・デバッグのときは行わない処理を入れたい(テスト時はDBへの書き込みしないとか?)
そこでテスト・デバッグ時は代わりに行う処理がない、というとき
これが正も逆もあるようなめんどくさい状況だと使わざるを得ない
あとは、elseを使わないifみたいな条件判定としては、try、catch、の後で何か処理したいときとか
tryの中に大筋で2パターンの処理に分かれてて、どっちでException投げてきたのかわからない、
値をチェックしてどっちの状況でも適合するように準備とか
テスト・デバッグのときは行わない処理を入れたい(テスト時はDBへの書き込みしないとか?)
そこでテスト・デバッグ時は代わりに行う処理がない、というとき
これが正も逆もあるようなめんどくさい状況だと使わざるを得ない
あとは、elseを使わないifみたいな条件判定としては、try、catch、の後で何か処理したいときとか
tryの中に大筋で2パターンの処理に分かれてて、どっちでException投げてきたのかわからない、
値をチェックしてどっちの状況でも適合するように準備とか
もう設計・書き方のやりかたと可読性の話題であって
on/offスイッチがoffの時だけやりたい処理とは何かの質問じゃないな
さらに元の話題は定数定義のやりかた・条件分岐の正確性の問題だ
例外処理だって、例外処理をどのように設計し組むかはもはや哲学
例えばtry入れ子をどう考えるかひとつとっても非常に深い問題だ
on/offスイッチがoffの時だけやりたい処理とは何かの質問じゃないな
さらに元の話題は定数定義のやりかた・条件分岐の正確性の問題だ
例外処理だって、例外処理をどのように設計し組むかはもはや哲学
例えばtry入れ子をどう考えるかひとつとっても非常に深い問題だ
追記
計算コストが変わらずコーディング規約の縛りがないなら
可読性を重視するかどうかも含めて好きに選べば良い好みの問題だと思う
個人的には、単独ブロックの使い道かと思ったら可読性の話題になってて後出しに見えるがな
計算コストが変わらずコーディング規約の縛りがないなら
可読性を重視するかどうかも含めて好きに選べば良い好みの問題だと思う
個人的には、単独ブロックの使い道かと思ったら可読性の話題になってて後出しに見えるがな
可読性が失われる上に意図を汲みにくいコードを選択する理由は無いと思うんだけど。
on/offスイッチがオフのときだけやりたい処理は今のところ出てないような。
まぁ、本来の話で言うなら、そもそもHOGEが肯定形のスイッチなのかどうかがまず一つ。
否定形のスイッチであるなら、意味を逆にするべきだと思う。
その上で、if (!HOGE) {} ではなく、if (HOGE) {}となるようにしたほうがよいだろうというのが提案。
on/offスイッチがオフのときだけやりたい処理は今のところ出てないような。
まぁ、本来の話で言うなら、そもそもHOGEが肯定形のスイッチなのかどうかがまず一つ。
否定形のスイッチであるなら、意味を逆にするべきだと思う。
その上で、if (!HOGE) {} ではなく、if (HOGE) {}となるようにしたほうがよいだろうというのが提案。
書きやすさ、好み、先例、コーディング規約
さらにいずれの書き方が可読性の面で
より良いものかは統一的な見解はありえない
offの時だけやりたい処理なら
例えばDEBUG_LEVELを指定しておいてレベルごとに詳しく書く
他方DEBUG_LEVEL===0&&何かエラー発生なら最後の最後で警告文を出す
こんなやり方でも絶対こう書かねばならない必要性は存在しないか
存在していても簡単にこうと説明できないだろうし不自然・おかしいといくらでも評論できる
さらにいずれの書き方が可読性の面で
より良いものかは統一的な見解はありえない
offの時だけやりたい処理なら
例えばDEBUG_LEVELを指定しておいてレベルごとに詳しく書く
他方DEBUG_LEVEL===0&&何かエラー発生なら最後の最後で警告文を出す
こんなやり方でも絶対こう書かねばならない必要性は存在しないか
存在していても簡単にこうと説明できないだろうし不自然・おかしいといくらでも評論できる
> 0 1 2 と値を持つような状態フラグの話
0 1 2と値を持つなら、それはフラグじゃなくてステータスです。
0 1 2と値を持つなら、それはフラグじゃなくてステータスです。
すんげー下らないんだけど
何らかの日本語対応文字コードで記述されている長さ不明の文字列を
単純なサイズ (~~~bytes) 指定で文字列長の上限を設けるかたちで途中で切ることを考えるとき
単純にsubstrで切るとマルチバイト文字の途中で切れるかもしれない、mb_substrで切るとbytesで切れない、
Shift_JISやEUCは2bytesだけどUTF-8などは3bytesと違いがある
やはり、泥臭くても
文字コード判定→マルチバイト文字の長さ n を取得→
指定サイズで切ったあと最後から n bytes分取ってmb_detect_encodingとかにかける→
失敗したら切る場所を指定サイズから1文字少なくしてリトライ
ってやるか、それか文字コード完全決め打ちして少し処理軽減するくらいしかないのだろうか?
何らかの日本語対応文字コードで記述されている長さ不明の文字列を
単純なサイズ (~~~bytes) 指定で文字列長の上限を設けるかたちで途中で切ることを考えるとき
単純にsubstrで切るとマルチバイト文字の途中で切れるかもしれない、mb_substrで切るとbytesで切れない、
Shift_JISやEUCは2bytesだけどUTF-8などは3bytesと違いがある
やはり、泥臭くても
文字コード判定→マルチバイト文字の長さ n を取得→
指定サイズで切ったあと最後から n bytes分取ってmb_detect_encodingとかにかける→
失敗したら切る場所を指定サイズから1文字少なくしてリトライ
ってやるか、それか文字コード完全決め打ちして少し処理軽減するくらいしかないのだろうか?
>>783
うわーお知らなかった・・・教えて下さってありがとうございます
やっぱ泥臭くやるしかないですよね
こういう処理が必要なケースを考えると裏の管理用のログ吐き等に限らないし
まだ出くわしてないけど検索結果の一部表示とか出来たらサイズで指定したい場合とかありそうだ
うわーお知らなかった・・・教えて下さってありがとうございます
やっぱ泥臭くやるしかないですよね
こういう処理が必要なケースを考えると裏の管理用のログ吐き等に限らないし
まだ出くわしてないけど検索結果の一部表示とか出来たらサイズで指定したい場合とかありそうだ
>>785
二度と来るな
二度と来るな
>>789
一応確認だけど、そのゴミってPHPをさしてるの?
一応確認だけど、そのゴミってPHPをさしてるの?
解像度でデザイン変えたりも出来るし、widthが%指定だったりするとあてにならないし、
無指定の場合のボーダー幅やtextareaのサイズなんかもブラウザによりけりだから誤差が出る。
ページの両脇全面に貼られてる広告領域をどうするかとか基準づくりも必要。
ソースコードやスタイルシートを解析する手法だとページによっては可能。
環境(解像度、OS)を指定して実際にその環境で開いてキャプチャーしたものを画像解析なら幅広く対応可能。
探せばありそうな部分的に作業を助けてくれるサードパーティー製ツールがあるとしても、
どっちもそれなりにスキルが必要で難しい作業になると思うが。
無指定の場合のボーダー幅やtextareaのサイズなんかもブラウザによりけりだから誤差が出る。
ページの両脇全面に貼られてる広告領域をどうするかとか基準づくりも必要。
ソースコードやスタイルシートを解析する手法だとページによっては可能。
環境(解像度、OS)を指定して実際にその環境で開いてキャプチャーしたものを画像解析なら幅広く対応可能。
探せばありそうな部分的に作業を助けてくれるサードパーティー製ツールがあるとしても、
どっちもそれなりにスキルが必要で難しい作業になると思うが。
レンダリングエンジンを外部から利用する方法以外はやめといたほうがいいかと。
見る側に左右されるとかそんなこと以前に
ページの幅なんか取得できて何が嬉しいの?
ページの幅なんか取得できて何が嬉しいの?
Webページをキャプチャするプログラムが世の中にゴロゴロあるだろ
そのソース見てこい
そのソース見てこい
>>799
開くな危険
開くな危険
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- 【PHP】下らねぇ質問はID出して書き込みやがれ 133 (1001) - [98%] - 2014/7/8 16:30
- 【PHP】下らねぇ質問はID出して書き込みやがれ 138 (991) - [98%] - 2015/1/6 8:00
- 【PHP】下らねぇ質問はID出して書き込みやがれ 136 (936) - [98%] - 2014/9/18 12:45
- 【PHP】下らねぇ質問はID出して書き込みやがれ 135 (984) - [98%] - 2014/8/7 1:00
- 【PHP】下らねぇ質問はID出して書き込みやがれ 134 (1002) - [98%] - 2014/7/29 4:15
- 【PHP】下らねぇ質問はID出して書き込みやがれ 132 (1000) - [98%] - 2014/6/18 20:58
- 【PHP】下らねぇ質問はID出して書き込みやがれ 131 (1001) - [98%] - 2014/1/19 21:30
- 【PHP】下らねぇ質問はID出して書き込みやがれ 130 (1001) - [98%] - 2013/11/11 2:45
- 【PHP】下らねぇ質問はID出して書き込みやがれ 129 (1001) - [98%] - 2013/9/18 1:45
- 【PHP】下らねぇ質問はID出して書き込みやがれ 137 (995) - [98%] - 2023/1/30 18:45
- 【PHP】下らねぇ質問はID出して書き込みやがれ 119 (1001) - [98%] - 2012/6/21 11:46
- 【PHP】下らねぇ質問はID出して書き込みやがれ 109 (1001) - [98%] - 2011/8/30 2:02
- 【PHP】下らねぇ質問はID出して書き込みやがれ 125 (1001) - [96%] - 2013/2/4 13:30
- 【PHP】下らねぇ質問はID出して書き込みやがれ 126 (1001) - [96%] - 2013/3/19 13:15
- 【PHP】下らねぇ質問はID出して書き込みやがれ 112 (1001) - [96%] - 2011/11/29 4:02
- 【PHP】下らねぇ質問はID出して書き込みやがれ 128 (1001) - [96%] - 2013/8/4 14:01
- 【PHP】下らねぇ質問はID出して書き込みやがれ 111 (1001) - [96%] - 2011/10/30 20:31
トップメニューへ / →のくす牧場書庫について