Writing Clean Code – List of things you can do to make your code clean

Writing readable, maintainable and clean code has been my passion both as a developer and as a mentor guiding other fellow developers. With clean code, I have been able to throw so much garbage that I have actually reduced the lines of code that we have in the system significantly. This list is just a tip of iceberg in what you can do to make your code clean, but is a good start for those who seek to be better developers.

In now way I am imposing these as a standards. Situation could be different with different developers and organizations and the same rule of thumb might not apply for all.
Clean code features:

  1. Code should have a straightforward logic, no unnecessary twists and turns.
  2. No nests for bugs to hide. If you write a bad code, it’s a sweet home for the bugs to get born and grow.
  3. Code should have reduced or minimized dependency. Heavily dependent code is not clean, it’s a mess.
  4. Proper error handling strategy. Don’t let your code fail everywhere.
  5. Tuned for performance. No code is clean and good if it takes forever to run.
  6. Efficiency is the key.
  7. Leaves no broken windows (Dave Thomas and Andy Hunt). If you leave a bad code, chances are there will be more sprouts of bad codes.
  8. No Memory Leaks
  9. Consistent and meaningful Naming
  10. Clean code should do one thing and that one thing should be done well (Bjarne). Bad code tries to do too much stuffs at a time and leaves rooms for inefficiencies, maintenance horrors etc.
  11. Classes, functions or modules need to be unpolluted. They should contain only what is absolutely necessary. Don’t leave the unused variables, and objects around.
  12. Readability: Clean code should read like well written prose. There should be proper indentation etc. Huge list can go in this topic. But you might guessed what I am talking about.
  13. Understandability: The code should be easy to read and understand. Avoid the abbreviated variables, class names or methods.
  14. Should have proper unit tests. Code coverage matters. Although 100% code coverage is not practicable, the unit test code coverage should be as high as possible. But don’t focus on the coverage percentage, focus on what you are testing. Do not write test cases for just covering the code. Write the test cases that test the intent.
  15. All the unit tests that are written for the code should pass. Don’t leave the failing unit tests in your code.
  16. Should have proper acceptance test criteria.
  17. Any exposed interfaces and APIs must be clear and minimal
  18. Clean code should be easily maintainable by the non-original developers
  19. Clean code should be the code that has been taken care of (Michael Feathers)
  20. Should have reduced number of entities (objects, classes, methods, modules etc.)
  21. Should not have redundant logic scattered around the code.
  22. Should follow the Boy Scout Rule – ‘Leave the campground cleaner than you found it.’ This means, if you find a bad code around the classes and methods that you are writing, don’t curse the original author. Clean the code right away, so you have one less mess in your code.

Finding if two Strings are Anagrams

Anagram is a word, a phrase or a sentence formed from another by rearranging it’s letters.

To find out whether given two entities are anagrams or not is an interesting piece for programmers. There are multiple ways to find anagrams. Here is the easy way I have done:

  1. I sorted both strings. 
  2. I wrote the sorting of the strings to ignore the case.
  3. Sorted words are trimmed to avoid any extra spacing. This is particularly important because sometimes, for example, a two word phrase can become three word phrase while re-arranging, thus have difference is number of spaces.
  4. Sorted strings are then compared to see if they are identical. If identical, then they form anagrams.

 

The Java code I wrote to find the anagrams is given below. I reused the String Sort code from my previous post.

package com.icodejava.blog.datastructure;

import java.util.Arrays;

/**
 * @author Kushal Paudyal
 * www.icodejava.com
 * Created On -  Feb 14, 2014
 * Last Modified On - Feb 14, 2014
 */
public class AnagramFinder {

	public static void main(String args[]) {
		String firstString = "Dormitory";
		String secondString = "Dirty Room";

		checkForAnagram(firstString, secondString);

		secondString = "Dirty Rooms";

		checkForAnagram(firstString, secondString);

	}

	private static boolean checkForAnagram(String firstString, String secondString) {

		System.out.println("Analyzing the following words for Anagrams: " + firstString + " , " + secondString);

		boolean result;

		if (firstString == null || secondString == null) {
			result = false;
		} else {
			String sortedFirstString = sortIgnoreCase(firstString).trim();
			String sortedSecondString = sortIgnoreCase(secondString).trim();

			System.out.println("Sorted First String: " + sortedFirstString);
			System.out.println("Sorted Second String: " + sortedSecondString);

			result = sortedFirstString.equalsIgnoreCase(sortedSecondString);
		}

		System.out.println("ANAGRAM RESULT - " + result + "\n\n");

		return result;

	}

	/**
	 * @param string
	 *            - String to be sorted
	 * @return sorted string
	 */
	private static String sortIgnoreCase(String string) {
		if (string == null) {
			return null;
		}

		char[] characters = string.toUpperCase().toCharArray();
		Arrays.sort(characters);
		return new String(characters);

	}

}

