PHP Classes

Criticisms

Recommend this page to a friend!

      Free Phone Number Verification in PHP  >  Free Phone Number Verification in PHP package blog  >  PHP Phone Number Vali...  >  All threads  >  Criticisms  >  (Un) Subscribe thread alerts  
Subject:Criticisms
Summary:Examples not using best practices
Messages:1
Author:Dave Smith
Date:2015-12-13 22:07:43
 

  1. Criticisms   Reply   Report abuse  
Picture of Dave Smith Dave Smith - 2015-12-13 22:07:43
Apparently there have been some criticisms to the examples used in the article that I will address...

1.) Hidden form variables to tell if a user has submitted a form.

It is not a best practice to avoid using hidden form variables. In my opinion it is best practice to use one to determine if a form has been posted since older browser will not post the submit field if the user submits the form by pressing the enter key.

2.) Using unsanitized $_REQUEST values.

This is correct, all user input should be sanitized, however this article is a guide to using the Phone Number Verification package methods and not a guide on how to properly sanitize user input, which would end up being an entire article on its own.

3.) Completely unsanitized form input that is directly used in the code.

See comment to point 2 above.

4.) Using include() when the entire script requires the use of said include()...so a require() should be used at the least.

I suppose the flip side of this argument is that it is okay to use includes when you know it won't be included. There is no best practice to use require over include. That is like saying you should always use include_once, just in case someone nests the include. Using include to include a file you know is there is fine.

5.) No autoloading, namespacing, or any modern PHP development practices are applied.

This is directly related to the class, and not the article. I attempt to keep all my open source classes as simple, yet operational, as possible. I do this so that the code can be figured out by just about anyone and I see no need to over complicate things just because I can.

6.) Five levels of nested control statements.

The purpose of the example is to provide easy to follow logic for the reader. It makes no sense to me to provide unreadable, however more efficient, code unless the article happens to be about more efficient coding practices, which this article is not.

7.) Not mentioning once that initial number validation can be done both on the frontend in JS and sanitizing + validation using filter_input() on the backend in PHP.

This is suggesting that you should validate the phone number format before sending it to the API to be validated. Validate before validating... really? The API uses advanced techniques to validate the format based on international and local standards as well as correction mechanisms to auto correct if possible. Don't force your user to re-enter their phone numbers unless the API can't correct and validate them. That is one of the main advantages of using the API to begin with.

Examples used in articles will not likely be production ready, as these aren't. Instead, they serve the purpose of providing information in a way that even non coders can understand.

Dave