Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #17908 > unrolled thread

How do you handle debug code? Removing from production versus conditional execution

Back to article view | Back to comp.lang.php

Contents

  How do you handle debug code? Removing from production versus conditional execution Ryan <rbilesky@gmail.com> - 2019-05-02 18:00 -0700
    Re: How do you handle debug code? Removing from production versus conditional execution "J.O. Aho" <user@example.net> - 2019-05-03 06:52 +0200
      Re: How do you handle debug code? Removing from production versus conditional execution bm <bm.tempo999@gémail.com> - 2019-05-09 01:31 +0000
    Re: How do you handle debug code? Removing from production versus conditional execution Martin Gregorie <martin@mydomain.invalid> - 2019-05-03 08:18 +0000
      Re: How do you handle debug code? Removing from production versus conditional execution Martin Gregorie <martin@mydomain.invalid> - 2019-05-03 08:22 +0000
    Re: How do you handle debug code? Removing from production versus conditional execution Arno Welzel <usenet@arnowelzel.de> - 2019-05-03 13:59 +0200
      Re: How do you handle debug code? Removing from production versus conditional execution Jerry Stuckle <jstucklex@attglobal.net> - 2019-05-03 09:38 -0400
    Re: How do you handle debug code? Removing from production versus conditional execution bm <bm.tempo999@gémail.com> - 2019-05-09 01:33 +0000
    Re: How do you handle debug code? Removing from production versus conditional execution Angle <angleaaaaaaa@zohomail.eu> - 2023-04-22 22:06 -0700
      Re: How do you handle debug code? Removing from production versus conditional execution doctor@doctor.nl2k.ab.ca (The Doctor) - 2023-04-23 12:03 +0000
        Re: How do you handle debug code? Removing from production versus conditional execution legalize+jeeves@mail.xmission.com (Richard) - 2023-04-24 17:50 +0000
          Re: How do you handle debug code? Removing from production versus conditional execution Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-04-24 14:27 -0400

#17908 — How do you handle debug code? Removing from production versus conditional execution

Perhaps an age old question, but how do you all deal with your debug code?  Do you remove it before deploying to production, if so how do you make sure you remove it all without removing something important that will break your code?  Or do you use conditional execution such as:

if ($_ENV['DEGUG'] == true) {
    var_dump($data);
}

If so what condition are you using?  An environment variable like above, a constant defined elsewhere in a config file?

I think conditional execution would be easier but question if having to check if the debug code can run would slow down a production server, but the question is how much overhead really does it take to check $_ENV or a constant...

So I am curious to see how others deal with this.

[toc] | [next] | [standalone]

#17909

On 03/05/2019 03.00, Ryan wrote:
> Perhaps an age old question, but how do you all deal with your debug code?  Do you remove it before deploying to production, if so how do you make sure you remove it all without removing something important that will break your code?

Debug code can be good to keep for later us.


>  Or do you use conditional execution such as:
> 
> if ($_ENV['DEGUG'] == true) {
>      var_dump($data);
> }

Except don't display the debug data on the page, always log it to a file 
as the system log.


> If so what condition are you using?  An environment variable like above, a constant defined elsewhere in a config file?

I tend to use a configuration value.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#17914

Le Fri, 03 May 2019 06:52:13 +0200, J.O. Aho a écrit :

> On 03/05/2019 03.00, Ryan wrote:
>> Perhaps an age old question, but how do you all deal with your debug
>> code?  Do you remove it before deploying to production, if so how do
>> you make sure you remove it all without removing something important
>> that will break your code?
> 
> Debug code can be good to keep for later us.
> 
> 
>>  Or do you use conditional execution such as:
>> 
>> if ($_ENV['DEGUG'] == true) {
>>      var_dump($data);
>> }
> 
> Except don't display the debug data on the page, always log it to a file
> as the system log.
> 
> 
>> If so what condition are you using?  An environment variable like
>> above, a constant defined elsewhere in a config file?
> 
> I tend to use a configuration value.


I have no "debug code", the debugging phase is made with debugger like 
Xdebug. I have "test code" which is covering some unit tests and 
functional tests but I store them in specific files (and not in files for 
production).

Therefore I cannot speak about how much overhead it take because my way 
of building apps avoid to encounter them.

bm

[toc] | [prev] | [next] | [standalone]

#17910

