4 Best Practices For Coding
1. Variables & Classes Names
Choose descriptive and unambiguous names.
Make meaningful distinctions.
Choose descriptive and unambiguous names.
Use pronounceable names.
Use searchable names.
Use nouns for classes, packages, and variables
Use verbs/verb phrases for functions.
Avoid unpopular acronyms and other names that don’t make sense.
Avoid using confusing letters for names.
Avoid meaningless prefixes or suffixes.
2. Code Formatting
coding best practices python,good coding practices in software engineering,coding best practices java,software development best practices,
Group code by their functionality. Related functions must be close. Related code must appear vertically dense.
Declare temporary variables close to their usage.
Adapt company/team-wide code conventions. Agree on a common standard for code-formatting. 4. Either use an external tool or IDE options for auto-formatting.
Avoid too long files. 1000–2000 lines are okay. Shorter, the better.
Avoid too-wide code lines. Make sure they fit into the screen (Up to 70 to 120 characters). If they don’t fit, try to split them into multiple lines.
Write high-level code first in a file and keep lower-level implementations towards the end of the file. (Good files are like newspaper articles, with a heading, the important stuff first, and details later)
Make sure the code is ordered as of the calling sequence. The caller should be before the callee.
Follow proper indentation across code files. Use an external tool or IDE’s support.
3. Error Handling
coding best practices python,good coding practices in software engineering,coding best practices java,software development best practices,
At lower levels, throw exceptions instead of returning error codes. Keep error codes for communication between different layers, interfaces, or systems.
Errors and exceptions must provide adequate context (such as intent, failure stage, error type, failed values etc.)
Map foreign errors to adhere to common standards. Wrap all errors and exceptions raised from external systems, third-party libraries, and APIs. Use a generic error type for unknown/unhandled cases.
Reduce the reliance on return type and null checks (since they strongly couple failure path information to main flow). Instead of returning null/false, return a proper error object or throw an exception. Passing null to a function / next stage is also bad, avoid such practices.
