Re: [PATCH 13/17] engine.pl: provide more debug print statements

2015-06-29 Thread Sebastian Schuberth

On 25.06.2015 02:03, Philip Oakley wrote:


--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -41,6 +41,7 @@ EOM
  # Parse command-line options
  while (@ARGV) {
  my $arg = shift @ARGV;
+   #print "Arg: $arg \n";
  if ("$arg" eq "-h" || "$arg" eq "--help" || "$arg" eq "-?") {
showUsage();
exit(0);
@@ -129,6 +130,7 @@ sub parseMakeOutput
  print "Parsing GNU Make output to figure out build structure...\n";
  my $line = 0;
  while (my $text = shift @makedry) {
+   #print "Make: $text\n"; # show the makedry line


Please never commit code that's been commented out. Also see

http://dev.solita.fi/2013/07/04/whats-in-a-good-commit.html

;-)

--
Sebastian Schuberth

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [msysGit] Re: [PATCH 13/17] engine.pl: provide more debug print statements

2015-07-07 Thread Philip Oakley

From: "Sebastian Schuberth" 

On 25.06.2015 02:03, Philip Oakley wrote:


--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -41,6 +41,7 @@ EOM
  # Parse command-line options
  while (@ARGV) {
  my $arg = shift @ARGV;
+ #print "Arg: $arg \n";
  if ("$arg" eq "-h" || "$arg" eq "--help" || "$arg" eq "-?") {
  showUsage();
  exit(0);
@@ -129,6 +130,7 @@ sub parseMakeOutput
  print "Parsing GNU Make output to figure out build
structure...\n";
  my $line = 0;
  while (my $text = shift @makedry) {
+ #print "Make: $text\n"; # show the makedry line


Please never commit code that's been commented out. Also see

http://dev.solita.fi/2013/07/04/whats-in-a-good-commit.html

;-)


The gif was fun, even if it's a little OTT. It does smack of religious
dogma though ;-)



--


Hi Sebastian,

It's "deactivated code", not dead code [1].

I'd deliberately included this 'code', as per the commit message because
I saw this as a clear part of aiding future maintenance, and it matches
the rest of the code style, i.e. the judicious placement of a comment
that says 'here's the place to pick out the status when debugging' -
perhaps it's my engineering experience that sees the benefits.

These were the key debug points I used - other's I've removed from the 
series.


Philip


[1] In one of the replies to
http://embeddedgurus.com/barr-code/2013/02/dead-code-the-law-and-unintended-consequences/

:>> as per DO178B safety critical software development guideline
document Terms "Dead code" and "Deactivated Code" have distinct 
meanings:


Dead code : Dead code is source code (and it is a part of binary code)
that is not executed in the final system and it will be not having
traceability to any requirements (one can say unintentional code).

Deactivated code: code which is commented out or removed via #ifdef's
(it is not a part of final binary code) and it will be having
traceability to its low level requirements (its a intentional code and
it can be activated in some configurations through hardware traps for
debugging or other purposes.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html