Frequently asked questions

• Who built Insphpect?

  Insphpect was built by Tom Butler as part of his Ph.D thesis at the University of Northampton.

• Why PHP and not Java/Python/Ruby/etc?

  PHP was chosen as a proof of concept because:

  1. It is open source and would have been possible to make a custom build of the PHP interpreter for the scanner if required.
  2. There are thousands of existing projects which could be used to test the metric.
  3. PHP allows easily controlling how classes are loaded via autoloaders. This enabled easier development as custom code could be easily injected into classes.

• Can it scan private repositories?

  This is planned for a future version, however at the moment all code that is uploaded is visible on a publicly accessible URL, as such, a complete login system with report privacy will also be required.

• What is uploaded code used for?

  Uploaded code is scanned and used to generate a report.

• How long is code kept for?

  Code is currently kept on the server to keep reports availble to view. Reports can be manually deleted by request

• Should I recode my application based on the recommendations given?

  Insphpect is an educational tool, it's not designed to yell at you to change your code until you get a perfect score. However, you might want to consider the suggestions when writing your next project.

  Further reading: https://r.je/hazard-2-but-ive-always-done-it-this-way.

• Why is it flagging [ ... ] as a bad practice?

  The following bad practices are currently identified by Insphpect:

  1. Global Variables
  2. Inheritance
  3. Using the new keyword in a constructor
  4. Setter Injection
  5. Singletons
  6. Static Methods
  7. Annotations
  8. Service Locators

  Although there is always some debate on the best approach in any given case, Insphpect only scans for bad practices related to flexibility. There may be cases where performance or developer convenience are more of a concern than flexibility. Insphpect does not attempt to second guess what your priorities are and simply outlines places where code flexibility can be improved.

  The bad practices idenfied are backed up by academic research. The methdology is on the background research page.

  It should be noted, that it is expected that this list will grow over time as new bad practices are identified by industry experts.

• What does the score mean?

  The grade given is a score between 0 and 100 where 100 means every class in the project is free of practices which hinder flexibility in your code.

  A score of 0 means your classes will be very difficult to move between projects, use in isolation (without the full stack) or will be impossible to use with different configurations.

• Should I try to get a 100 score?

  Probably not. Insphpect calculates the flexibility of each class. Sometimes a class will never need to be used on another project or re-used with different configurations. Insphpect only tells you that it will be difficult to use the class in a different environment or with a different configuration.

  In a lot of libraries there will be an entry ponit which does a lot of instantiation of other objects and is inflexible by design. However, if you have inflexibility in other locations a better design may be preferred.