On Thu, 02 May 2019 18:00:22 -0700, Ryan wrote:

> Perhaps an age old question, but how do you all deal with your debug
> code?  Do you remove it before deploying to production, if so how do you
> make sure you remove it all without removing something important that
> will break your code?  Or do you use conditional execution such as:
> 
> if ($_ENV['DEGUG'] == true) {
>     var_dump($data);
> }
> 
> If so what condition are you using?  An environment variable like above,
> a constant defined elsewhere in a config file?
> 
> I think conditional execution would be easier but question if having to
> check if the debug code can run would slow down a production server, but
> the question is how much overhead really does it take to check $_ENV or
> a constant...
> 
> So I am curious to see how others deal with this.

My debug output: tracing statements, Warning: msg and Error: msg (which 
stops the run) are all localised in a ReportError diagnostic class which 
accepts a debugging level (0=no tracing o/p, +ve values enable 
progressively more o/p).

The debug level defaults to zero and can be set, via the setDebug() 
method, in any way that seems suitable for the process being debugged, 
i.e. from a command line option, via a configuration file, .... 

Each trace() method has the triggering debug level as its first argument. 
while warning() and error() methods are always active.

I always leave this in production code on the grounds that input can 
differ from what the system spec required so the ability to enable 
debugging in a production environment can be very useful. In practice the 
overhead seems to be minimal. 

ReportError also implements a circular buffer for trace messages - the 
number of messages it holds is configurable. This is very useful when 
you're trying to diagnose a once a day/once a week problem in a process 
that runs 24/7. A buffer dumps are triggered by calls on the warning() 
and error() methods - the buffer content immediately preceeds the warning 
or error message. Experience says that a straight stackdump only tells 
you where the fault is, but not what triggered it - hence the circular 
buffer, which holds that information.

In my implementation all output is to stderr, but it would be equally 
easy to configurably interface something like this to your favourite 
message logging package.
 

-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#17911

On Fri, 03 May 2019 08:18:23 +0000, Martin Gregorie wrote:

> On Thu, 02 May 2019 18:00:22 -0700, Ryan wrote:
> 
>> Perhaps an age old question, but how do you all deal with your debug
>> code?  Do you remove it before deploying to production, if so how do
>> you make sure you remove it all without removing something important
>> that will break your code?  Or do you use conditional execution such
>> as:
>> 
>> if ($_ENV['DEGUG'] == true) {
>>     var_dump($data);
>> }
>> 
>> If so what condition are you using?  An environment variable like
>> above,
>> a constant defined elsewhere in a config file?
>> 
>> I think conditional execution would be easier but question if having to
>> check if the debug code can run would slow down a production server,
>> but the question is how much overhead really does it take to check
>> $_ENV or a constant...
>> 
>> So I am curious to see how others deal with this.
> 
> My debug output: tracing statements, Warning: msg and Error: msg (which
> stops the run) are all localised in a ReportError diagnostic class which
> accepts a debugging level (0=no tracing o/p, +ve values enable
> progressively more o/p).
> 
> The debug level defaults to zero and can be set, via the setDebug()
> method, in any way that seems suitable for the process being debugged,
> i.e. from a command line option, via a configuration file, ....
> 
> Each trace() method has the triggering debug level as its first
> argument.
> while warning() and error() methods are always active.
> 
> I always leave this in production code on the grounds that input can
> differ from what the system spec required so the ability to enable
> debugging in a production environment can be very useful. In practice
> the overhead seems to be minimal.
> 
> ReportError also implements a circular buffer for trace messages - the
> number of messages it holds is configurable. This is very useful when
> you're trying to diagnose a once a day/once a week problem in a process
> that runs 24/7. A buffer dumps are triggered by calls on the warning()
> and error() methods - the buffer content immediately preceeds the
> warning or error message. Experience says that a straight stackdump only
> tells you where the fault is, but not what triggered it - hence the
> circular buffer, which holds that information.
> 
> In my implementation all output is to stderr, but it would be equally
> easy to configurably interface something like this to your favourite
> message logging package.

In my case this this stuff is implemented in both C and Java, but the 
approach should be applicable to almost any programming or scripting 
language: in PHP you probably would not need the circular buffer.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#17912

On 03.05.19 03:00, Ryan wrote:

