Code Review Guide lines

 1- Readable

2- Performance (dev vs prod) 3- Reusable code 4- Naming convention - variables, classes, properties, functions Eg, GetEmployee >> GetEmployeeList ----- both conveying same meaning but first is small 5- DRY principle - Don't repeat yourself -- create helper classes/ function and reuse 6- Class names, Method names: PascalCase 7- Variables: camelCase 8- Keep methods small and simple. Don't make it too large. Keep it short and simple. If it's too short, split its functionality and call the function in actual function.. 9- Create self explanatory method names so that you don't need to write comments

Code Review Checklist:

1. Logging
2. Monitoring
3. Scale
4. Traceability
5. Troubleshooting
6. Reporting
7. UX
8. Incorrect problem definition
9. Time management
10. Ignoring other features.
11. Focusing on today needs.
12. Alerting
13. Metrics
14. Testing
15. Deployment
16. Code cleanup
17. Latency
18. No design review
19. No customer review
20. Concurrency
21. Simple bugs
22. Mutation
23. Readability
24. Naming
25. Documentation (motivation)
26. Audit
27. Security
28. Complex if-then logic
29. Suspicious loop 'break'
30. Negative logic
31. Regexp - long input could cause issues.
32. Nulls
33. More than 3 arguments
34. Line length
35. Shared resources abuse
36. Cache (think hard)
37. Variable name length
38. Commit message
39. Squash if needed
40. Build time change
41. "Random" usage smell
42. Open Close principle
43. Code duplication
44. OverComplexity (ex. Types where string is enough)
45. UnderComplexity (ex. strings where type is required)
46. Bulk test fail smell
47. Backward compatibility
48. Forward compatibility
49. API no version
50. Incorrect db type usage
51. Adding indexes instead of search engine view
52. Ignoring Failures
53. Expecting feature would work
54. Too verbose error handling
55. Sensitive info in logs
56. Missing "main" flow
57. Feature toggle (if needed)
58. Dependencies (collisions? new one?)
59. Comments smell
60. Dependent Teams
61. Plural/Singular correctness
62. Consistency with codebase conventions
63. Revert implications
64. Either simple MultiReturn or Single
65. Time to understand code smell