Manju

Greetings! It is common thing in programming that we need to iterate over items. Question is, how do you iterate over collection and implement your logics? Most of the time, people violate single responsibility principle as loops are having multiple logics. I would like to have cleaner separation between unrelated logics. If you pay attention, you can see that in loops, we are doing multiple things. Let's see a little (dirty) example. public class SplitLoop { public static void main(String[] args) { List<Subject> subjects = Arrays.asList(new Subject("Maths", 90), new Subject("History", 85)); int total = 0; int marksForMaths = 0; for (Subject subject : subjects) { total += subject.getMarks(); if ("Maths".equals(subject.getTitle())) { marksForMaths = subject.getMarks(); } } System.out.println("Total " + total + " for Maths " + marksForMaths); } static class Subject { ...

Greetings! "I have done my work. I'm taking another ticket." "Can we close this ticket end of the sprint." "Why is this ticket still open." "We need to work extra and close these tickets." Those are only a few phrases. If you have not heard those words, congratulations!! you are working in a super nice environment. Unfortunately for most, these are daily sentences they encounter. The definition I'm using this term for anyone, be it an intern, architect, manager or anyone whose main target is to close the ticket by themselves or by forcing others. They do not focus on, do not allow code improvements. Why do they do it As I can't read minds, I don't know. However they may be targeting big paychecks, promotions, praises, etc by showing they are very efficient, committed, etc. However they are just moving from one ticket to another. How do they look like Lazy to learn Do not understand the value of good code No proper use of design pr...

Greetings! While I was reviewing a code, I noted that there is a Sonar violation saying not to use HashTable. Which is correct. Also it suggested to use something like HashMap instead of HashTable. I reached out the developer and asked to remove the HashTable but she said that use of HashMap did not work. Also when I asked why did you use HashTable at first place, the answer was legacy code expects it, hence for new code we need to add HashTable. Let's see how we can solve such cases.  Problem First of all we need to understand why these kind of rules exists. Our codebase is very old hence we have lots of deprecated class usages. Former developers have used whatever the API available those days. As a junior developer you need to understand, learn that classes like HashTable, Vector should not use in modern codes because those are synchronized. You need to replace those with modern APIs. Hashtable<Integer, String> ht1 = new Hashtable<>(); Problem... Again One of thos...

Greetings! I have been using SonarQube as a quality tool for quite some time now. It is used for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities. Eventhough the intention is to detect issues, top level managers, architects, etc use it to measure team's working quality progress in their visual boards. As they are usually busy people they will not have time to look into real code and to see the real issues there. What happen then? developers will start to write "sonar satisfy" codes. I have seen very unreadable bad codes with zero sonar quality issues. And also there are good quality codes with some unnecessary sonar issues. Reason for that is it can detect prefined rules but not all design flows. If you want to be a good developer, don't try to write "sonar quality" code, instead use "clean codes" and get the Sonar support when necessary. Let...

Greetings! There are If/Else or switch statements in any Software. We need to use that logical branching for object oriented programming as well. The question is how do you use that? are they readable? maintainable? or looks beautiful? What I normally see in such codes is those are very fragile, hard to read, ugly. Needless to say about the vulnerability of the branching levels in this case. Most of the developers might add few private methods and call those to show that the code is clean. This can be solved in multiple ways depending on the situation. Simple Conditions When you see such a code, consider it as a candidate for polymorphism. In most of the cases, you can deal this with abstraction. A simple factory will do the rest. Multi level branches Complexity arrives with multi levels. It is quite difficult to identify common factors, abstraction. However, it does not mean you can't do it. It depends on the problem at hand. You might still fix this with a simple interface, using...