> Perhaps an age old question, but how do you all deal with your debug
> code?  Do you remove it before deploying to production, if so how do
> you make sure you remove it all without removing something important
> that will break your code?  Or do you use conditional execution such
> as:
> 
> if ($_ENV['DEGUG'] == true) { var_dump($data); }
> 
> If so what condition are you using?  An environment variable like
> above, a constant defined elsewhere in a config file?
> 
> I think conditional execution would be easier but question if having
> to check if the debug code can run would slow down a production
> server, but the question is how much overhead really does it take to
> check $_ENV or a constant...
> 
> So I am curious to see how others deal with this.

I don't add "debug code" at all. I use a Debugger like xdebug which is
supported in Visual Studio Code, PHPStorm etc.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17913

On 5/3/2019 7:59 AM, Arno Welzel wrote:
> On 03.05.19 03:00, Ryan wrote:
> 
>> Perhaps an age old question, but how do you all deal with your debug
>> code?  Do you remove it before deploying to production, if so how do
>> you make sure you remove it all without removing something important
>> that will break your code?  Or do you use conditional execution such
>> as:
>>
>> if ($_ENV['DEGUG'] == true) { var_dump($data); }
>>
>> If so what condition are you using?  An environment variable like
>> above, a constant defined elsewhere in a config file?
>>
>> I think conditional execution would be easier but question if having
>> to check if the debug code can run would slow down a production
>> server, but the question is how much overhead really does it take to
>> check $_ENV or a constant...
>>
>> So I am curious to see how others deal with this.
> 
> I don't add "debug code" at all. I use a Debugger like xdebug which is
> supported in Visual Studio Code, PHPStorm etc.
> 
> 

Ditto here.  I find it to be much easier to find and fix bugs with a 
debugger than debugging code.  And xdebug does a good job.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17915

Le Thu, 02 May 2019 18:00:22 -0700, Ryan a écrit :

> Perhaps an age old question, but how do you all deal with your debug
> code?  Do you remove it before deploying to production, if so how do you
> make sure you remove it all without removing something important that
> will break your code?  Or do you use conditional execution such as:
> 
> if ($_ENV['DEGUG'] == true) {
>     var_dump($data);
> }
> 
> If so what condition are you using?  An environment variable like above,
> a constant defined elsewhere in a config file?
> 
> I think conditional execution would be easier but question if having to
> check if the debug code can run would slow down a production server, but
> the question is how much overhead really does it take to check $_ENV or
> a constant...
> 
> So I am curious to see how others deal with this.


I have no "debug code", the debugging phase is made with debugger like 
Xdebug. I have "test code" which is covering some unit tests and 
functional tests but I store them in specific files (and not in files for 
production).

Therefore I cannot speak about how much overhead it take because my way of 
building apps avoid to encounter them.

bm

[toc] | [prev] | [next] | [standalone]

#19445

You know how stupid You look ? It is absolutely beyond belief !!!!!!!!!!!!!!!



On Friday, May 3, 2019 at 3:00:29 AM UTC+2, Ryan wrote:
> Perhaps an age old question, but how do you all deal with your debug code? Do you remove it before deploying to production, if so how do you make sure you remove it all without removing something important that will break your code? Or do you use conditional execution such as: 
> 
> if ($_ENV['DEGUG'] == true) { 
> var_dump($data); 
> } 
> 
> If so what condition are you using? An environment variable like above, a constant defined elsewhere in a config file? 
> 
> I think conditional execution would be easier but question if having to check if the debug code can run would slow down a production server, but the question is how much overhead really does it take to check $_ENV or a constant... 
> 
> So I am curious to see how others deal with this.

[toc] | [prev] | [next] | [standalone]

#19446

In article <c028adea-b315-4ba3-8f93-a44b6a097630n@googlegroups.com>,
Angle  <angleaaaaaaa@zohomail.eu> wrote:
>You know how stupid You look ? It is absolutely beyond belief !!!!!!!!!!!!!=
>!!
>
>
>
>On Friday, May 3, 2019 at 3:00:29=E2=80=AFAM UTC+2, Ryan wrote:
>> Perhaps an age old question, but how do you all deal with your debug code=
>? Do you remove it before deploying to production, if so how do you make su=
>re you remove it all without removing something important that will break y=
>our code? Or do you use conditional execution such as:=20
>>=20
>> if ($_ENV['DEGUG'] =3D=3D true) {=20
>> var_dump($data);=20
>> }=20
>>=20
>> If so what condition are you using? An environment variable like above, a=
> constant defined elsewhere in a config file?=20
>>=20
>> I think conditional execution would be easier but question if having to c=
>heck if the debug code can run would slow down a production server, but the=
> question is how much overhead really does it take to check $_ENV or a cons=
>tant...=20
>>=20
>> So I am curious to see how others deal with this.

