Forum Discussion

ryan_perneel's avatar
ryan_perneel
Contributor
8 years ago

Dead Code

Has anyone come up with a way to search for dead code in a large code base?  I am trying to do some cleanup on a legacy project, and currently having to do a search for each function to see if it is referenced in the project somewhere.

 

I have started to build something in C# that would accomplish this, but was wondering if anyone else has done something similar in the past.

 

What would be really useful is if we had something similar to CodeLense that is in visual studio

 

 

  

Thanks

  • tristaanogre's avatar
    tristaanogre
    8 years ago

    All that said... if you think this is a feature worth adding to TestComplete, the cool thing about SmartBear folks is that they take suggestions seriously.  Go to https://community.smartbear.com/t5/TestComplete-Feature-Requests/idb-p/TestXCompleteFeatureRequests and create a feature request.  It doesn't guarentee that it will get done, but it will get looked at.

    In the meantime... have you considered just bringing in your code units into an IDE that has such a feature and letting the feature run?  All the script code units are simple text files that can be brought into any environment that supports it.  In the past, there was someone that was looking for some sort of "auto-documentation" tool that would parse code and generate documentation on all methods and such in the code.  They used an external tool to do so because of this very thing... that the code units are simple text files that can be ported into any compatible tool.

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi,

     

    a) No, TestComplete does not provide any means for this task;

    b) If exists, such analysis tool will be language-dependent and TestComplete supports 5 scripting languages and two additional flavors of JScript;

    c) While explicit search for function names may work in some situations, note, that all scripting languages provide Eval() or Evaluate() function that makes it possible to call function by providing its name as a plain string and, depending on the design of the given test code, this string may be obtained from, say, configuration file and not be explicitly referenced from within test code.

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor

      Point c is probably the biggest "gotcha" for this.  If  you are writing a lot of explicit code and not bringing stuff in via data, then yes, a "dead code" detector should work pretty well.  It might even be possible to do so with all the different languages, after all, we do have syntax highlighting that is keyed off of language.   

      However, in frameworks like what I'm currently using or that Colin_McCrae is working with, it's not quite so easy.  There may be classes, routines, etc., that the data feeding the test framework no longer reference and yet there are no explicit calls to them within the actual code base.  For that matter, should those be deleted?  I know, in the past, I've had multiple data sets all using the same framework.  One data set uses one set of code, another date set uses another set of code.  There's some overlap, but which data set would you use to determine which code is "dead"?

      I think, in the long run, good practices of code development of making sure to mark deprecated code within internal documentation, etc., is the better way to go.  If you tag routines and methods with some sort of common tag, then you can go through and remove that code.  Consider leveraging the "TODO" feature.

      • Colin_McCrae's avatar
        Colin_McCrae
        Community Hero

        Yep. I'm in agreement with AlexKaras & tristaanogre

         

        90% of the functions in my tests are called by the user populating the driver sheets with keywords and then "eval'd" in the code. Without using logging, and applying some sort of analysis to logs over time, I would have no idea how much use each one gets. Even then, a function showing zero use after a few weeks of running may simply be an infrequently used one.

         

        That's functions that are written to perform parts of tests. (I have few functions that are full tests in their own right.)

         

        Framework functions are different. They're not user called for the most part, so would be easier to track down redundancy.