How to remember to remove debug lines in code

Question

It seems to me that this is a new idea (since I did not find solutions or someone implemented it) ...

A shell script that automatically runs whenever you run git or something else that tells you if you forgot to remove any debugs or env development specific lines of code in your project.

For instance:

Often (in my Ruby projects) I will leave lines of code for outputting variables, e.g.

puts params.inspect 

or

 raise params.inspect 

In addition, sometimes I will use different methods, so I can easily see the effects, for example, in cases, for example, using delayed_job, where I would rather name the method without delay during development.

Sometimes I forget to change these methods or forget to remove the call to raise params.inspect, and I will inadvertently press this code.

So, I thought, maybe the easiest solution was to add a comment to any such debug line, such as

 raise params.inspect #debug 

Essentially mark this line as a development / debug line. Then, in a shell script that runs before some other command, such as git commit, it can use awk or grep to search all the last modified files for this #debug comment and stop execution and warn you. However, I am not very versed in shell scripts, so I thought I would ask for help :)

Answer 1

Although I sincerely recommend following cdeszaq’s advice and discouraging this kind of thing from happening, it's pretty easy to write a git hook that will prevent you from making any lines with a specific line. For simplicity, I don't show git rev-parse -verify HEAD, which you should use to get this hook to work with the original commit, but if you just put the following in .git / hooks / pre-commit (and make it executable), you you cannot commit any lines of code containing the string "#debug":

  #! / bin / sh

 if git diff-index -p -M --cached HEAD |  grep '#debug'> / dev / null;  then
   echo 'debug lines found in commit.  Aborting '> & 2
   exit 1
 fi

Answer 2

Instead of forgetting to do extra work (deleting lines of code), you only need to do extra work later when things break again (re-adding this code), why not introduce reasonable debugging statements from the very beginning?

Most languages ​​have quite expressive and often cheap logging libraries that will allow you to write out various levels of information (error, information, debugging, tracing) at several different locations (file, database). Many of these libraries will even allow you to adjust the logging level for a specific piece of code at run time or even while the program is running.

So, instead of trying to repack the brute force, debugging the problem, why not, and the rest of the world should use what you produce, benefit and use the real logging structure for logging

Answer 3

As I said in my comment, you can use any programming language that is convenient for you.

In any case, looking for other commit fixations, I think this one might be good for a start. It basically searches for some words in your files and can only be configured to modify the checks array at the top of the file.

Answer 4

@cdeszaq is right with the logging part.

For behavior that varies by environment, a common way to achieve this is to make the behavior customizable. delayed_job should read the value from the configuration file to decide how long to delay. For production environments, configuration has one meaning, and for development environments, configuration will have a different meaning.