Scribd
Upload
49 views

Code Review

1) The document provides a checklist for code reviews focusing on 10 key areas: functional requirements, side effects, concurrency, readability and maintenance, consistency, performance, exception handling, simplicity, reuse of existing code, and unit testing. 2) Common causes of memory leaks include objects remaining referenced in memory even when no longer needed due to static variables or improper object cleanup. As memory fills, applications experience degraded performance and can crash. 3) Developers should check for thread safety, avoid unnecessary synchronization, and properly release resources to prevent memory leaks and ensure high performance concurrency.

Uploaded by

Prasad Dhanikonda
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
49 views

Code Review

1) The document provides a checklist for code reviews focusing on 10 key areas: functional requirements, side effects, concurrency, readability and maintenance, consistency, performance, exception handling, simplicity, reuse of existing code, and unit testing. 2) Common causes of memory leaks include objects remaining referenced in memory even when no longer needed due to static variables or improper object cleanup. As memory fills, applications experience degraded performance and can crash. 3) Developers should check for thread safety, avoid unnecessary synchronization, and properly release resources to prevent memory leaks and ensure high performance concurrency.

Uploaded by

Prasad Dhanikonda
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Checklist Item Category Explanation

Performance
Avoid excessive synchronization Concurrency

Keep Synchronized Sections Small Concurrency

Beware the performance of string concatenation General


Programming
Avoid creating unnecessary objects Creating and
Destroying Objects
Use a data type that best suits the needs such
as StringBuilder, generic collection classes.
Caching and session/application data.

Memory Leads because of Un reference or un Static variables in utility


used objects. GC can’t able to remove classes Out Of Memory
General
Prefer executors to tasks and threads Concurrency

Use enums instead of int constants Enums and


Annotations
Always override toString General
Programming
Always override hashCode when you override General
equals Programming
Refer to objects by their interfaces General
Programming
Minimize the scope of local variables General
Programming
Don't ignore exceptions Exceptions

Use checked exceptions for recoverable conditions Exceptions


and runtime exceptions for programming errors
Reusability, scalability, STest Driven
Programming,unit Test cases

Security
Avoid duplication of code
Fundamentals
Avoid excessive logs for unusual behavior Denial of Service

Release resources (Streams, Connections, etc) in Denial of Service


all cases
Do not log highly sensitive information Confidential
Information
Validate inputs (for valid data, size, range, Input Validation
boundary conditions, etc)

Make public static fields final (to avoid caller Mutability


changing the value)
Avoid serialization for security-sensitive classes Serialization
Deserialization
Be careful caching results of potentially privileged Serialization
operations Deserialization
1) Does Code meet the functional requirement: first and foremost does code meets all requirements
which it should meet, point out if anything has been left out.

2) Is there any Side effect of this change: Sometimes one change in your system may cause a bug in
other upstream and downstream system and it’s quite possible that new developer or anyone who is
writing code might not be available of that dependency. This often directly related to experience in
project and I found that the more you know about the system and its environment better you able to
figure this out.

3) Concurrency: does code is thread-safe? Does it have properly synchronized if using shared resource?
Does it free of any kind of deadlock or live-lock? Concurrency bugs are hard to detect and often surfaces
in production. Code review is one place where you can detect this by carefully understand design and its
implementation.

4) Readability and maintenance: do code is readable? Or is it too complicate for some-one complete
new? Always give value to readability as code is not just for this time it will remain there for long time
and you need to read it many times. Another important aspect is maintenance as most of software
spends 90% time on maintenance and only 10% time on development it should be maintainable and
flexible in first place. You can verify that whether code is configurable or not, look for any hard coding,
find out what is going to be changed in near future etc.

5) Consistency: This is part of point 4 but I have made it another separate point because of its
importance. This is the best thing you can have in your code which automatically achieves readability.
Since many developer and programmer take part in project and they have there own style of coding, it’s
in best interest of everybody to form a coding standard and follow it in letter and spirit. For example it’s
not good someone using function initialize() and other is using init() for same kind of operation, keep
you code consistent and it will look better, read better.
6) Performance: Another important aspect most important if you are writing high volume low latency
electronic trading platform for high-frequency trading which strives for micro second latency. Carefully
monitor which code is going to execute at start-up and which is going to be executed in a loop or
multiple times optimize the code which is going to execute more often.

7) Exception handling: Ask does code handles bad input and exception? It should and that too with
predefined and standard way which must be available and documented for support purpose. I put this
point well above on my chart while doing a review because failing on this point can lead your application
crash and not able to recover from fault on other system or another part of the same application.

8) Simplicity: Always see if there is any simple and elegant alternative available at-least give a thought
and try. Many times first solution comes in mind is not best solution so giving another thought is just
worth it.

9) Reuse of existing code: See if the functionality can be achieved by using existing code, the advantage
of doing this is that you are using tried and tested code which reduces your QA time and also gives you
more confidence. Introducing new libraries

10) Unit test: Check whether enough JUnit test cases have been written and cover sufficient percentage
of new code. never let you pass the code without Junit test because developer often makes excuse of
time but believe me its worth to write it.

Read more: https://javarevisited.blogspot.com/2011/09/code-review-checklist-best-


practice.html#ixzz6HxHiRYDx

What Is a Memory Leak


A Memory Leak is a situation when there are objects present in the heap that are
no longer used, but the garbage collector is unable to remove them from
memory and, thus they are unnecessarily maintained.
A memory leak is bad because it blocks memory resources and degrades system
performance over time. And if not dealt with, the application will eventually exhaust
its resources, finally terminating with a fatal java.lang.OutOfMemoryError.
There are two different types of objects that reside in Heap memory — referenced and
unreferenced. Referenced objects are those who have still active references within the
application whereas unreferenced objects don't have any active references.
The garbage collector removes unreferenced objects periodically, but it never
collects the objects that are still being referenced. This is where memory leaks can
occur:
Symptoms of a Memory Leak

 Severe performance degradation when the application is continuously running


for a long time
 OutOfMemoryError heap error in the application
 Spontaneous and strange application crashes
 The application is occasionally running out of connection objects

You might also like