Showing posts with label best practices. Show all posts
Showing posts with label best practices. Show all posts

Friday, February 14, 2014

Why Static Code Analysis is Important?

From last few years, Software code quality and security has went from being a �nice to have� to a necessity, and many organizations, including investment banks are making it mandatory to pass static code analysis test, penetration testing and security testing before you deploy your code in production. Static analysis tools like findbugs and fortify are getting popular every passing day and more and more companies are making fortify scan mandatory for all new development. For those unaware of what static code analysis is, static code analysis is about analysing your source code without executing them to find potential vulnerabilities, bugs and security threats. Static code analyser looks for patterns, defined to them as rules, which can cause those security vulnerability or other code quality problems, necessary for production quality code. But like every other technology, static analysis has it�s set of advantages and disadvantages, which is also best way to judge any technology. Static code analyser are not a new thing, and they are here from long time, but as a senior Java developer or Team lead, you have responsibility to set-up process like automated code analysis, continuous integration, automation testing to keep your project in healthy state and promote best development practices in your team. In my opinion, unit testing, code review and static code analysis makes a nice combo, along with continuous integration. In this article, we will learn some pros and cons of static code analysis, to let you decide, whether static analysis is important or not. I am already convinced with pros, and we are using fortify scanning in all our projects, and have seen benefits of that, but its not all good, its also time consuming. When your tool alert you with false positive, you start taking them lightly and then it become habit to treat everything as false positive, which eventually take away all benefits of static code analysis. You need to be discipline enough, not to fall on that trap.
Read more �

Tuesday, August 20, 2013

Why use SLF4J over Log4J for logging in Java

Every Java programmers knows that logging is critical for any Java application, especially server side application, and many of them are already familiar with various logging libraries e.g. java.util.logging, Apache log4j, logback, but if you don't know about SLF4J, Simple logging facade for Java, then it's time to learn and use SLF4J in your project. In this Java article, we will learn why using SLF4J is better than using log4j or java.util.logging. It�s been long time, since I wrote 10 logging tips for Java programmer,I don�t remember anything I have writing about logging. Anyway, let�s get back to topic, on contrary to all those logging libraries, there is a major difference between them and SLF4J. SLF4J or Simple logging Facade for Java is not really a logging implementation, instead it's an abstraction layer, which allows you to use any logging library in back-end. If you are writing API or utility library, which can be used internally or externally, then you really don't want that any client, which uses your library, should also stick with your choice of logging library. Suppose if a project is already using log4j, and you included a library say Apache Active MQ, which has dependency on logback, another logging library, then you need to include them as well, but if Apache Active MQ uses SL4J, you can continue with your logging library, without pain of adding and maintaining new logging framework. In short SLF4J make your code independent of any particular logging API, which is good think for public API developers. Though idea of abstracting logging library is not new and Apache commons logging is already using it, but now SLF4J is quickly becoming an standard for logging in Java world. Let's see couple of more reason to use SLF4J over log4j, logback or java.util.logging.
Read more �