The output of this program is:

Analyzing the following words for Anagrams: Dormitory , Dirty Room
Sorted First String: DIMOORRTY
Sorted Second String: DIMOORRTY
ANAGRAM RESULT - true


Analyzing the following words for Anagrams: Dormitory , Dirty Rooms
Sorted First String: DIMOORRTY
Sorted Second String: DIMOORRSTY
ANAGRAM RESULT - false

50 Things I Look For When I Do A Peer Code Review

(C) icodejava.com – Clean, well formatted, readable code.

I work as a tech lead for one of the fortune 500 companies, working with multitudes of developers on various projects. Some of these developers are fresh ones, others have come of age. Some of them are full time associates, while others are contractors who have seen various faces of software development styles at various other companies. In the end, everyone has their own coding styles, their own way of defining variables, their own way of writing classes and methods. Nobody purposefully wants to write bad code. Ultimately everyone tries to be a better coder.

Having said that, due to the varied nature of developers and their coding skills and styles, it becomes an important part of my role as a technical lead to make sure that the code that we are producing on a day to day basis are consistent, easy to read, are not nests for bugs, and are maintainable by people other than the ones who originally wrote them.

We work in an agile environments, pair programming kind of tends to do a first degree of code review by itself. But at times, I find myself still getting involved in a formal code review. Having worked on the enterprise application for several years, I do have a bigger picture of the application that some developers who are fresh hires. Coding clean is my passion. So when I start looking to peer’s work, I focus on certain standards of coding. Most of these standards are agreed upon by the team I work with and are implemented via static code analyzers such as Checkstyle. But it becomes necessary to remind to the new hires about these standards we follow. In this article, I am sharing 50 major things that I look at when I do a code review of my peer,co-worker, team mate.

  1. Does the code have proper error handling strategy? The common one being for the null pointer exception.
  2. Has the source code been properly formatted?
  3. Does every new method that is written have at least one unit test?
  4. Are there abbreviated variables or method names? I discourage using those. Variables, method names and class names must be meaningful.
  5. Are there any hard coded string literals? The string literals should be defined as constants.
  6. Is the method too long? Does it need to be split?
  7. Is the code efficient? For instance, are there any break statements in a for loop?
  8. Is the code repeated? If it is, then it’s time to refactor the code. Apply DRY – Don’t Repeat Yourself principle.
  9. Is the method having too many return statements?
  10. Are there too many if else conditions?
  11. Are there nested for loop? Every time there is a nested for loop, I recommend splitting that into two or more methods.
  12. Are there any default comments which add no values?
  13. Are there any TODO statements?
  14. Are the lines too long?
  15. Is the code consistent with rest of the code?
  16. Is the code readable?
  17. Is the code easy to follow through?
  18. Is the code maintainable? If someone else were to read the code and maintain it few years later, would it make sense?
  19. Are the resources, such as database connections, properly closed?
  20. Are there any tab characters? We have enforced to use spaces over tab characters in our team.
  21. Are there any unused imports?
  22. Is there any code with unhandled code warnings?
  23. Does the code have unused variables and methods?
  24. String Comparison. Does the code do CONSTANT.equals(variable) or varibale.equals(CONSTANT). The latter one can throw null pointer if variable is null. The former one does not.
  25. If you use static code analysis such as checkstyle, does the code introduce new warnings or errors?
  26. Does the code fail any unit tests?
  27. Are the variables public? variables must be private and have abstract methods.
  28. Is the file too long?
  29. Are there any empty methods?
  30. Do the methods have too many parameters?
  31. If the constructor definition in wrong order?
  32. Does the code catch the Exception class instead of the actual Exception such as NumberFormatException?
  33. Are there too many conditions being checked in an if statement?
  34. Are the variables and constants defined in correct order according to their visibility (public/private/protected/default).
  35. If you work on an agile environment, was there any pair programming done?
  36. Does the piece of code need performance testing?
  37. Is your method small? Does it do one thing and just one thing at a time based on your method name?
  38. If the code exposes any interfaces or APIs, are those clear and minimal?
  39. Is the proper level of abstraction used?
  40. If the code modified any existing logic, did the developer fix any existing issues such as abbreviated variable names in that method?
  41. Does the code use magic number such as 2,3,4 without stating what they mean?
  42. Does the code use magic strings such as “cp” (which could actually mean copy command) without stating what it means? The solution is to define description strings and use it, such as String COPY_COMMAND =”CP”;
  43. Does the class use a default package?
  44. Are there any variables defined within loops?
  45. Are there any variables defined that are used only once?
  46. Does the code use shared variables? Is the code thread safe?
  47. Is there any commented out code?
  48. Is the logging done properly, are there any left over System.out.println?
  49. Is the code clearly documented as needed? If the code is readable and flows through well, the needed documentation will be significantly less.
  50. Does a Switch / Case statement have a default?