eeping huge
changes of things, at a pretty fine-grained level if it turns out that
they were a bad idea. You want to preserve existing functionality as far
as the user is concerned -- it's what the software is for.
Refactoring to tests helps start to create "executable docs", and helps
"Steven Staples" writes:
>> My monitor can also display about 55 lines of code, my functions are, on
>> average, just a few lines of code though -- a maximum of about 20, with an
>> average of around 5 or so.
>>
>> This is because the rule of thumb I follow is that a function should do
> one
>>
Lester Caine writes:
> Not directly a PHP problem, but since PHP tends to automatically create a
> session cookie I thought it appropriate to ask here first.
I don't know about the rest of your post, but you can easily turn off
this behavior if it's present (unless you are using a rather poor ho
Tedd Sperling writes:
> It would be an interesting survey to ask programmers to review their code and
> provide the average number of lines in their functions AND how many lines of
> code their monitor's can display. In other words, look at your editor; count
> the
> number of lines your monitor
On Wed, Feb 8, 2012 at 12:48 PM, Paul M Foster wrote:
> Um, yeah. It's very "meta".
>
> (That's what I love about "The C Programming Language". It's a little
> over half an inch thick in paperback, explains the whole language
> clearly and concisely, and has barely been revised since 1988. I'm not
On Sun, Oct 30, 2011 at 8:47 AM, Nam Gi VU wrote:
> It is convenient to have a trailing comma when defining an array - so as
> easy to add/remove code to add/remove an entry to the array
>
> array(
> 'key00' => 'value00',
> 'key01' => 'value01',
> 'key02' => 'value02',
> ...
> )
>
> I
On Sun, Oct 30, 2011 at 4:30 PM, Rick Dwyer wrote:
> Hello all.
>
> Not sure just how much of this is PHP related, but hoping someone has come
> across this before.
>
> I Google's webmaster tools for a site I work on, they list more than 100
> crawl errors for pages with URL's as follows:
>
> http
On Tue, Oct 4, 2011 at 9:25 PM, Tommy Pham wrote:
> There would be a difference in performance since the the expression has to
> be reevaluated, including the function FROM_BASE, every time versus one time
> evaluation of prepared statement.
This is true, but it should be pointed out that for a l
On Tue, Oct 4, 2011 at 8:15 PM, Tommy Pham wrote:
> On Tue, Oct 4, 2011 at 6:07 PM, Jeremiah Dodds
> wrote:
>>
>> On Tue, Oct 4, 2011 at 7:51 PM, Stuart Dallas wrote:
>> > As for the overhead I very much doubt there's much difference between
>> > tha
On Tue, Oct 4, 2011 at 8:10 PM, Stuart Dallas wrote:
> Prepared statements incur an additional hit against the DB server to prepare
> the statement.
But only once, right? This could, of course, still be a downside
depending the nature of your app.
--
PHP General Mailing List (http://www.php.ne
On Tue, Oct 4, 2011 at 7:51 PM, Stuart Dallas wrote:
> As for the overhead I very much doubt there's much difference between that
> and the overhead of prepared statements.
Probably not. As an aside, I'm really struggling to find a case where
it'd be worth base64-encoding the queries like that
On Tue, Oct 4, 2011 at 2:44 PM, Jim Giner wrote:
>
> I thought you were supposed to do an addslashes to protect your appl from
> malicious d/e.
>
To protect your app from malicious stuff going to SQL queries, you
should be using prepared statements, see
http://php.net/manual/en/pdo.prepared-stat
12 matches
Mail list logo
