CODING STANDARD-1

Author: Irtifa Haider
Date: September 14, 2024

Contents

1. Naming Conventions
   1.1. Variables
   1.2. Constants
   1.3. Functions/Methods
   1.4. Classes
   1.5. XML Elements
   1.6. Packages

2. Layout Conventions
   2.1. Indentation
   2.2. Empty Lines
   2.3. Braces

3. Member Order

4. Code Comments
   4.1. Inline Comments
   4.2. Method and Class Comments
   4.3. XML Layout Comments

5. Error Handling

6. Code Reusability

---

Chapter 1

Naming Conventions

1.1 Variables

Use camelCase for variable names.
Example:

 int totalAmount;

I suggest this, because: The use of capitalization in the middle of the variable helps distinguish individual words.

1.2 Constants

Constants should be written in UPPERCASE_SNAKE_CASE.
Example:
Figure 1.2

I suggest this, because: UPPERCASE_SNAKE_CASE makes constants stand out from other elements in the code. Since constants are meant to represent values that don’t change, making them easily identifiable helps programmers quickly recognize them.

1.3 Functions/Methods

Use camelCase for method names.
Example:
Figure 1.3

I suggest this, because: Method names typically represent actions and camelCase makes these action-oriented names easier to read.

1.4 Classes

Class names should be written in PascalCase.
Example:
Figure 1.4

I suggest this, because: PascalCase improves readability by capitalizing the first letter of each word in the class name.

1.5 XML Elements

Use lowercase and separate words with underscores.
Example:
Figure 1.5

I suggest this, because: Using lowercase with underscores ensures that XML names remain consistent and compatible, avoiding case-sensitivity issues that might arise in different programming languages or systems, like: Java. And separating words with underscores makes multi-word names more readable.

1.6 Packages

Use lowercase names, with no underscores, following the hierarchical naming structure.
Example:
Figure 1.6

I suggest this, because: This is the standard practice for package names in Java and Android to ensure compatibility across different platforms.

---

Chapter 2

Layout Conventions

2.1 Indentation

Use 4 spaces per indentation level. Do not use tabs.
Example:
Figure 2.1

I suggest this, because: It creates a clear visual hierarchy in the code structure.

2.2 Empty Lines

Add an empty line between:

• Methods
• Blocks of unrelated code.
  Example:
  I suggest this, because: using empty lines to separate different sections of code for better readability.

2.3 Braces

Always put the opening brace on the same line as the statement.
Example:
Figure 2.3

I suggest this, because: Placing the opening brace on the same line as the statement, rather than on a new line, makes the code more compact and readable, reducing unnecessary vertical space.

---

Chapter 3

Member Order

The member order defines the structure inside a class, ensuring consistency across the codebase.
Recommended Order Inside a Class:

• Constants
• Variables
• Constructors
• Methods: Public methods, followed by private methods.
  Example:
  Figure 3.1

I suggest this, because: this ordering follows a natural top-down structure. Constants provide class-level information, fields represent the object’s state, constructors initialize the state, and methods define the behavior of the class.

---

Chapter 4

Code Comments

4.1 Inline Comments

Use inline comments to clarify complex logic.
Example:
Figure 4.1

I suggest this, because: using inline comments highlights why certain decisions were made.

4.2 Method and Class Comments

Each method/class should have a Javadoc comment to describe its purpose, parameters, and return value (for method).
Example:
Figure 4.2

I suggest this, because: even if the code is well-written, the purpose of a method/class and their behavior/functionality may not always be immediately clear from just the code itself. By providing a high-level overview of what the method/class does, you make it much easier for others to understand the method’s functionality without needing to examine its implementation details line by line.

4.3 XML Layout Comments

Add comments in XML files to explain the section.
Example:
Figure 4.3

I suggest this, because: it explains why certain structures are used.

---

Chapter 5

Error Handling

• Use specific exceptions rather than catching or throwing generic exceptions.
  Example:
  Figure 5.1

  I suggest this, because: Using specific exceptions like IOException, SQLException, or NullPointerException provides clear information about what went wrong.

• Avoid empty catch blocks.
  Example:
  Figure 5.2

  I suggest this, because: Avoiding empty catch blocks ensures that errors are either properly handled or logged, preventing silent failures.

---

Chapter 6

Code Reusability

• DRY (Don’t Repeat Yourself)
  I suggest this, because: Avoid duplicating code to abstract common logic into reusable methods or classes.

• Use interfaces and abstract classes.
  I suggest this: to define shared behavior and promote polymorphism.