This abusive spamtroll came from

comp.lang.php #168037
X-Received: by 2002:ac8:7d94:0:b0:3e6:970e:a405 with SMTP id c20-
+           20020ac87d94000000b003e6970ea405mr3339752qtd.6.1682226412762;
+           Sat, 22 Apr 2023 22:06:52 -0700 (PDT)
X-Received: by 2002:a05:620a:1006:b0:74e:4504:46da with SMTP id
+           z6-20020a05620a100600b0074e450446damr614083qkj.11.1682226412602;
+           Sat, 22 Apr
+           2023 22:06:52 -0700 (PDT)
Path: news.nk.ca!news.quux.org!1.us.feeder.erje.net!3.us.feeder.erje.net!
+     feeder.erje.net!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-
+     out.google.com!nntp.google.com!postnews.google.com!google-groups.
+     googlegroups.com!not-for-mail
Newsgroups: comp.lang.php
Date: Sat, 22 Apr 2023 22:06:52 -0700 (PDT)
In-Reply-To: <a2740b73-91c2-4002-9573-d0204fe2bec7@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=82.131.76.206;
+               posting-account=JYCD-AoAAABJjYHTEug7bzEvKBag4Jpy
NNTP-Posting-Host: 82.131.76.206
References: <a2740b73-91c2-4002-9573-d0204fe2bec7@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c028adea-b315-4ba3-8f93-a44b6a097630n@googlegroups.com>
Subject: Re: How do you handle debug code? Removing from production versus
+        conditional execution
From: Angle <angleaaaaaaa@zohomail.eu>
Injection-Date: Sun, 23 Apr 2023 05:06:52 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 23
Xref: news.nk.ca comp.lang.php:168037


Spamtrollers are trolls posting useless spam thinking it is content
but are posting useless noise. Spamtrolls are newsgroup vandals!
Thoses trolls are as bad as Donald 
Trump on Twitter.

This makes
https://groups.google.com/search/conversations?q=Depeer%20Google%20Groups

Depeer Google groups Now!!

Spamtroller   , thou art rebuked in the Name of Yahweh the Father, 
Jesus the Son and the Holy Spirit for Jesus has all authority here
and Satan has no authority here!
-- 
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
We are running a marathon we cannot win when we hide ourselves from who we are. -unknown Beware https://mindspring.com

[toc] | [prev] | [next] | [standalone]

#19449

[Please do not mail me a copy of your followup]

doctor@doctor.nl2k.ab.ca (The Doctor) spake the secret code
<u236qf$150$59@gallifrey.nk.ca> thusly:

>This abusive spamtroll came from

You're only making it worse by responding to their posts.  Either
report the abuse to their posting ISP or adjust your KILL file to drop
their posts so you don't see them.

To answer the real question from 2019 (whee!), instead of addding
"debug" code to your production deployment, write unit tests for
everything you do so that you have confidence in the deployed code.

An example can be found here:
<https://github.com/LegalizeAdulthood/manx>
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#19450

On 4/24/2023 1:50 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
> 
> doctor@doctor.nl2k.ab.ca (The Doctor) spake the secret code
> <u236qf$150$59@gallifrey.nk.ca> thusly:
> 
>> This abusive spamtroll came from
> 
> You're only making it worse by responding to their posts.  Either
> report the abuse to their posting ISP or adjust your KILL file to drop
> their posts so you don't see them.
> 
> To answer the real question from 2019 (whee!), instead of addding
> "debug" code to your production deployment, write unit tests for
> everything you do so that you have confidence in the deployed code.
> 
> An example can be found here:
> <https://github.com/LegalizeAdulthood/manx>

Actually I don't have a problem with The Doctor calling out the posting 
ISP.  But I wish he wouldn't copy the entire message.  It just gives the 
message more popularity.

-- 
==================
Remove the "x"'s from my email address
Jerry Stuckle
stucklex.jerryx@gmail.com
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web