Source code review

Get a Source Code Review done for your Website & Application

Source Code Review (also known as peer review) means identifying and rectifying the fundamental and prime flaws in coding which can lead into loss of data and reach even up to the extent of defacement of your company’s website and disrupting the image of your business poorly. Website defacement is typically the ill-work of system crackers, who by breaking into web servers changes the very visual appearance of a site or a webpage.

To prevent this undesirable and unauthenticated behavior it is a must to create a website that is hack proof. And it can be remediated only by making a website go under a thorough source code review where your website will be comprehensively scanned by our experts. Following the scan the vulnerabilities will be reported to you by our experts. Next, we would patch the vulnerabilities for you to make it hack proof. Whenever there is a significant change or modification in website, it is highly advocated to go for a source code review.

Our experts thrive in performing code review as it also boosts their own technical skills also. It is best suited to perform source code review alongside Web Penetration Testing or Android App Penetration Testing like most corporate houses do in order to give the process a more vivid, comprehensive and complete outlook.

 

Source Code Review

 

We at Indian Cyber Security Solutions possess the required people, right tools, good working atmosphere, great amenities, and superb infrastructure that would satisfy all your needs pertaining to all kinds of code review errors and/or problems. By our source code review solutions we give your website the perfect shape and look maintaining in full volume its originality and integrity through the removal of all sorts of flaws in design and bugs.

We meticulously remove the errors in programming application that might anytime result into the collapse of your webpage. The review not only involves the application of tools but manual top-grade efforts of our experts as well who have got enormous patience, a quality that every good code reviewer must have at his disposal. 

Code review also enhances the software security aspect by detecting and removing vulnerabilities like formal string exploits, race conditions, memory leaks and buffer overflow. Ideal code review rates should range between 200-400 lines of code per hour. We understand that the margin for error in code review is nil and therefore carry out our work accordingly with great care and accuracy. In the long run code review can save both time and money provided they are done properly. Highlighting issues that are more appropriate to human perception is another significant function of source code review.

Over the years code reviews have evolved rather drastically and there are now many options to select from. According to industry data, code review can achieve 85% accuracy rate at most while the average defect removal rate is about 65%. Code review can be broadly classified into two categories viz. formal and lightweight. The former involves detailed process including multiple phases and participants. It is the traditional way of code reviewing.

Instance of formal code review is Fagan inspection which is truly effective in finding defects in the code that is under review. The lightweight mode of code review too can be equally successful if and when done properly. However, it requires less formal overhead in comparison to the formal one. So it is used for mainly the normal development process.  The amount of investment and the duration of time taken are however much more for formal code reviews which again is quite natural given the enormity of the task.

Make your website hack proof and go for a code review where we conduct a complete scan of your website development code and report vulnerability to you. we patch those coding errors and make your website hack proof.

 


Want to go for a Source Code Review for your business ?

GET STARTED


 

Top 10 source code review checklist

Documentation

  • All methods are commented in clear language. If it is unclear to the reader, it is unclear to the user.
  • All source code contains @author for all authors.
  • @version should be included as required.
  • All class, variable, and method modifiers should be examined for correctness.
  • Describe behavior for known input corner-cases.
  • Complex algorithms should be explained with references. For example,  document the reference that identifies the equation, formula, or pattern. In all cases, examine the algorithm and determine if it can be simplified.
  • Code that depends on non-obvious behavior in external frameworks is documented with reference to external documentation.
  • Confirm that the code does not depend on a bug in an external framework which may be fixed later, and result in an error condition. If you find a bug in an external library, open an issue, and document it in the code as necessary.
  • Units of measurement are documented for numeric values.
  • Incomplete code is marked with //TODO or //FIXME markers.
  • All public and private APIs are examined for updates.

Testing

  • Unit tests are added for each code path, and behavior.
  • Unit tests mustcover error conditions and invalid parameter cases.
  • Unit tests for standard algorithms should be examined against the standard for expected results.
  • Check for possible null pointers are always checked before use.
  • Array indices are always checked to avoid ArrayIndexOfBounds exceptions.
  • Do not write a new algorithm for code that is already implemented in an existing public framework API, and tested.
  • Ensure that the code fixes the issue, or implements the requirement, and that the unit test confirms it. If the unit test confirms a fix for issue, add the issue number to the documentation.

Error Handling

  • Invalid parameter values are handled properly early in methods (Fast Fail).
  • NullPointerExceptionconditions from method invocations are checked.
  • Consider using a general error handler to handle known error conditions.
  • An Error handler mustclean up state and resources no matter where an error occurs.
  • Avoid using RuntimeException, or sub-classes to avoid making code changes to implement correct error handling.
  • Define and create custom Exceptionsub-classes to match your specific exception conditions. Document the exception in detail with example conditions so the developer understands the conditions for the exception.
  • (JDK 7+) Use try-with-resources. (JDK < 7) check to make sure resources are closed.
  • Don’t pass the buck!Don’t create classes which throw Exception rather than dealing with exception condition.
  • Don’t swallow exceptions!For example catch (Exception ignored) {}. It should at least log the exception.

Thread Safety

  • Global (static) variables are protected by locks, or locking sub-routines.
  • Objects accessed by multiple threads are accessed only through a lock, or synchronized methods.
  • Locks must be acquired and released in the right order to prevent deadlocks, even in error handling code.

Performance

  • Objects are duplicated only when necessary. If you must duplicate objects, consider implementing Cloneand decide if deep cloning is necessary.
  • No busy-wait loops instead of proper thread synchronization methods. For example, avoid while(true){ … sleep(10);…}
  • Avoid large objects in memory, or using Stringto hold large documents which should be handled with better tools. For example, don’t read a large XML document into a String, or DOM.
  • Do not leave debugging code in production code.
  • Avoid out.println();statements in code, or wrap them in a Boolean condition statement like if(DEBUG) {…}
  • “Optimization that makes code harder to read should only be implemented if a profiler or other tool has indicated that the routine stands to gain from optimization. These kinds of optimizations should be well documented and code that performs the same task should be preserved.” – UNKNOWN.

Further updated details refer to the code review updates

 


Show Buttons
Hide Buttons