Avoid Catch Generic Exception

Avoiding catching generic exceptions is generally recommended for several reasons:

1. Loss of Information:

   • Catching a generic exception like Exception or Throwable can hide important information about the specific type of error that occurred. This makes it harder to diagnose and fix the underlying problem.

2. Overgeneralization:

   • Catching a generic exception can lead to overgeneralization in error handling. Different types of exceptions may require different handling strategies, and catching them all with a single catch block can result in inappropriate error handling or masking of critical issues.

3. Unintended Consequences:

   • Catching a generic exception may inadvertently catch exceptions that should be propagated up the call stack for higher-level handling. This can lead to unexpected behavior or failure to handle critical errors properly.

4. Difficulty in Debugging:

   • When an exception is caught at a high level without specific information about the type of exception, debugging becomes more challenging. Developers may spend more time tracking down the root cause of the issue, especially in complex codebases.

5. Violation of Principle of Least Surprise:

   • Catching a generic exception violates the principle of least surprise, which states that code should behave in a way that is intuitive and predictable to developers. Explicitly catching specific exceptions makes the code's behavior more predictable and understandable.

Instead of catching generic exceptions, it's better to catch specific exceptions that you expect to occur and handle them appropriately. This allows for more targeted error handling, clearer code, and better resilience in your application. If there are common operations that need to be performed for different types of exceptions, consider refactoring them into separate methods or utility classes to avoid code duplication.

Continue

Practical Advice Clean Code For Android Developer

Generated by chat GPT:

1. Follow the Single Responsibility Principle (SRP):

   • Aim to create classes and methods that have a single responsibility. For example, separate UI logic from business logic and data access logic.

2. Use Descriptive Names:

   • Name your variables, methods, and classes descriptively so that anyone reading your code can understand their purpose without needing additional comments.

3. Keep Methods Short:

   • Aim for methods that are concise and do one thing well. If a method is too long (lines of code), it becomes harder to understand and maintain.

4. Avoid Magic Numbers and Strings:

   • Instead of hardcoding numbers and strings directly into your code, use constants or resource files. This makes your code more readable and easier to maintain.

5. Use Meaningful Comments Sparingly:

   • Comments should explain why something is done, not what is done. Ideally, write code that is self-explanatory, but use comments when clarification is necessary.

6. Consistent Formatting:

   • Stick to a consistent code style throughout your project. Use indentation, spacing, and naming conventions consistently to improve readability.

7. Handle Errors Gracefully:

   • Use try-catch blocks to handle exceptions appropriately. Avoid catching generic exceptions unless necessary, and always log or handle errors gracefully.

8. Separate Concerns with Design Patterns:

   • Use design patterns like MVC (Model-View-Controller) or MVVM (Model-View-ViewModel) to separate concerns and make your code more modular and maintainable.

9. Avoid Deeply Nested Callbacks:

   • Refactor your code to avoid deeply nested callback structures, which can make code harder to read and understand. Consider using RxJava or Kotlin coroutines for asynchronous operations.

10. Optimize Performance:

    • Write efficient code by optimizing resource usage, minimizing memory allocations, and using appropriate data structures and algorithms.

11. Unit Testing:

    • Write unit tests for your code to ensure its correctness and maintainability. Test-driven development (TDD) can help you write cleaner and more robust code from the start.

12. Code Review:

    • Regularly review your code with teammates or peers. Code reviews help identify issues, enforce coding standards, and improve overall code quality.

13. Refactor Regularly:

    • Refactor your code regularly to keep it clean and maintainable. As you add new features or find areas for improvement, take the time to refactor existing code to keep it in good shape.

14. Keep Dependencies Up-to-Date:

    • Update your dependencies regularly to benefit from bug fixes, performance improvements, and new features. Outdated dependencies can introduce security vulnerabilities and compatibility issues.

15. Documentation:

    • Document your code, including classes, methods, and complex algorithms, using appropriate comments. This helps other developers understand your code and its purpose.

By following these tips, you can write cleaner, more maintainable code in your Android projects, leading to better productivity and fewer bugs over time.

Continue

Normalisasi Database

Unnormalized data example :

Student ID	Student Name	Date of Birth	Teacher	Subject
98765432	John Smith	2006-05-12	Mr. Smith	Mathematics
12345678	Emily Johnson	2007-09-21	Ms. Jones	Science
87654321	Michael Brown	2005-11-03	Mr. Brown	English
54321678	Sarah Lee	2006-08-17	Mrs. Lee	History
87654321	Michael Brown	2005-11-03	Mrs. Garcia	Geography
98765432	John Smith	2006-05-12	Mr. Johnson	Physics

• Rows with Student ID 87654321 and 98765432 are duplicates with different Teacher and Subject.

After Normalized

To normalize this table, we'll split it into multiple tables to eliminate redundancy and improve data integrity. We'll create separate tables for Students, Teachers, Subjects, and a table to manage the relationships between them.

Students Table:

Student ID	Student Name	Date of Birth
98765432	John Smith	2006-05-12
12345678	Emily Johnson	2007-09-21
87654321	Michael Brown	2005-11-03
54321678	Sarah Lee	2006-08-17

Teachers Table:

Teacher ID	Teacher Name
1	Mr. Smith
2	Ms. Jones
3	Mr. Brown
4	Mrs. Lee
5	Mrs. Garcia
6	Mr. Johnson

Subjects Table:

Subject ID	Subject
1	Mathematics
2	Science
3	English
4	History
5	Geography
6	Physics

Student-Teacher Relationship Table:

Student ID	Teacher ID
98765432	1
12345678	2
87654321	3
54321678	4
87654321	5
98765432	6

Student-Subject Relationship Table:

Student ID	Subject ID
98765432	1
12345678	2
87654321	3
54321678	4
87654321	5
98765432	6

In this normalized structure:

• Each table stores data about a specific entity (students, teachers, subjects).
• Relationships between entities are managed in separate tables (student-teacher and student-subject relationships).
• Redundancy is minimized, and data integrity is improved.

Continue